调优内存与 JVM 参数（Aikar's Flags）降低 Minecraft 卡顿

Minecraft 服务器出现卡顿、TPS 下降，并不总是因为内存太少。很多时候罪魁祸首是 Java 虚拟机（JVM）配置不当，导致长时间的垃圾回收（GC）停顿，玩家会感觉到明显的卡帧。本文将说明如何正确分配内存、恰当设置 -Xms 和 -Xmx，并应用被称为 Aikar's Flags 的常用参数集，让你的 Paper/Spigot 服务器尽可能流畅运行。

为什么内存越多不一定越流畅

"内存越多越好"是最常见的误解。给 JVM 分配过大的堆内存，会迫使垃圾回收器在每个周期扫描巨大的一块内存，产生更长而非更短的停顿。此外，Minecraft 的性能主要受单线程 CPU 速度限制，而非内存大小，因为世界的 tick 逻辑运行在唯一的主线程上。

彻底理解 -Xms 与 -Xmx

这两个参数是 JVM 内存分配的核心：

• -Xms = JVM 启动时立即预留的初始堆大小
• -Xmx = JVM 允许增长到的最大堆大小

始终设置为相等

对于游戏服务器，你应当始终把 -Xms 设置为与 -Xmx 相等。如果两者不同，JVM 会在需要更多内存时逐步扩展堆，而每次堆扩展（heap resize）都会造成玩家感受到的卡顿停顿。从一开始就设置相等，JVM 会立即预留全部空间，之后无需再次扩展。

不要把系统全部内存都给 JVM

一个严重错误是把 -Xmx 设置为机器的全部内存。除了堆之外，Java 还使用堆外内存（Metaspace、线程栈、原生缓冲区），操作系统本身也需要内存。请始终为操作系统以及 Minecraft 的堆外使用预留大约 1-2GB。

Aikar's Flags：标准参数集

Aikar's Flags 是由 Aikar（PaperMC 开发者）开发的 JVM 参数集，专门针对 Minecraft 的工作负载调优 G1 垃圾回收器，优先追求短 GC 停顿而非纯粹的吞吐量。以下是适用于堆内存不超过 12GB 的参数集：

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -jar paper.jar --nogui

关键参数的含义：

• -XX:+UseG1GC 使用为短停顿设计的 G1 垃圾回收器
• -XX:MaxGCPauseMillis=200 目标是停顿不超过 200ms
• -XX:+AlwaysPreTouch 在启动时触及全部内存，使内存真正提交并减少运行时的缺页中断
• -XX:+DisableExplicitGC 防止插件调用 System.gc() 触发不必要的 full GC

内存超过 12GB 时调整参数

如果你分配的堆内存超过 12GB（例如大型模组服务器），Aikar 建议调整若干参数，让 G1GC 更有效地处理较大的堆：

-XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCCountTarget=8

原因在于：更大的堆需要更大的新生代（更高的 G1NewSizePercent/G1MaxNewSizePercent）和更大的区域（G1HeapRegionSize=16M），以减少 GC 需要管理的区域数量。同时 InitiatingHeapOccupancyPercent=20 允许堆填充得更满再启动并发周期，这更适合大堆。

TPS 与 MSPT：真正的指标

不要凭感觉衡量流畅度，要看真实数据：

• TPS（每秒 tick 数）目标是每秒 20 个 tick。低于此值意味着服务器跟不上，游戏会变慢。
• MSPT（每 tick 毫秒数）处理每个 tick 的时间应保持在 50ms 以下（因为 1000ms / 20 tick = 50ms）。超过 50ms，TPS 就会开始下降。

用 /spark 或 /timings 诊断

使用 /spark 插件（推荐）或 /timings 命令来剖析什么最消耗 tick 时间，例如实体过多、红石负载过重，或某个特定插件。这些报告能告诉你问题是出在内存/GC，还是 CPU 受限（CPU-bound）。

按玩家数量推荐内存

以下数字是你应分配给 JVM 的堆大小（Xmx 值），而不是 VPS 的总内存。记得为操作系统预留 1-2GB：

玩家数量	服务器类型	推荐堆内存（Xmx）
1-5 人	原版/Paper	2-3GB
5-15 人	Paper + 插件	4GB
15-30 人	Paper + 大量插件	6-8GB
模组（Forge/Fabric）	大型整合包	8-16GB+

使用大型整合包的模组服务器，消耗的内存是原版的数倍，因为它们加载大量模组并生成更复杂的世界。

选择适合 Minecraft 的 VPS

由于 Minecraft 主要依赖单核（单线程）CPU 性能，选择 VPS 时应看重每核 CPU 速度，而非核心数量多。AsiaGB 提供的 Linux VPS 套餐起价 500 泰铢/月，采用 SSD 存储，通过 DirectAdmin 管理，具备 99% 的在线率，足以应对中小型服务器。请选择一个既为操作系统预留内存、又能满足上表所需堆大小的套餐。

调优流程总结

1. 评估玩家数量和服务器类型，从表中选取堆大小
2. 始终把 -Xms 设为与 -Xmx 相等，并为操作系统预留 1-2GB
3. 应用完整的 Aikar's Flags（堆超过 12GB 时进行调整）
4. 运行并用 /spark 监控 TPS/MSPT
5. 如果内存充足仍卡顿，应排查 CPU 受限问题，而不是增加内存

正确的调优不是塞入尽可能多的内存，而是分配恰到好处的量并让 G1GC 高效工作，同时搭配单核性能强劲的 CPU。

常见问题 (FAQ)

应该把 Xms 和 Xmx 设置为相等吗？

是的，应始终设置为相等，让 JVM 在启动时预留完整堆，运行途中无需扩展，从而避免引起卡顿的停顿。

分配大量内存真的会让服务器更流畅吗？

不一定。过大的堆会延长 GC 停顿，如果问题是 CPU 受限，增加内存完全不会提升 TPS。

TPS 与 MSPT 有什么区别？

TPS 是每秒 tick 数，目标为 20；MSPT 是每 tick 的时间，应保持在 50ms 以下，若 MSPT 超过 50ms，说明 TPS 正在下降。

如何判断卡顿是内存还是 CPU 导致的？

使用 /spark 或 /timings 检查，如果内存充裕且没有长 GC 停顿但 TPS 仍下降，就是 CPU 受限，需要减少主线程负载。