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 仍然是多数企业的主流选择。