jdk 21分代zgc通过动态分代与并发回收实现亚毫秒停顿，但需调优晋升阈值（如-xx:maxtenuringthreshold=10–15）、避免硬设新生代大小、保持minor gc频率1–3秒，并启用透明大页禁用以保障zrelocate性能。
JDK 21 的 Generational ZGC 是目前唯一能在超高分配速率（如每秒数 GB）下仍稳定维持亚毫秒级停顿的 GC 方案，但它不是开箱即用的“银弹”——必须针对性配置内存结构和回收节奏，否则反而会因晋升过快或新生代过小触发频繁 Allocation Stall。
为什么默认 ZGC 在高分配场景下容易卡住
不分代的 ZGC（JDK 11–20）每次 GC 都要扫描整个堆，哪怕 95% 的对象生命周期
-XX:+ZGenerational 必须显式启用，且依赖 -XX:+UseZGC
这两个参数缺一不可，顺序无关，但漏掉 -XX:+ZGenerational 就退化回旧版 ZGC：
java -XX:+UseZGC -XX:+ZGenerational -Xmx32g -jar app.jar
注意：-XX:+UnlockExperimentalVMOptions 在 JDK 21 中已废弃，不再需要；若加了反而报错。
常见错误现象：
- 日志里看不到
Young或Minor字样，只有ZGC Pause Mark Start—— 说明分代没生效 - 使用
jstat -gc <pid></pid>查看，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=10提高到 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。
