CMS被淘汰而G1成为分水岭，因其并发标记无法处理浮动垃圾且易退化为Serial GC；G1通过Region划分与Remembered Set实现标记与回收解耦，采用“并发标记+并行复制”模式。
为什么 CMS 被淘汰而 G1 成为分水岭
CMS 的 concurrent-mark 阶段虽能并发执行，但无法处理浮动垃圾（floating garbage），且一旦发生 Concurrent Mode Failure 就会退化为 Serial GC 全停顿。G1 把堆划分为 Region，用 Remembered Set 精确跟踪跨区引用，让并发标记（concurrent marking cycle）和并行回收（evacuation）真正解耦——标记阶段只扫描存活对象，回收阶段才决定哪些 Region 要复制、压缩、清理。
关键区别在于：CMS 是“并发标记 + 并发清除”，G1 是“并发标记 + 并行复制”，ZGC/Shenandoah 更进一步把复制也做成并发。
如何配置 G1 实现吞吐与停顿的动态平衡
G1 不靠固定周期触发 GC，而是基于预测模型，在满足 -XX:MaxGCPauseMillis 前提下尽可能少做 GC。但这个目标不是硬性保证，而是统计意义上的概率目标（默认 90% 的暂停 ≤ 设定值）。
-
-XX:MaxGCPauseMillis=200：设得太低（如 50ms）会导致 GC 频繁、吞吐骤降；设得太高（如 1000ms）则失去低延迟意义 -
-XX:G1HeapRegionSize必须是 2 的幂（1MB~4MB），影响 Remembered Set 大小和扫描粒度；小 Region 提高精度但增加元数据开销 - 不要手动设置
-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent，G1 会根据 pause 目标自动伸缩年轻代——除非你观察到 young GC 过于频繁且每次回收量极小 -
-XX:G1MixedGCCountTarget=8控制混合回收中老年代 Region 的清理节奏；值越小，单次混合 GC 压力越大，但总耗时可能缩短
并发标记启动时机与常见误判
G1 的并发标记周期不是在堆满时才启动，而是在堆使用率达到 InitiatingOccupancyFraction（默认 45%）时触发初始标记（Initial Mark），该阶段需 STW，但极短（通常
容易踩的坑：
- 误以为
-XX:InitiatingOccupancyFraction=20就能“更早清理”，结果导致标记周期太频繁，反而抬高 CPU 占用、挤占应用线程资源 - 忽略
G1ReservePercent（默认 10%）——这是预留空间，防止混合回收时无空闲 Region 可用；若老年代碎片严重又没留够，会触发 Full GC - 监控时只看
G1 Evacuation Pause，却漏掉G1 Humongous Allocation引发的意外停顿：大对象（>½ Region）直接分配在巨型 Region，不参与复制，易造成碎片和隐式 Full GC
ZGC 的“染色指针”如何绕过传统并发难题
ZGC 不用写屏障维护 Remembered Set，而是把标记信息直接编码进 64 位指针的高 bits（metadata bits），通过读屏障（Load Barrier）在对象加载时检查并修正标记状态。这意味着：
- 并发标记和并发移动（
Concurrent Relocation）可真正重叠，STW 阶段只剩初始标记和最终标记中的极小部分（通常 - 无需分代假设，所有 Region 统一管理，避免 G1 中年轻代/老年代策略冲突
- 但 ZGC 要求 Linux kernel ≥ 4.14（支持 userfaultfd）、JDK ≥ 11（生产可用从 JDK 15 开始），且堆大小建议 ≥ 8GB 才显优势
真正难的是内存页映射与 TLB 刷新的协同——ZGC 在 relocate 后必须确保所有 CPU 核心的 TLB 条目失效，这步由 OS 协助完成，也是它对内核版本敏感的根本原因。
