CMSvsG1/ZGC性能对比详解

本文深入剖析了CMS、G1与ZGC三大垃圾收集器的性能演进脉络，揭示其核心突破并非单纯追求吞吐速度，而是围绕停顿时间可控性、大堆内存适应性及内存碎片治理能力的持续升级：CMS作为低延迟先驱虽实现“尽量少停”，却因标记-清除算法导致碎片化严重、Full GC不可控；G1通过分区设计与可预测停顿模型达成“可设上限”的稳定低延迟；而ZGC则借助着色指针与读屏障等创新技术，真正迈向“几乎不停”的毫秒级（甚至亚毫秒级）停顿新境界——这不仅是JVM内存管理的技术跃迁，更是现代高并发、大流量系统对极致响应能力的必然回应。

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 的额外资源开销。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。