G1停顿预测模型基于历史Region回收数据拟合衰减平均值并叠加置信度生成预测，非定时触发；需运行8～10分钟让模型收敛，避免初期调参；新生代须动态伸缩，关键参数为G1NewSizePercent=20与G1MaxNewSizePercent=50。
停顿预测模型不是定时器，而是基于历史数据的回归估算
G1 的 MaxGCPauseMillis 不会触发“每 X ms 强制 GC”，它只在每次 GC 决策前，用过去若干次回收的 Region 成本（时间 + 回收量）拟合出一个衰减平均值，并叠加置信度系数生成预测。这意味着：如果刚启动 JVM，前 3～5 次 Young GC 的 pause 时间往往严重偏离目标——模型没足够样本；稳定运行后，G1 才真正开始“按预测选 Region 集合”。所以别在压测刚开始就调参，先让 GC 日志跑满 8～10 分钟再看分布。
GC 频率由新生代 Region 数量动态决定，而非固定大小
很多人手动设 -XX:NewRatio 或 -Xmn 试图锁死新生代，这反而破坏 G1 的预测模型。G1 必须自由伸缩 Eden/Survivor Region 数量，才能在 MaxGCPauseMillis 约束下调整单次 Young GC 的工作量。关键参数是：
-
-XX:G1NewSizePercent=20和-XX:G1MaxNewSizePercent=50：把新生代浮动范围收窄，避免 Eden 区忽大忽小导致 pause 波动剧烈 - 不设
-XX:G1HeapRegionSize：除非堆 >32GB 且对象普遍偏大，否则让 JVM 自动选 1～4MB Region，太大会让单 Region 回收时间不可控 - 观察
jstat -gc <pid>中YGCT（Young GC 总耗时）和YGC（次数）比值：若比值持续 >80ms，说明新生代被撑得太满，G1 被迫频繁回收小块 Region，此时应适当提高堆总大小或降低对象分配速率
Mixed GC 的“步长”由回收价值排序与目标时间共同截断
Mixed GC 不是一次性扫光所有老年代 Region，而是按 Remembered Set 标记的跨 Region 引用密度 + 垃圾占比算出每个 Region 的“回收价值”，排成优先队列。G1 从队头开始累加预估耗时，一旦接近 MaxGCPauseMillis 就停止——这个截断点就是实际步长。因此：
- 若 Mixed GC 频次低但单次 pause 超标，说明老年代 Region 垃圾密度低或跨 Region 引用太多，需检查是否有长期存活的缓存对象未及时清理
-
-XX:G1MixedGCCountTarget=4比默认 8 更激进：每次回收更少的老年代 Region，但周期内执行更多轮 Mixed GC，适合 P99 延迟敏感服务 - 日志里看到大量
Humongous allocation记录，意味着大对象直接进老年代，它们不参与 Mixed GC，却持续占用 Region 并拖慢并发标记进度——这是隐性步长干扰源
验证预测是否生效，必须看 pause 时间直方图而非均值
用 -Xlog:gc*,gc+pause=info:file=gc.log:time,tags 启用 JDK 10+ 日志后，grep "GC pause (G1 Evacuation Pause)"，提取末尾的 secs 值（如 0.1423872secs）。重点不是算平均值，而是统计：
- 90% 的 pause ≤
MaxGCPauseMillis× 0.8？——说明模型收敛良好 - 是否存在连续多个 >200ms 的 spike？——大概率是 Evacuation Failure 或 Humongous Region 拷贝阻塞
- Young GC 和 Mixed GC 的 pause 分布是否分离？若混合在一起，说明 G1 无法区分代际压力，可能因
G1NewSizePercent过低导致新生代 Region 不足
真正难调的从来不是参数本身，而是理解 G1 如何用 Region 成本历史去赌下一次回收的效率——它永远在试探边界，而你的任务是不让它输得太难看。
