EasyGC

Minecraft JVM 参数与最佳 GC 设置 ​

Minecraft（Java 版）本身就是一个 JVM 应用——你世界的每一个 tick 都跑在 Java 虚拟机上，而服务器卡顿的第一大元凶就是垃圾回收。选对 JVM 参数，直接决定你是稳 20 TPS 还是不断回弹卡顿。

为什么默认参数不行 ​

原版启动器和很多服务器宿主给的堆偏小，而且历史上不指定回收器。Minecraft 会大量产生短命对象（方块更新、实体、网络包）。堆小时：

  1. 年轻代几秒钟就填满 → 回收频繁、停顿密集。
  2. 每次停顿 = 服务器冻结 = 玩家看到卡顿尖刺。
  3. 模组服上千个类还会压迫元空间。

内存该给多少？（-Xmx / -Xms） ​

给 JVM 足够的堆，并把初始值设成和最大值一样，避免运行中扩容：

场景推荐 -Xmx
原版客户端，常规视距2–4 GB
模组客户端（轻中度整合包）4–6 GB
原版服务器（10 人）4–8 GB
模组服务器（100+ Mod）6–12 GB
-Xms4G -Xmx4G

内存不是越大越好

堆过大时，每次 Full GC 要清扫的内存也大 → 停顿更长。给 JVM "需要的量"，而不是"你所有的量"。

换用现代垃圾回收器 ​

影响最大的一个改动：用 G1GC 替换默认回收器，并按 Minecraft 的分配模式调参。社区标准做法（即 Paper 服务器常用的 "Aikar 风格参数"）遵循以下原则：

  1. G1GC + 较小的停顿目标——几毫秒的停顿替代几百毫秒。
  2. 更大的年轻代（-XX:G1NewSizePercent=40）——MC 对象死得极快，更大的 Eden 意味着更少的回收次数。
  3. 积极的混合回收（-XX:MaxGCPauseMillis=130、降低触发阈值）——在被逼 Full GC 之前就把老年代清掉。
  4. 元空间预留，模组服尤其需要（-XX:MaxMetaspaceSize=256M）。

服务器的现代最小起点：

bash
java -Xms4G -Xmx4G \
  -XX:+UseG1GC -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 \
  -XX:MaxGCPauseMillis=130 -XX:InitiatingHeapOccupancyPercent=30 \
  -XX:MaxMetaspaceSize=256M -jar server.jar nogui

Paper / Purpur 服务端内置了合理默认值——但进一步调优时，上面的 GC 思路依然适用。

然后：测量，而不是猜 ​

在启动命令里加一行 GC 日志参数，让服务器正常跑一段时间，再看看真实的停顿数据：

bash
# 加进启动命令（Java 9+）
-Xlog:gc*:file=gc.log:time,uptime

然后把 gc.log 拖进 GC 日志分析器：你能确切看到每次停顿多久、多久发生一次、堆够不够用。如果报告显示停顿频繁且长、或 GC 后堆占用持续抬升，就调大 -Xmx 或套用上面的 G1 参数——然后再分析一次确认效果。

实测效果

一个模组服从默认参数下每分钟 8–15 秒 GC 时间，优化到 G1 + 合理堆大小后的每分钟不到 1 秒——卡顿尖刺消失。

相关文章 ​