G1停顿可预测性依赖Region模型实际运行，需合理设置Region大小、积累历史数据并动态调整回收决策。默认Region大小为1MB～32MB，大堆建议显式设为4M或8M；Region总数应≥2048；冷启动需20次GC建立收益模型；Mixed GC的CSet由回收价值、误差校正和老年代压力共同决定；Humongous Region易引发长停顿，需监控避免。

G1不是靠“设个参数就稳了”的收集器，它的可预测停顿依赖Region模型真正跑起来——也就是Region划分得当、历史数据积累够、回收决策能动态响应。光调-XX:MaxGCPauseMillis没用，关键在让每个Region的「回收价值」被准确识别和排序。

Region大小必须匹配堆规模与对象特征

Region不是越小越好，也不是越大越省事。默认大小由JVM按堆总大小自动计算（1MB～32MB，且为2的幂），但实际业务中常需干预：

• 堆≤16GB时，默认值通常可用；堆≥32GB，建议显式设置-XX:G1HeapRegionSize=4m或8m——尤其当多数对象在200KB～1MB之间，避免默认32MB导致单Region evacuation耗时飙升
• Region总数应≥2048，否则JVM会放大单Region尺寸，削弱粒度控制能力；例如-Xmx64g -XX:G1HeapRegionSize=4m可得16384个Region，远超下限
• 避免过小（如1MB）：64GB堆将生成65536个Region，Remembered Set元数据膨胀，拖慢并发标记阶段

停顿预测依赖冷启动期的真实样本

G1的预测模型不是开箱即用的，它靠前20次GC逐步建立每个Region的「收益/耗时比」。刚启动时，即使设了MaxGCPauseMillis=200，实际停顿也可能达300ms以上：

• 衰减平均值（davg）和标准偏差（dsd）至少需要5次有效回收才能初步收敛
• 某些Region若持续表现为“垃圾少但耗时长”（比如含大量finalize()的对象），G1会逐步调低其优先级——但这必须基于真实回收观测，不能靠预设
• 冷启动阶段建议开启-Xlog:gc*,safepoint，重点看Evacuation Pause各子阶段耗时分布，而不是只盯总暂停时间

Mixed GC中的CSet是动态博弈结果

Mixed GC每次选多少老年代Region进CSet，由三股力量实时平衡：

• 回收价值排序：按(Region Size − Live Data) / 预估耗时打分，优先挑垃圾占比高、RSet小、存活数据少的Region
• 历史误差校正：连续两次超时，本轮CSet自动减1～2个Region；多次显著低于目标（如120ms vs 200ms），则试探性增加
• 老年代压力信号：当老年代占用率明显高于IHOP阈值（如达65%），G1会主动放宽停顿约束，多选Region防Full GC

Humongous Region是隐性停顿放大器

只要对象≥50% Region大小，就会触发Humongous分配——这是停顿突增最隐蔽的源头：

• Humongous Region不参与Young GC，仅在Mixed GC Cleanup阶段或Full GC时回收
• 回收时必须一次性锁定全部关联Region（包括StartsHumongous及其后续连续Region），STW时间不可拆分
• 监控建议：通过-Xlog:gc+humongous观察大对象分配频率；若频繁出现，需检查业务是否无意创建巨型缓存或未分片的数据结构