G1已取代CMS，因其可预测停顿、无内存碎片、统一管理整堆；CMS仅处理老年代、易触发秒级Full GC且产生碎片，JDK9废弃、JDK14移除。
G1 收集器整体上已取代 CMS，不是因为“更先进”，而是因为它在关键痛点上给出了更可靠的解法：可预测停顿、无碎片、统一管理新生代与老年代。CMS 在 JDK 9 中被标记为废弃，JDK 14 正式移除，这一演进背后是真实生产环境的反馈。
内存模型与工作范围不同
CMS 是老年代专用收集器，必须搭配 ParNew（或 Serial）处理新生代，属于“组合式”方案；G1 是全域收集器，把整堆划分为多个固定大小 Region（默认 2048 个），每个 Region 动态承担 Eden、Survivor、Old 或 Humongous 角色，不再有物理分代边界。
- CMS 老年代采用连续大块内存，大对象直接进入，易因空间不连续触发 Full GC
- G1 引入 Humongous Region，专存超大对象（>50% Region 大小），避免跨 Region 引用和晋升扰动
- G1 的 Region 模型天然支持增量回收——每次只选若干高收益 Region 回收，而非整代扫描
停顿时间控制机制不同
CMS 声称“低停顿”，但实际不可控：初始标记和重新标记阶段 STW 时间随老年代存活对象数增长而波动，且并发失败（Concurrent Mode Failure）会直接退化为 Serial Old 全堆单线程 GC，停顿可达数秒。
- G1 通过 -XX:MaxGCPauseMillis（如设为 200ms）设定目标，JVM 动态调整每次 Mixed GC 回收的 Region 数量与类型，使 STW 尽量贴近该值
- G1 的 STW 阶段仅出现在初始标记、最终标记、筛选回收（Evacuation）三个环节，其中筛选回收是真正移动对象的阶段，耗时可控
- CMS 的并发标记虽不 STW，但会抢占 CPU 资源，导致应用吞吐下降；G1 的并发标记也需 CPU，但其 Evacuation 阶段可并行多线程执行，资源利用更均衡
内存碎片与算法本质不同
CMS 使用标记-清除（Mark-Sweep），回收后留下大量不连续空闲块，长期运行后即使老年代剩余空间充足，也可能因无法分配大对象而触发 Full GC。
- CMS 可通过 -XX:+UseCMSCompactAtFullCollection 在 Full GC 后压缩，但压缩本身是 STW 且极耗时，治标不治本
- G1 整体采用标记-整理（Mark-Compact），回收时将存活对象复制到新 Region，旧 Region 整块释放，彻底消除碎片
- G1 局部使用复制算法（Region 间），全局体现为整理效果，既避免 CMS 的碎片问题，又不像 Serial Old 那样需要全堆移动
适用场景与运维复杂度不同
CMS 对 JVM 参数敏感，调优门槛高：比如 -XX:CMSInitiatingOccupancyFraction 设低了频繁 GC，设高了易并发失败；而 G1 更“自适应”，多数参数可缺省，依赖 JVM 自动决策。
- CMS 适合堆不大（
- G1 适合堆中等至大（4GB–64GB）、要求稳定低延迟、存在大对象或长周期服务（如微服务、实时风控）的场景
- JDK 8u40+ 开始 G1 性能趋稳，JDK 9 起成为默认 GC，JDK 14 彻底删除 CMS——这不是版本迭代，而是工程实践的淘汰
