Java垃圾回收器演进深度解析：从CMS、G1到ZGC的实战选择指南

凌晨三点，监控告警骤然响起，核心服务的响应时间曲线飙升。登录服务器排查，发现一次Full GC竟耗时数十秒，元凶是CMS回收器在并发模式下遭遇了“并发模式失败”。对于Java开发者而言，类似由垃圾回收引发的服务抖动并不陌生。从经典的CMS到如今大放异彩的ZGC，了解其演进脉络并做出正确的版本选择，是保障应用稳定性的关键一步。

一、CMS：时代的功臣与局限

在G1回收器成为主流之前，并发标记清除（CMS）回收器曾是追求低延迟的Java应用，特别是Web服务的首选。其核心目标是通过与用户线程并发工作，最大限度减少垃圾收集导致的停顿（STW）。它的工作流程分为四步：

1. 初始标记：短暂的STW，标记GC Roots直接关联的对象。
2. 并发标记：与用户线程并发，遍历标记整个对象图。
3. 重新标记：第二次STW，修正并发标记期间因用户线程运行而产生的标记变动。
4. 并发清除：与用户线程并发，清理已标记的死亡对象。

然而，随着应用复杂度与内存容量的增长，CMS的固有缺陷逐渐暴露：

• 内存碎片化：其“标记-清除”算法不会整理内存，长期运行后产生大量内存碎片，可能导致“明明有足够总内存却因无连续空间而触发Full GC”的窘境。
• “并发模式失败”：若并发清理阶段用户线程申请内存过快，或碎片导致大对象无法分配，CMS会退化为由Serial Old触发的Full GC，产生长时间STW，这是其最典型的故障场景。
• 资源敏感：并发阶段与业务线程竞争CPU，可能降低应用吞吐量。
• 浮动垃圾：并发阶段新产生的垃圾无法被本次回收处理。

二、G1回收器：区域化设计与可预测停顿

JDK 9及之后版本的默认回收器G1（Garbage-First），旨在兼顾高吞吐量与可控停顿时间。它通过架构革新解决了CMS的核心痛点。

核心设计思想：

1. 区域化内存（Region）：将堆划分为多个大小相等的Region，物理上不连续。回收时以Region为单位进行。
2. 可预测停顿模型：通过参数-XX:MaxGCPauseMillis（默认200ms）设定目标停顿时间。G1会根据此目标，优先筛选回收收益（垃圾比例）最高的几个Region进行收集，这便是“Garbage-First”的由来。
3. 标记-整理算法：G1在回收选中的Region（回收集，Collection Set）时，会将其中存活对象复制到空闲Region，此复制过程天然完成了内存整理，彻底解决了碎片化问题。

实践建议与避坑：

• 合理设置停顿目标：避免在超大堆上设置过小的MaxGCPauseMillis（如10ms），这会导致G1为满足不切实际的目标而频繁回收，严重损害吞吐量。目标值应基于GC日志分析来设定。
• 警惕“疏散失败”：当G1复制对象时找不到空闲Region，会触发Full GC。适当增加堆大小或调整-XX:InitiatingHeapOccupancyPercent（IHOP，触发并发标记的老年代占用阈值）可缓解。

迁移案例：在一个从JDK 7（CMS）升级至JDK 8（G1）的电商订单系统中，最显著的改善并非平均响应时间，而是尾部延迟（如P99、P999）的稳定性。G1的混合回收（Mixed GC）将停顿严格控制在目标范围内，消除了CMS因碎片化导致秒级Full GC停顿的风险，极大增强了高并发下的服务韧性。

三、新时代的低延迟王者：ZGC与Shenandoah

JDK 11引入的ZGC和JDK 12可用的Shenandoah，目标更为激进：将STW停顿时间控制在10ms以下的毫秒级，且停顿时间不随堆容量增大而显著增加。这对于现代微服务与云原生架构至关重要。

ZGC的核心技术：

• 染色指针：将GC元数据（如标记、重定位状态）存储在64位指针的未使用比特位上，而非对象头中，减少了访问开销。
• 读屏障：在读取对象引用时插入的一小段代码，用于处理并发转移中的对象访问。这是实现“几乎全程并发”的关键，将并发工作成本分摊到了用户线程的每次指针加载上。
• 内存多重映射：通过虚拟内存技巧，使对象在转移期间新旧地址可同时被访问，实现平滑过渡。

Shenandoah同样实现了亚毫秒级停顿，其核心技术是“Brooks Pointer”和写屏障。两者在实现哲学上不同，但均为极致低延迟而生。

面试要点：ZGC/Shenandoah与G1的根本区别在于，它们通过读/写屏障技术，将对象复制/转移这一最耗时的阶段也做到了与用户线程并发执行，而G1在此阶段仍需STW。

配置模板：

# ZGC 基础启动参数 (JDK 11+)
java -XX:+UseZGC \
     -Xmx16g \                 # 设置堆大小
     -Xlog:gc*:file=gc.log:time \ # 输出详细GC日志，便于[监控与诊断](https://yunpan.plus/f/47-1)
     -XX:+ZGenerational \      # JDK 21+ 强烈建议启用分代ZGC
     -jar your-application.jar

# Shenandoah 基础启动参数 (JDK 12+)
java -XX:+UseShenandoahGC \
     -Xmx16g \
     -Xlog:gc*:file=gc.log:time \
     -jar your-application.jar

四、项目实战选择指南

面对众多选择，可遵循以下决策路径：

1. 首要目标是什么？

   • 高吞吐量（批处理、计算密集型）：优先考虑Parallel Scavenge（JDK 8）或G1。
   • 低延迟（Web服务、实时系统）：优先考虑G1、ZGC或Shenandoah。

2. 堆内存有多大？

   • 超大堆（>32GB甚至数TB）且要求低延迟：ZGC/Shenandoah是首选，其停顿时间几乎与堆大小无关。
   • 中小堆：G1、ZGC、Shenandoah均可，根据JDK版本决定。

3. 基于JDK版本的最终决策：

   • JDK 8：G1 (-XX:+UseG1GC) 是替代CMS的最佳选择，综合表现最成熟。除非堆极小且追求极致吞吐，否则不再建议使用CMS。
   • JDK 11 ~ JDK 17 (LTS)：追求低延迟、大堆场景，首选ZGC。Shenandoah是优秀的备选。若稳定性优先且对吞吐更敏感，G1依然可靠。
   • JDK 21+ (最新LTS)：分代ZGC (-XX:+UseZGC -XX:+ZGenerational) 已成为综合性能（吞吐与延迟）最强的王者，无脑推荐。分代Shenandoah (-XX:+UseShenandoahGC -XX:+ShenandoahGenerational) 是次选。

技术的演进让Java在面对海量数据与苛刻延迟要求时更加从容。升级JDK版本并选用合适的垃圾回收器，往往是提升系统性能最具性价比的策略之一。理解其原理，方能做出最适合自己应用场景的抉择。