行业资讯 · 发布时间：
租赁服务器运行Minecraft模组服的Java垃圾回收参数调优，第一步不是复制一串“优化参数”，而是确认卡顿是否真的来自 GC。区块加载、模组逻辑、磁盘读写和 CPU 忙碌都可能造成延迟；只改垃圾回收器，未必能改善游戏体验。
先确认卡顿和 GC 有没有关系
观察服务器卡顿时的 MSPT（每刻耗时）：Minecraft 服务端需要尽量在每个游戏刻的时间预算内完成工作。若 MSPT 突然升高，并与 GC 日志中的长时间暂停重合，才有理由优先调整堆和 GC。若没有对应暂停，应继续检查模组任务、实体数量、区块生成及主线程负载。
模组服使用的 Java 版本取决于 Minecraft 版本和模组加载器要求。先查看服务端启动日志或对应版本说明，不要为了尝试新 GC 而擅自更换 Java。租赁套餐标注的内存也不一定全能分给 Java 堆：系统、原生内存和其他进程同样需要空间。
从堆大小与日志开始调整
给堆留出余量
对于有一定模组数量的服务端，可先依据实际占用设置 -Xms 和 -Xmx；例如机器总内存为 8 GB 时，堆可从约 4–6 GB 试起，同时为系统及 Java 堆外内存保留空间。这个范围只是起点，模组数量、在线人数和租赁环境会改变需求。若服务端频繁因内存不足退出，再结合运行记录逐步增加，而不是直接把全部内存分给堆。
开启 GC 日志
Java 17 可在启动参数中加入 -Xlog:gc*:file=logs/gc.log:time,uptime,level,tags:filecount=5,filesize=10M。确认日志目录可写，并在数次卡顿后查看记录；不同 Java 版本的日志参数可能不同。重点看暂停时长、回收前后堆占用，以及 GC 是否频繁发生，不要仅凭某一条记录下结论。
G1 参数怎么调
Java 9 及之后的版本通常默认使用 G1。先用较少的参数运行一段有代表性的时段，再根据日志逐项调整。-XX:MaxGCPauseMillis=100 可作为尝试的暂停目标；它不是保证值，设得过低可能增加回收频率或资源消耗。不要同时套用来源不明的整套参数，也不要把早期 Java 版本常见的 CMS 参数直接搬到新版本。
- 记录 Java 版本、堆大小、在线人数和卡顿发生时间。
- 开启 GC 日志，观察多个高负载时段，而非只看启动后的短时间。
- 若日志显示暂停偏长且堆占用持续偏高，检查堆是否过小；有内存余量时，再小幅增加 -Xmx。
- 每次只改一项，并在相似负载下比较 MSPT 与 GC 暂停；若变化无改善，恢复原值。
租赁服务器运行Minecraft模组服的Java垃圾回收参数调优，核心是用日志验证因果，再谨慎改变堆大小或暂停目标。ZGC 等其他收集器是否适用，要看 Java 版本、服务端兼容性和资源情况；不要仅因名称更新就切换。
常见问题
把 -Xms 和 -Xmx 设成一样好吗？
便于固定堆的目标范围，但会减少弹性；应确保租赁服务器有足够内存容纳堆外开销和系统需求。
GC 暂停不长，服务器仍然卡怎么办？
继续排查主线程负载、模组任务、区块生成和磁盘情况，避免把所有卡顿都归因于垃圾回收。
要不要直接换 ZGC？
先确认 Java 版本和服务端兼容性，再进行对照测试。不同收集器在暂停、吞吐和资源占用上的表现会随负载变化。
参数改完后多久判断效果？
至少覆盖有代表性的高负载时段，并比较相近在线人数和活动场景下的日志与 MSPT；单次短测不足以说明效果。
