并行回收与标记平衡GC性能

本文深入剖析了现代Java垃圾回收器如何在吞吐量与停顿时间之间实现动态平衡，从CMS因无法处理浮动垃圾和易退化为Serial GC而被淘汰，到G1通过Region划分、Remembered Set和“并发标记+并行复制”架构实现标记与回收解耦，再到ZGC借助染色指针与读屏障将STW压缩至亚毫秒级；同时详解了G1关键参数（如MaxGCPauseMillis、G1HeapRegionSize、MixedGCCountTarget）的调优逻辑与常见误区，揭示了GC演进的本质——不是简单追求更低停顿，而是以可预测性、自适应性和内存管理精度为核心，在复杂业务负载下智能权衡系统响应与资源效率。

为什么 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 协助完成，也是它对内核版本敏感的根本原因。

今天关于《并行回收与标记平衡GC性能》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！