CMS、G1、ZGC性能演进聚焦停顿可控性、大堆适应性、碎片治理：CMS“尽量少停”但碎片致Full GC不可控；G1实现“可设上限”停顿；ZGC迈向“几乎不停”。
CMS、G1 和 ZGC 的性能演进不是简单“谁更快”，而是围绕停顿时间可控性、大堆适应性、碎片治理能力三方面层层递进的升级。核心趋势是：从“尽量少停”（CMS），走向“可设上限”（G1），再迈向“几乎不停”（ZGC）。
CMS：低延迟先驱，但受限于碎片与不确定性
CMS 是首个主打并发回收的老年代收集器，靠“并发标记+并发清除”把 STW 时间压得很短。但它用的是标记-清除算法，不整理内存，长期运行后碎片堆积，容易触发 Full GC——这时停顿可能长达数秒，完全不可控。另外，并发阶段若业务分配太快，还会出现“concurrent mode failure”，直接 fallback 到 Serial Old，彻底失去低延迟意义。它适合堆不大（
- 典型停顿：2–200ms（波动大，依赖堆使用模式）
- 最大隐患：碎片导致的 Full GC 不可预测
- JDK 9 起已废弃，JDK 14 彻底移除
G1：分区化设计带来可预测性与自愈能力
G1 把堆切成固定大小 Region（1–32MB），不再严格区分新生代/老年代，而是按垃圾密度动态选择回收区域。“Garbage-First”就是优先清理收益最高的 Region。它在并发标记后做筛选回收，过程中会复制存活对象，天然完成局部压缩，大幅降低碎片风险。通过 -XX:MaxGCPauseMillis 可设定目标停顿（如 200ms），G1 会据此调整每次回收的 Region 数量和类型。
- 典型停顿：稳定在目标值附近（如设 200ms，实际多在 150–220ms）
- 优势：大堆（数十GB）下仍保持可控停顿，碎片少，Full GC 极少发生
- 代价：算法更重，吞吐量略低于 Parallel GC，JDK 8 中尚不成熟，JDK 9+ 成为默认
ZGC：面向超低延迟的全并发重构
ZGC 的目标是让 GC 停顿与堆大小解耦——无论堆是 4GB 还是 4TB，停顿都控制在 10ms 以内。它靠三项关键技术实现：彩色指针（Colored Pointer）记录对象状态，读屏障（Read Barrier）拦截对象访问并实时更新元数据，并发转移（Concurrent Relocation）全程不 STW 就完成对象复制与引用更新。ZGC 的 STW 阶段只剩极短的初始标记和最终标记（各约 1ms），其余全部并发。
- 典型停顿：平均 1–3ms，P99 ≤ 10ms，与堆大小无关
- 适用场景：金融风控、高频交易、实时推荐等对抖动零容忍的系统
- 约束：仅支持 64 位 Linux/macOS/Windows；CPU 开销略高；JDK 15+ 生产就绪
演进主线很清晰
从 CMS 到 G1，是用分区模型和部分整理解决碎片与不可控问题；从 G1 到 ZGC，是用硬件辅助（指针着色）+ 全并发流程消除 STW 瓶颈。这不是替代，而是分层适配：小项目用 Parallel，中大型服务用 G1，极致低延迟场景才上 ZGC。选型关键不在“新”，而在你的停顿敏感度、堆规模、以及能否承担新 GC 的额外资源开销。
