HotSpot JVM 提供了多种垃圾回收器。不同收集器面向不同目标：有的追求简单，有的追求吞吐，有的追求低延迟，有的适合大堆。

1. Serial GC

Serial 是单线程收集器。

特点：

• 实现简单。
• 回收时会 STW。
• 适合单核、小内存、客户端或测试环境。

参数：

-XX:+UseSerialGC

2. Parallel GC

Parallel 是吞吐量优先的并行收集器。

特点：

• 多线程 GC。
• 注重整体吞吐。
• 停顿时间可能较长。
• 适合批处理、后台计算任务。

参数：

-XX:+UseParallelGC

3. CMS

CMS 是以降低老年代停顿为目标的并发标记清除收集器。

特点：

• 老年代并发标记和清除。
• 停顿比传统老年代收集器短。
• 会产生内存碎片。
• 对 CPU 资源敏感。

CMS 已在 JDK 14 中移除，现代 JDK 不应再把 CMS 作为新系统选型。

4. G1

G1 是面向服务端应用的低停顿收集器。

特点：

• 使用 Region 管理堆。
• 支持可预测停顿目标。
• 兼顾吞吐和延迟。
• JDK 9 起成为服务端默认 GC。

参数：

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

5. ZGC

ZGC 是可扩展低延迟收集器。

特点：

• 面向超低停顿。
• 大部分工作并发执行。
• 适合大堆和低延迟应用。
• JDK 15 成为生产可用。
• JDK 21 引入分代 ZGC。

参数：

-XX:+UseZGC

6. Shenandoah

Shenandoah 也是低停顿收集器，目标是通过并发压缩降低 GC 停顿。

参数：

-XX:+UseShenandoahGC

不同 JDK 发行版对 Shenandoah 的支持情况可能不同，选型时要结合实际运行时。

7. 如何选择

粗略建议：

场景	可考虑
小工具、小内存	Serial
批处理、高吞吐	Parallel
普通服务端应用	G1
大堆、低延迟	ZGC 或 Shenandoah
老 JDK 8 低停顿历史系统	CMS，但应规划升级

8. 阶段小结

垃圾回收器选型要看业务目标：吞吐、延迟、堆大小、JDK 版本、团队经验和可观测性。现代服务端应用默认从 G1 开始评估，低延迟大堆场景再考虑 ZGC 或 Shenandoah。

9. 收集器发展脉络

Serial
  │  单线程，简单
  ▼
Parallel
  │  多线程，吞吐优先
  ▼
CMS
  │  并发标记清除，降低老年代停顿，但有碎片
  ▼
G1
  │  Region 化，可控停顿，服务端默认选择
  ▼
ZGC / Shenandoah
     并发移动对象，低延迟，大堆友好

从演进方向看，GC 一直在尝试解决两个核心矛盾：

• 堆越来越大，但停顿不能越来越长。
• 应用延迟要求越来越高，但对象分配仍然很频繁。

10. 收集器能力对比

收集器	关注目标	是否压缩	停顿特点	典型场景
Serial	简单、小内存	是	长 STW	小工具
Parallel	吞吐量	是	STW 但多线程	批处理
CMS	低停顿	否	并发标记，碎片风险	老 JDK 低延迟系统
G1	可控停顿	是	Young/Mixed GC	普通服务端
ZGC	极低停顿	是	大部分并发	大堆低延迟
Shenandoah	极低停顿	是	并发压缩	低延迟场景

11. 选型流程

是否是现代 JDK 服务端应用？
  │
  ├─ 是 -> 先用 G1 建基线
  │       │
  │       ├─ 延迟满足 -> 保持，少调参数
  │       │
  │       └─ P99/P999 受 GC 明显影响
  │              └─ 评估 ZGC / Shenandoah
  │
  └─ 否 -> 看 JDK 版本和业务目标
          ├─ 批处理吞吐 -> Parallel
          └─ 小内存工具 -> Serial

选型后要压测。GC 不是只看官方宣传，而是要看你的对象模型、分配速率和延迟目标。

12. Tips 快问快答

Q：G1 一定比 Parallel 快吗？

A：不一定。G1 更关注可控停顿，Parallel 在纯吞吐批处理场景可能更合适。

Q：CMS 还能用吗？

A：CMS 已在 JDK 14 移除。老 JDK 8 存量系统可能还在用，但新系统不建议选 CMS。

Q：ZGC 是不是最好的 GC？

A：不是。ZGC 低停顿很强，但也有 CPU、版本和观测成本。小堆普通服务不一定需要。

Q：换 GC 能解决内存泄漏吗？

A：不能。泄漏对象仍然可达，换收集器最多改变爆发速度。