CMS、G1、ZGC、Shenandoah 的全面对比
大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！
Java 垃圾回收器从最早的 Serial 一步步演化，如今已经有了多款高性能、低延迟的 GC 垃圾收集器可选，比如 CMS、G1、ZGC、Shenandoah。到底它们有啥区别？适合哪些业务场景？一文讲透👇
🧠 GC 垃圾收集器发展图谱
Serial -> Parallel -> CMS -> G1 -> ZGC / Shenandoah
注：JDK8 以前主要是 CMS 和 Parallel，JDK9 之后 G1 成为默认收集器，JDK11+ 后 ZGC、Shenandoah 崭露头角。
📦 各主流 GC 收集器全景对比
| 收集器 | 停顿时间 | 吞吐量 | 并发回收 | 吞吐目标/延迟目标 | 特点 | 适用场景 |
|---|---|---|---|---|---|---|
| CMS | 低 | 中等偏高 | ✅ 是 | 响应时间优先 | 老年代并发回收，减少 STW 时间 | 响应敏感型应用，如 Web 服务 |
| G1 | 中等 ~ 低 | 中等 | ✅ 是 | 吞吐 & 延迟均衡 | 分区收集，避免碎片，JDK 默认选项 | 混合型业务，JDK 默认选择 |
| ZGC | 极低（<10ms） | 中等 | ✅ 是 | 极低延迟（毫秒级） | 彩色指针、Region 化，支持 TB 级堆 | 低延迟系统、超大内存应用 |
| Shenandoah | 极低（<10ms） | 中等 | ✅ 是 | 极低延迟（毫秒级） | 并发整理，空闲 compact，不需 stop | 响应敏感场景，如在线支付系统 |
🔍 收集器特性深度解析
♻️ CMS（Concurrent Mark Sweep）
-
工作方式：并发标记+并发清除，最早的低停顿收集器之一。
-
优点：
- 大部分阶段与用户线程并发执行；
- 停顿时间远低于 Serial / Parallel。
-
缺点：
- 容易产生“内存碎片”；
- Stop-the-World 多次触发；
- 即将被 G1 替代（JDK 9 之后已标记为废弃）。
🔧 适合场景：老年代对象存活率高，业务对响应时间敏感。
🧬 G1（Garbage First）
-
设计目标：兼顾吞吐量和低延迟。
-
特点：
- 分区（Region）机制；
- 可预测的停顿时间；
- 支持部分并发整理。
-
缺点：
- 相较 CMS 停顿更稳定，但最大停顿时间不一定更短；
- 吞吐量略低于 CMS/Parallel。
🔧 适合场景：电商、社交类中大型项目，推荐默认使用。
⚡️ ZGC（Z Garbage Collector）
-
目标：亚毫秒级别 GC 停顿（<10ms），支持 TB 级内存。
-
特点：
- 彩色指针+读屏障；
- Region 化内存布局；
- 几乎全并发，GC 不影响用户线程；
- 从 JDK 15 起正式可用于生产。
-
缺点：
- 目前仅支持 Linux / macOS / Windows 的 64 位系统；
- 最大吞吐量略低。
🔧 适合场景：低延迟需求极高的服务（如金融风控、广告系统）。
🛰️ Shenandoah
-
目标：低延迟（<10ms）+ 并发整理，真正“Pause Time 不随堆大小增长”。
-
特点：
- 并发压缩对象，打破 CMS / G1 的 STW 整理局限；
- 与 ZGC 类似，也使用读屏障；
- 可在 JDK12+ 开启使用（JDK17 后正式生产可用）。
-
缺点：
- 实现复杂、CPU 开销略高；
- 与 G1 类似，吞吐量适中。
🔧 适合场景：低延迟、大堆内存项目，如物联网、即时计算平台。
🧭 选型建议
| 业务场景 | 推荐 GC | 说明 |
|---|---|---|
| 吞吐优先 | Parallel GC | 简单粗暴，STW 时间长但效率高 |
| 响应时间优先 | CMS / Shenandoah | 停顿低，适合 Web、支付类系统 |
| 低延迟、超大堆内存 | ZGC / Shenandoah | 停顿极低，支持 TB 级堆 |
| 默认 JDK 设置 | G1 | 综合性能均衡，几乎无脑选 |
🔚 写在最后
GC 没有“银弹”，只有“适合”。理解各种 GC 的特点后，结合业务特性才能做出最佳选择。未来，ZGC 和 Shenandoah 正逐步成为低延迟服务的标配，而 G1 仍然是多数企业的主流选择。