Folia：区域化多线程技术如何改变你的Minecraft服务器
如果你运营着一个大型Minecraft服务器，每当有人探索新区块或达到玩家数峰值时，看着TPS不断下降，Folia可能就是你一直在寻找的答案。这个基于Paper的分支完全重新设计了Minecraft服务器的计算方式，它将世界分割成独立的区域，每个区域在自己的线程上运行。与其让单个主线程竭力应对一切，不如让Folia充分发挥你CPU核心的并行处理能力。
什么是Folia
Folia不是模组，也不是插件。它是Paper服务器的一个从零开始的重写，彻底移除了主线程的概念。取而代之，临近的区块被分组到"区域"中，每个区域在线程池的某个线程上独立运行自己的Tick循环。可以把它理解为：不再让一个线程去微观管理一切，而是给世界的不同部分分配各自的处理器。
这种架构很重要，因为它改变了你服务器的扩展方式。
Paper在单线程设计下对数百万玩家的服务器表现良好，但当你达到下一个规模层级时 - 数百名玩家分散在一个巨大的世界中 - 瓶颈就会出现。Folia不试图从单个线程中挤出更多的性能，而是从根本上改变了问题的本质。
为什么你需要这个
大型分散式服务器受益最多。拥有浮空岛屿散布在各维度中的空岛网络、巨大的生存世界、具有分布式副本地牢的自定义RPG服务器 - 这些地方正是Folia大放异彩的地方。如果你的玩家都聚集在一个出生点附近，你看不到同样的性能提升。但对于拥有200+玩家的SMP，其中人们在不同的象限探索，差异是显著的。
我应该坦白地说，这不是一个即插即用的替代品。
你的插件需要为Folia的多线程环境重写。这是真正的成本。但如果你已经达到了考虑使用它的规模，你的插件生态系统可能已经是自定义的了。不假设存在主线程的标准Paper插件在Folia下会立即崩溃。
不过，收益是真实的。经过适当的配置，你会看到能随CPU核心数扩展的真实性能改进。这在标准Paper上是无法实现的。
安装与基础设置
首先，从PaperMC下载页面获取最新构建版本。截至2026年，Folia支持现代Minecraft版本（1.20.4及更高）。将jar文件下载到你的服务器目录：
<! - gh-code-start - >wget https://api.papermc.io/v2/projects/folia/versions/latest/builds/latest/downloads/folia-latest.jar
mv folia-latest.jar folia.jar接下来，你需要在eula.txt文件中同意EULA。启动服务器一次以生成配置文件：
<! - gh-code-start - >java -Xmx30G -Xms30G -jar folia.jar nogui将其停止（它会创建folia.yml配置文件），然后你需要进行真正的工作：线程配置。这不只是"设置更多线程然后启动"。PaperMC文档建议在生产环境前预生成你的世界，这能显著降低区块加载的开销。
线程配置：真正的挑战
这是大多数人感到困惑的地方。你的folia.yml有一个`threaded-regions.threads`设置。不要简单地把它最大化。项目本身的指导方案是：为netty IO分配约4个线程（每200-300个玩家），为区块系统IO线程分配约3个线程（每200-300个玩家），为区块系统工作线程分配约2个线程（如果预生成），然后使用剩余核心用于Tick线程，总分配不超过80%。
在一台32核机器上运行500名玩家的服务器，你大概会分配：
- Netty IO：8个线程
- 区块系统IO：6个线程
- 区块系统工作线程：4个线程
- Tick线程：剩余核心，不超过80%（约10个线程）
你不能使用100%的分配，因为插件和意外的后台任务会生成自己的线程并导致服务器崩溃。80%的上限是一个真正重要的安全边界。
即便如此，这也只是一个起点。在实际负载下监控你的线程使用情况并进行调整。folia.yml文件为每个选项都提供了详细的注释。
有效的关键功能
区域隔离。每个区域以20 TPS独立运行。一个区域中的延迟峰值不会级联到其他区域。如果你的副本地牢系统优化得不好，它也不会拖累你出生点的性能。
适当的线程扩展。与Paper的插件线程池方法不同（后者仍然会在Tick关键操作上产生瓶颈），Folia的区域并行运行Tick逻辑。更多的核心实际上会转化为更多的Tick处理。扩展不是线性的，但它是真实的。
异步区块加载。区块I/O在区域线程之外进行。你不会再经历单线程服务器在存储读取激增时的随机冻结。
还有对服务器端区块优化、预生成区块缓存和可配置的每区域内存限制的原生支持。坦白地说，如果你愿意深入文档，功能深度令人印象深刻。
什么会崩溃以及如何处理
大多数插件假设它们在主线程上，并且可以安全地读写世界状态而无需同步。它们在Folia上是错的。如果一个插件做类似"检查方块X是否是石头，然后将其设为空气"的事情，那个竞争条件可能会在线程间发生，而在Paper上永远不会。预期插件失败。
一些具体的例子：
- 在区域之间的传送涉及额外的复杂性，如果插件不小心可能导致死锁
- 世界边界检查是区域感知的，可能表现得与你预期的不同
- 计时器和计划任务需要区域安全以避免损坏
- 跨区域边界的实体跟踪需要插件更新
Folia文档明确列出了不兼容的模式。如果你在为兼容性评估插件，检查它们是否直接操纵Tick逻辑或假设对区块数据的单线程访问。
什么时候Folia有意义
你有一台16+核的机器。你的服务器会定期达到200+并发玩家。你的玩家在地理上分散（不是全部在出生点）。你要么有自定义的插件基础设施，要么你愿意移植现有的插件。
这四个条件都满足？你就是潜在用户。
你在VPS上运行50个玩家的服务器，只有8个核心？坚持使用Paper。性能提升不值得兼容性的麻烦。你运行一个100玩家的SMP，其中每个人都聚集在出生点？Folia有帮助，但不如在分散式服务器上那样戏剧性。
但如果你在构建下一代认真的多人Minecraft社区，Folia是性能天花板实际上更高的地方。像adderall_abuser的皮肤、ironmouse的皮肤以及其他大型服务器活跃社区成员的玩家已经在探索这个领域。查看直播社区和Modrinth上的大型生存项目 - 你会越来越频繁地看到Folia出现。
值得考虑的替代方案
Paper。仍然是大多数服务器的黄金标准。稳定、易于理解、拥有庞大的插件生态系统。如果Folia感觉太过度了，Paper的优化功能（异步区块加载、减少实体AI Tick等）可能就足够了。
Purpur。Paper的一个分支，具有额外的每玩家优化。对于玩家体验差异很大的服务器更好（一些AFK，一些积极探索）。架构变化比Folia少，性能提升更有针对性。
Fabric服务器。如果你需要模组支持（不是插件），Fabric生态系统现在对服务器来说实际上相当不错。不是以同样方式多线程的，但轻量级且快速。
诚实的事实是，Folia是专门化的。它是为特定规模下的特定问题而设计的。对于其他所有人来说，经过深思熟虑的配置的Paper仍然是正确的选择。
<! - gh-polish-start - > <! - gh-polish-end - >
