怎么利用 JDK 21 的 Generational ZGC 实现在超高分配速率下的极低延迟垃圾回收

先说一个关键判断：JDK 21 的 Generational ZGC 是目前唯一能在超高分配速率——比如每秒数 GB 的吞吐——下，仍然稳定维持在亚毫秒级停顿的 GC 方案。但别指望它是开箱即用的“银弹”。如果不对内存结构和回收节奏做针对性配置，反而会因为晋升过快或者新生代太小，频繁触发 Allocation Stall，把低延迟优势彻底葬送掉。

JDK 21 分代 ZGC 通过动态分代与并发回收实现亚毫秒停顿，但需调优晋升阈值（如 -XX:MaxTenuringThreshold=10–15）、避免硬设新生代大小、保持 Minor GC 频率 1–3 秒，并启用透明大页禁用以保障 ZRelocate 性能。

为什么默认 ZGC 在高分配场景下容易卡住

不分代的 ZGC（JDK 11–20）每次 GC 都要扫描整个堆，哪怕 95% 的对象生命周期短得可怜，也逃不过全堆遍历。这在分配速率低的时候还能忍受，一旦速率飙升，停顿时间就会像脱缰的野马。分代 ZGC 把年轻代和老年代分开处理，但如果你不主动调优，默认参数根本扛不住。

-XX:+ZGenerational 必须显式启用，且依赖 -XX:+UseZGC

这两个参数缺一不可，顺序无所谓，但漏掉 -XX:+ZGenerational 就退化成旧版 ZGC。正确写法如下：

ja va -XX:+UseZGC -XX:+ZGenerational -Xmx32g -jar app.jar

注意：JDK 21 中 -XX:+UnlockExperimentalVMOptions 已经废弃，不需要再加；加了反而报错。

判断分代是否生效有个很直观的方法：看 GC 日志里有没有 Young 或 Minor 字样。如果只看到 ZGC Pause Mark Start，说明分代没生效。另一个快速验证是用 jstat -gc ，如果 YGCT（年轻代 GC 次数）始终为 0，那基本可以断定分代没跑起来。

调优新生代大小：别信默认值，按分配速率反推

JDK 21 默认 -XX:ZNewSizePercent=1，新生代最小占比只有 1%。对 32GB 堆来说，这意味着新生代只有 320MB——在高分配场景下，撑不过 100ms 就会被打满。必须主动放大。

• 对于短期对象密集型服务（比如网关、实时风控），建议设置 -XX:ZMaxNewSizePercent=40，让新生代可以弹性扩到 12.8GB。
• 观察 ZStatistics 输出里的 Young Generation Allocated 和 Promotion Rate，如果晋升率超过 5%/s，说明新生代还是偏小，或者对象存活时间被误判了。
• 避免固定新生代大小（比如直接用 -XX:ZNewSize），Region-based 设计下硬指定很容易导致内存碎片。

防止过早晋升：用 -XX:MaxTenuringThreshold 控制对象“成年”门槛

默认阈值是 6 次 Minor GC，但在高分配+低延迟场景下，很多对象其实只活 2–3 次 GC 就该死了。如果它们被提前晋升到老年代，就会污染老年代扫描范围，拖慢 Major GC。

实操建议：

• 先开启统计：-XX:+ZStatistics -Xlog:gc*,zstats=debug
• 检查日志中 Promoted bytes 是否集中在第 2–3 次 GC 后激增；如果是，把 -XX:MaxTenuringThreshold 从默认的 6 提高到 10–15。
• 不要设为 0（禁用晋升）——这会导致年轻代 Region 无法释放，最终 OOM。

真正难处理的是那些“半衰期模糊”的对象：既不立刻死，又不长期活。Generational ZGC 会动态调整晋升决策，但前提是留给它足够观测窗口——所以保持 Minor GC 频率在 1–3 秒一次比较合理，靠 -XX:ZCollectionInterval 强控不如靠新生代大小自然调节。

最后提醒一点：Generational ZGC 的并发能力依赖操作系统内存页支持。在 Linux 上需要启用 transparent_hugepage=never，这点常被忽略，却会导致 ZRelocate 阶段延迟陡增。不是 JVM 参数能解决的，得查 /sys/kernel/mm/transparent_hugepage/enabled。