CMS / G1 / ZGC：收集器怎么选？它们分别怎么工作？
你问“收集器怎么选”，其实是在问两件事：
- 吞吐量优先还是延迟优先
- 你的堆有多大、停顿目标（RT）有多苛刻
这篇先把主线讲清楚：
- CMS 为什么曾经流行
- G1 为什么成为很多项目的默认选择
- ZGC 解决的是什么问题
1. 你需要先会分清：吞吐量 vs 延迟
- 吞吐量优先：单位时间处理更多请求（允许更长停顿）
- 延迟优先：单次停顿必须短且可控（RT 稳定）
大多数在线服务更关心：
- 延迟稳定性（尤其是 P99/P999）
2. CMS：低停顿的老年代并发收集器（历史重点）
CMS 的核心特点：
- 老年代并发标记/清理，尽量减少 STW
你只要记住它的经典问题：
- 碎片问题：标记清除容易产生碎片
- 并发失败：回收赶不上分配，可能退化成 Full GC
- 对 CPU 资源更敏感
工程上 CMS 常见的“感受”：
- 平时停顿短
- 但偶尔会出现一次很长的 Full GC
3. G1：Region 化 + 可预测停顿
G1 的核心思路：
- 把堆切成多个 Region
- 每次回收按“收益”挑选 Region
- 目标是满足你设定的停顿时间目标
你只要先记住三个关键词：
- Region
- Remembered Set（跨 Region 引用记录）
- 按收益回收（收益高的先回）
4. ZGC：超低停顿的并发收集器
ZGC 的定位很清晰：
- 更大的堆
- 更低的停顿
你可以把它理解成：
- 把更多工作并发化
- 尽量把 STW 的时间压缩到极短
但你要注意：
- 选择 ZGC 往往意味着你对延迟极其敏感
- 同时要考虑 JDK 版本与生产环境验证
5. 面试/实战都能用的选择逻辑
你可以按这个顺序回答“选哪个”：
- 堆大小：大堆更倾向选择对大堆友好的收集器
- 延迟目标：是否要求可预测停顿
- CPU 预算：并发收集会占用更多 CPU
- 业务特性：对象生命周期、峰值流量
一个常见的工程表述方式：
- 大部分在线服务：优先考虑G1
- 对极低停顿/超大堆：评估ZGC
- CMS：更多是“理解历史与排老系统”
6. 总结
- CMS：并发清理、碎片与并发失败是典型问题
- G1：Region 化 + 可预测停顿，很多项目的主力选择
- ZGC：更低停顿、更大堆的场景
- 选型永远回到：延迟目标 + 堆大小 + 资源预算