阅读前の声明

本文章转载于 JVM Tuning: Optimized G1GC for Minecraft – Aikar’s Thoughts
翻译工具：DeepSeek-R1

引言

经过数周对JVM、参数及多种组合的测试研究，我为Minecraft总结出一套高度优化的G1垃圾回收参数。这些参数已在个人服务器中测试并沿用多年。随后我将研究成果公开，至今众多服务器长期使用这些参数，反馈显示垃圾回收行为显著改善。

这些参数凝聚了大量心血，并在不同规模服务器、插件列表及服务器类型中经过生产环境验证，反复证明其有效性。

我强烈建议使用这些参数启动服务器。它们能确保服务器运行保持一致性，避免大型垃圾回收峰值。CPU占用可能轻微上升，但服务器的整体可靠性和TPS稳定性将大幅提升。

若这些参数对您的服务器有帮助，请考虑赞助支持！

PayPal 捐赠链接：https://donate.emc.gs/MC Flags

JVM启动参数——MC 1.15（Java 8+，MC 1.8+）更新版

请严格使用以下参数，仅修改Xmx和Xms。这些参数适用于任意内存规模（甚至500MB），但1.15版本在过低内存下表现不佳…）

java -Xms10G -Xmx10G -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 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar paperclip.jar nogui

最后更新：2020年4月25日 美国东部时间下午3:30
*这些参数推荐用于Minecraft全版本！从1.8到1.15+均可使用此配置。*

重要提示——请阅读——勿耗尽全部内存！！面板用户注意！

设置Xms与Xmx值时，若主机标明内存为8000M，切勿直接设置为8000M！Minecraft（及Java）需在Xmx值之外预留额外内存。建议将Xmx/Xms降低约1000-1500M，以避免内存耗尽或触发”OOMKiller”终止进程。此举同时为操作系统预留内存空间。

拥有8000M内存？安全起见请设为6500M。但可询问主机商是否愿承担此开销并提供9500M内存——部分主机会同意！

推荐的服务端

若您尚未使用Paper（Spigot的高度优化版），务必切换！Paper是更快的Spigot版本，具有显著性能提升，同时修复漏洞与安全问题，提供新特性及丰富API以优化插件体验。

Paper可无缝替代Spigot，所有Bukkit/Spigot插件均兼容。切换无任何弊端。

下载 Paper

Paper 文档

Paper Discord 频道

（需要梯子）为何你应该转向 Paper

Paper是保障1.15服务器流畅运行的唯一选择！

推荐的内存配置

*推荐至少分配6-10GB内存，无论玩家数量多少！*若无法提供10GB，请尽可能分配最大内存，但需确保为操作系统留出空间。G1GC在更大内存下表现更佳。

若为MC分配的内存≤12GB，请勿调整以下参数。

若Xmx值大于12G

若实际使用内存超过 12GB，请调整以下参数：

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

注意：若调整后老年代回收频率增加，请恢复基础参数！

注：老年代垃圾回收，指Java虚拟机垃圾回收机制中对老年代（Old Generation / Tenured Generation）内存区域进行的回收操作。老年代主要存放存活时间较长的对象。

调整原因：

• 基础参数设为30/40是为降低空间耗尽风险。内存充足时此风险降低，故将新生代比例提升至40/50，并因默认预留空间已增大而降低保留百分比。
• 增大Region Size可减少巨型分配（注：Humongous Allocations，指超过Region一半大小的对象），加速标记过程。小堆需较小Region Size以保证区域数量充足。
• 因CPU可用老年代空间更多，将IHOP（注：堆占用触发阈值）设为20可延迟老年代回收时机。

Java GC日志记录

使用这些参数时是否遇到老年代问题？请协助我分析！根据Java版本添加以下参数启用GC日志：

Java 8-10：

-Xloggc:gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=1M

Java 11+:

-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M

若在Timings中发现老年代回收，请提取logs/gc.log文件（与latest.log同目录）并通过Paper Discord发送给我。

GC日志不影响性能，可长期开启。文件体积极小（仅5MB）。

参数技术解析：

-Xms 与-Xmx 保持一致的原因

绝不允许-Xmx耗尽系统内存。服务器应预期完全使用-Xmx内存！需确保操作系统在Xmx外另有内存供非MC进程使用。因此，若Java可能用满内存，切勿设置无法支持的-Xmx值。若-Xms低于-Xmx，则存在未用内存！未用内存即浪费内存。G1（可能包括CMS）在内存充足时表现更优。G1自适应分配各区域内存以优化暂停时间。若内存超出最优暂停所需，G1仅将多余内存划入老年代而无害（CMS或非如此，但G1适用）。优化GC的核心是确保短命对象年轻代消亡，永不晋升。内存越多，G1越能避免对象过早晋升至老年代。G1机制异于旧回收器，可更高效处理大堆。

-XX:+UnlockExperimentalVMOptions

启用后续实验性参数所必需。

-XX:G1NewSizePercent

关键参数。CMS等回收器中，调整新生代需用-Xmn固定其大小。G1更优：可指定新生代占总堆的百分比范围。此设置使新生代占比提至40%（默认仅5%）。*Minecraft内存分配率极高——30人服务器可达800MB/秒！且多为短命对象（如区块坐标）*。若新生代过小，每秒将触发1-2次新生代回收，导致频繁暂停威胁TPS，且对象更快晋升加速老年代增长。增大新生代可拉长回收间隔，留足时间让短命对象消亡，提升GC效率。

-XX:G1MixedGCLiveThresholdPercent=90

控制混合回收（注：Mixed GC，同时回收新/老年代的GC）中纳入老年代区域的条件。内存占用低于此值时，老年代不参与混合回收。混合回收轻于Full GC，小规模渐进清理可维持内存低占用。默认值依Java版本为65-85，设为90可加速回收老年代垃圾以保留更多空闲区域。旧参数误设为35（本意与65效果相同），切勿使用35。

-XX:G1ReservePercent=20

新版MC内存分配率极高，易因空间不足引发灾难性”to-space耗尽”（注：复制存活对象时目标区域不足）。此参数预留更多内存应对此操作，默认值10提升至20

-XX:MaxTenuringThreshold=1

MC内存分配率极高，多数内存在Eden区回收。但瞬态数据（注：短时存在对象）会溢入Survivor区。初始测试完全移除Survivor效果尚可，但导致瞬态数据进入老年代。阈值设为1确保瞬态数据不晋升至老年代——存活超过2次GC的对象视为长存对象。此举大幅缩短年轻代暂停时间，因在Survivor复制15次才晋升的对象实际消耗大量时间。理想机制应跟踪对象平均年龄加速晋升，但现行机制非如此。鉴于年轻代回收间隔通常为10秒至数分钟，此设置不会导致”垃圾”晋升，仅延迟长存对象至混合回收处理。

-XX:SurvivorRatio=32

因大幅降低晋升阈值，Survivor区利用率锐减，故释放更多区域供Eden使用。

-XX:+AlwaysPreTouch

启动时预占内存确保连续分配，提升内存访问效率。使用透明大页（注：Transparent Huge Pages，Linux内存管理特性）时必需启用。

-XX:+DisableExplicitGC

许多插件试图调用垃圾回收（System.gc()），触发Full GC导致严重卡顿。此参数禁用插件显式GC，规避劣质代码影响。

-XX:MaxGCPauseMillis=200

此参数控制新生代内存范围的使用策略，是期望的单次GC暂停时间目标。200ms目标对应至多4刻（tick）损失，虽致短暂TPS下降，但服务器可瞬时弥补，对TPS无实质影响（玩家无法感知200ms卡顿）。测试表明，过低值将致G1回收不足，可能耗尽老年代触发Full GC。设为200不意味每次回收均达200ms，而是允许GC在必要时用足此时间执行任务。

-XX:+ParallelRefProcEnabled

优化GC弱引用检查的多线程处理。不解为何非默认启用。

-XX:G1RSetUpdatingPauseTimePercent=5

默认暂停期间10%时间更新RSet（注：记忆集，记录跨代引用），降至5%以提升并发性缩短暂停。

-XX:G1MixedGCCountTarget=4

默认值8。因目标为降低回收速度及老年代使用率，需加速回收老年代内存防耗尽。

-XX:G1HeapRegionSize=8M

默认值自动计算。对MC（尤其1.15）至关重要——内存不足时默认值通常过低。任何超此值一半（4MB）的分配将视为”巨型对象”直进老世代且难释放。使用默认值将致大量内存被判定为巨型对象。

-XX:+PerfDisableSharedMem

GC写入文件系统时若磁盘IO过高可能引发高延迟——详见https://www.evanjones.ca/jvm-mmap-pause.html。

使用大页（Large Pages）

使用大页时，-Xms=-Xmx更为关键！大页需完全占用指定内存，否则无法获益。此内存本不会被系统挪用，故请用足。
另添加以下参数（Metaspace仅Java 8可用，Java 7勿用）：

-XX:+UseLargePagesInMetaspace

透明大页（Transparent Huge Pages）

争议性功能，若主机无法配置真实HugeTLBFS时可尝试。添加-XX:+UseTransparentHugePages，但必须同时启用AlwaysPreTouch，否则THP或适得其反。未实测THP对MC的影响及与AlwaysPreTouch的交互，本节供高级用户实验参考。

致谢

感谢https://product.hubspot.com/blog/g1gc-fundamentals-lessons-from-taming-garbage-collection深化我对参数的理解并推动改进！

更新日志

• 2020年5月2日：添加+PerfDisableSharedMem，MixedGCTarget调整为4
• 2020年4月25日：移除OmitStackTraces（部分插件或存性能问题）
• 2020年4月5日：参数建议重大重构，采用新策略优化暂停时间。参数或继续调整。MC 1.15必须应用此变更
• 2018年10月4日：移除AggressiveOpts及InitiatingHeapOccupancyPercent。AggressiveOpts在Java 11删除，IHOP在Java 11或损性能。Java 8用户也应移除
• 2018年8月18日：MixedGCLiveThreshold由50调至35，确保混合回收提早启动；增补10GB内存建议；扩充参数文档
• 2018年5月24日：添加-XX:+ParallelRefProcEnabled