g1在堆内存超4gb后仍保持可控停顿与高效回收，而cms因老年代全扫描、无整理及碎片化导致停顿飙升和频繁full gc；g1通过region分区、mixed gc优先回收高垃圾比region、humongous region单独管理等机制解决cms三大硬伤。
G1 在堆内存超过 4GB 后，停顿时间仍可控、回收效率不衰减；CMS 则会因老年代扫描范围过大、碎片加剧，导致停顿飙升甚至频繁 Full GC。
Region 分区让回收范围可预测、可限制
G1 把整个堆切分成约 2048 个大小相等的 Region（默认 1–32MB），每个 Region 独立管理，角色可动态切换（Eden、Old、Humongous）。这意味着：
- 回收不再绑定“整代”——
Young GC只扫Eden和Survivor Region，Mixed GC只挑垃圾占比高、成本低的老年代Region，避免 CMS 那样每次都要扫描整个老年代 - 大堆下，Region 数量线性增长，但单次回收的 Region 数由
-XX:MaxGCPauseMillis动态约束，停顿时间几乎不随堆增大而恶化 - CMS 的老年代是连续大块内存，标记-清除过程必须遍历全部已用空间，堆越大，标记耗时越长，且无法拆分控制
混合回收（Mixed GC）替代全老年代扫描
CMS 对老年代只做并发标记-清除，不整理，也不分片；G1 的 Mixed GC 是它应对大堆的核心机制：
- 在并发标记周期完成后，G1 构建“回收价值优先级列表”，只选
GarbageFirst的 Region（比如垃圾占比 >50% 的Old Region）加入Collection Set - 一次
Mixed GC可能只回收几十个 Region，而非整个老年代，STW 时间稳定在毫秒级（实测 32GB 堆下平均 - CMS 一旦并发失败（
Concurrent Mode Failure）或碎片导致大对象分配失败，立刻退化为单线程Full GC，停顿可达数秒
Humongous Region 隔离大对象，避免老年代雪崩
大对象（> 单个 Region 容量 50%）在 G1 中直接进入 Humongous Region，这带来关键区别：
- 不占用普通
Old Region的连续空间，从根源上缓解 CMS 那种“老年代空闲但无法分配大对象”的碎片困局 -
Humongous Region在Mixed GC或后续并发周期中可被单独识别和回收，不像 CMS 中的大对象长期钉在老年代，持续推高占用率 - 若设置不当（如
-XX:G1HeapRegionSize=1m在 16GB 堆上），Humongous Region过多会导致元数据（RSet）开销暴涨，反而降低有效内存 —— 所以堆 >8GB 时建议显式设为16m
大堆下 CMS 的三个不可逆瓶颈
不是参数调优能绕开的硬伤：
-
Concurrent Mode Failure触发概率随堆增大而上升：CMS 预留的“浮动垃圾”缓冲区（initiating occupancy）在大堆中更难精准预估 - 标记阶段需扫描整个老年代，CPU 缓存局部性差，多核并行效率迅速下降；G1 的 Region 局部性天然适配现代 CPU 的缓存行
- 没有压缩机制，运行数天后老年代碎片率常超 30%，此时哪怕总占用率仅 60%，也会因无法容纳新晋升对象而触发
Full GC
Region 不是银弹——它引入了 RSet 和卡表维护开销，但对 ≥4GB 堆而言，这个代价远低于 CMS 的碎片治理成本和不可控停顿。真正容易被忽略的是：InitiatingHeapOccupancyPercent 默认 45%，在大堆高频写入场景下往往过低，应结合 GC 日志观察并发标记启动时机，必要时调高到 60–70。
