Folia: Wie regionalisiertes Multithreading deinen Server verändert

Wenn du einen großen Minecraft-Server betreibst und zusehen musst, wie deine TPS in den Keller gehen, sobald jemand neue Chunks erkundet oder die Spielerzahlen ihren Höhepunkt erreichen, könnte Folia die Rettung sein. Dieser auf Paper basierende Fork krempelt die Art und Weise, wie Minecraft-Server Berechnungen verarbeiten, komplett um, indem er die Welt in unabhängige Regionen aufteilt, die jeweils in einem eigenen Thread laufen. Statt eines einzigen Haupt-Threads, der sich abmühlt, mit allem gleichzeitig Schritt zu halten, ermöglicht Folia deinen CPU-Kernen echte parallele Arbeit.

Was Folia ist

Folia ist keine Mod und auch kein Plugin. Es ist eine komplette Neuentwicklung des Paper-Servers, die das Konzept eines Haupt-Threads komplett abschafft. Stattdessen werden benachbarte Chunks zu „Regionen“ zusammengefasst, und jede Region führt ihre eigene Tick-Schleife im Thread-Pool aus. Stell es dir so vor, als ob verschiedene Teile deiner Welt ihren eigenen unabhängigen Prozessor bekämen, anstatt dass ein einziger Thread alles bis ins kleinste Detail verwalten muss.

Die Architektur ist wichtig, da sie die Skalierung deines Servers grundlegend verändert.

Paper bewältigt Server mit Millionen von Spielern gut im Rahmen seines Single-Thread-Designs, aber sobald du die nächste Stufe der Skalierung erreichst - Hunderte von Spielern, die über eine riesige Welt verteilt sind -, entstehen Engpässe. Folia versucht nicht, mehr aus einem einzelnen Thread herauszuquetschen. Stattdessen ändert es das Problem grundlegend.

Warum du das wollen würdest

Große, weitläufige Server profitieren am meisten. Skyblock-Netzwerke, bei denen Spieler über verschiedene Dimensionen verstreute schwebende Inseln haben, riesige Survival-Welten, benutzerdefinierte RPG-Server mit verteilten Dungeons - das sind die Bereiche, in denen Folia glänzt. Wenn sich deine Spieler an einem einzigen Spawn-Bereich knubbeln, wirst du nicht die gleichen Leistungssteigerungen sehen. Aber für ein SMP mit mehr als 200 Spielern, die in verschiedenen Quadranten auf Entdeckungstour sind, ist der Unterschied enorm.

Eines sollte ich vorab erwähnen: Dies ist kein direkter 1-zu-1-Ersatz.

Deine Plugins müssen für die Multithreading-Umgebung von Folia umgeschrieben werden. Das ist der eigentliche Haken. Aber wenn du eine Größe erreichst, bei der du darüber nachdenkst, ist dein Plugin-Ökosystem wahrscheinlich ohnehin maßgeschneidert. Standard-Paper-Plugins, die nicht davon ausgehen, dass es keinen Haupt-Thread gibt, werden unter Folia sofort abstürzen.

Die Mühe lohnt sich jedoch. Mit der richtigen Konfiguration erwarten dich echte Leistungsverbesserungen, die mit der Anzahl deiner CPU-Kerne skalieren. Das ist auf einem Standard-Paper-Server nicht machbar.

Installation und grundlegendes Setup

Hol dir zuerst den neuesten Build von der PaperMC-Download-Seite. Ab 2026 unterstützt Folia moderne Minecraft-Versionen (1.20.4 und neuer). Lade die JAR-Datei in dein Server-Verzeichnis herunter:

wget https://api.papermc.io/v2/projects/folia/versions/latest/builds/latest/downloads/folia-latest.jar
mv folia-latest.jar folia.jar

Als Nächstes musst du die EULA in deiner eula.txt-Datei akzeptieren. Starte den Server einmal, um deine Konfigurationsdateien zu erstellen:

java -Xmx30G -Xms30G -jar folia.jar nogui

Stoppe ihn wieder (dadurch wird die folia.yml-Konfiguration erstellt), und dann geht es an die eigentliche Arbeit: die Thread-Konfiguration. Hier gilt nicht einfach „mehr Threads einstellen und los“. Die PaperMC-Dokumentation empfiehlt, deine Welt vorzugeben (Pre-Generation), bevor du live gehst, was den Overhead beim Laden von Chunks erheblich reduziert.

Thread-Konfiguration: Die wahre Herausforderung

Hier geraten die meisten Leute durcheinander. Deine folia.yml hat eine Einstellung namens `threaded-regions.threads`. Reize diese nicht einfach blind aus. Die Richtlinie des Projekts selbst lautet: Weise Threads für Netty-IO zu (etwa 4 pro 200-300 Spieler), Chunksystem-IO-Threads (etwa 3 pro 200-300 Spieler), Chunksystem-Worker, wenn die Welt vorgeneriert ist (etwa 2 pro 200-300 Spieler), und verwende dann die verbleibenden Kerne bis zu einer Gesamtauslastung von 80 % für die Tick-Threads.

Auf einer Maschine mit 32 Kernen, die 500 Spieler bedient, würde man grob wie folgt aufteilen:

• Netty IO: 8 Threads
• Chunksystem IO: 6 Threads
• Chunksystem-Worker: 4 Threads
• Tick-Threads: verbleibende Kerne bis zu 80 % (etwa 10 Threads)

Man lässt die Auslastung nicht auf 100 % laufen, da Plugins und unerwartete Hintergrundaufgaben ihre eigenen Threads starten und den Server zum Absturz bringen können. Die 80-Prozent-Grenze ist ein Sicherheitspuffer, der wirklich wichtig ist.

Selbst das ist nur ein Ausgangspunkt. Überwache deine tatsächliche Thread-Auslastung unter Last und passe sie an. Die Datei folia.yml enthält detaillierte Kommentare zu jeder Option.

Wichtige Features, die funktionieren

Regionen-Isolierung. Jede Region tickt unabhängig mit 20 TPS. Ein Lag-Spike in einer Region wirkt sich nicht auf andere aus. Wenn dein Dungeon-System schlecht optimiert ist, zieht es die Performance deines Spawn-Bereichs nicht mit nach unten.

Echte Thread-Skalierung. Im Gegensatz zu Papers Plugin-Threadpool-Ansatz (der bei tick-kritischen Operationen immer noch an seine Grenzen stößt) führen die Regionen von Folia die Tick-Logik parallel aus. Mehr Kerne bedeuten tatsächlich mehr Tick-Verarbeitung. Die Skalierung verläuft zwar nicht linear, aber sie ist spürbar.

Asynchrones Chunk-Laden. Chunk-I/O findet abseits der Regions-Threads statt. Du wirst nicht die zufälligen Standbilder erleben, die Single-Thread-Server bei Spitzenwerten bei Lesezugriffen auf den Speicher haben.

Es gibt auch native Unterstützung für serverseitige Chunk-Optimierung, vorgenerierten Chunk-Cache und konfigurierbare Speicherlimits pro Region. Ehrlich gesagt ist die Feature-Tiefe beeindruckend, wenn man bereit ist, sich in die Dokumentation einzulesen.

Was kaputtgehen wird und wie man damit umgeht

Die meisten Plugins gehen davon aus, dass sie auf einem Haupt-Thread laufen und den Weltzustand ohne Synchronisierung sicher lesen und schreiben können. Bei Folia liegen sie damit falsch. Wenn ein Plugin beispielsweise prüft, ob Block X Stein ist, und ihn dann auf Luft setzt, kann dieser Race-Condition-Effekt über Threads hinweg auftreten, was auf Paper niemals passieren würde. Stelle dich auf Plugin-Fehler ein.

Einige Details:

• Das Teleportieren zwischen Regionen ist komplexer und kann zu Deadlocks führen, wenn Plugins nicht vorsichtig sind
• Weltgrenzen-Prüfungen sind regionsbezogen und verhalten sich möglicherweise anders als erwartet
• Timer und geplante Aufgaben müssen regionssicher sein, um Datenfehler zu vermeiden
• Das Entity-Tracking über Regionsgrenzen hinweg erfordert Plugin-Updates

Die Folia-Dokumentation listet inkompatible Muster explizit auf. Wenn du Plugins auf Kompatibilität prüfst, kontrolliere, ob sie die Tick-Logik direkt manipulieren oder einen Single-Thread-Zugriff auf Chunk-Daten voraussetzen.

Wann Folia Sinn macht

Du hast einen Server mit 16 oder mehr Kernen. Dein Server wird regelmäßig mehr als 200 gleichzeitige Spieler beherbergen. Deine Spieler sind geografisch weit verteilt (nicht alle am Spawn). Du hast entweder eine eigene Plugin-Infrastruktur oder bist bereit, bestehende Plugins anzupassen.

Treffen diese vier Bedingungen zu? Dann bist du ein Kandidat.

Du betreibst einen Server mit 50 Spielern auf einem VPS mit 8 Kernen? Bleib bei Paper. Die Gewinne rechtfertigen den Kompatibilitätsaufwand nicht. Du betreibst ein SMP mit 100 Spielern, bei dem sich alle am Spawn aufhalten? Folia hilft zwar, aber nicht so drastisch wie auf einem weitläufigen Server.

Aber wenn du die nächste Generation anspruchsvoller Minecraft-Multiplayer-Communities aufbaust, bietet Folia die deutlich höhere Leistungsgrenze. Spieler mit Skins wie adderall_abuser, ironmouse und andere aktive Community-Mitglieder auf riesigen Servern erkunden diesen Bereich bereits. Schau dir Streaming-Communities und große Survival-Projekte auf Modrinth an - du wirst Folia immer öfter sehen.

Bedenkenswerte Alternativen

Paper. Nach wie vor der Goldstandard für die meisten Server. Stabil, bewährt, riesiges Plugin-Ökosystem. Wenn dir Folia als Overkill erscheint, reichen die Optimierungsfunktionen von Paper (asynchrones Laden von Chunks, reduzierte Entity-AI-Ticks usw.) möglicherweise aus.

Purpur. Ein Paper-Fork mit zusätzlichen Optimierungen pro Spieler. Besser für Server, auf denen das Spielerlebnis stark variiert (einige AFK, andere aktiv am Erkunden). Weniger architektonische Änderungen als bei Folia, aber gezieltere Leistungssteigerungen.

Fabric Server. Wenn du Mod-Support (keine Plugins) benötigst, ist das Fabric-Ökosystem mittlerweile ziemlich solide für Server. Zwar nicht im gleichen Sinne multithreaded, aber leichtgewichtig und schnell.

Die nackte Wahrheit: Folia ist hochspezialisiert. Es ist für ein bestimmtes Problem in einer bestimmten Größenordnung gedacht. Für alle anderen ist Paper mit einer durchdachten Konfiguration nach wie vor die richtige Wahl.