CMS收集器专为老年代设计，以降低停顿时间为首要目标，但存在碎片多、并发失败风险高和CPU资源争抢等短板；适用于堆≤4GB、响应优先的系统，JDK14起已被移除。
CMS 收集器专为老年代设计，核心目标是压低停顿时间，但它在实际应用中是一把双刃剑——低延迟优势突出，但稳定性和扩展性存在明显短板。
优势：停顿短、并发强、响应快
它把最耗时的标记和清除操作放到与用户线程并发执行的阶段，只保留两次极短的 STW（初始标记和重新标记），整体停顿通常控制在几十毫秒内。这对 Web API、实时接口等响应敏感型服务非常友好。CMS 不干预新生代，专注老年代，职责清晰；配合 ParNew 使用，整套“ParNew + CMS”组合在 JDK 8 及更早版本中是低延迟场景的主流选择。
劣势：碎片多、失败风险高、资源争抢明显
采用标记-清除算法，不移动对象，长期运行必然产生内存碎片。当需要分配大对象却找不到连续空间时，会触发 Full GC，停顿瞬间飙升。并发阶段若用户线程持续分配或修改引用，可能造成“浮动垃圾”堆积；更严重的是，若老年代增长过快，CMS 来不及完成回收就填满，就会发生 Concurrent Mode Failure，直接退化为 Serial Old 式的单线程全堆扫描，STW 可达数秒。此外，CMS 对 CPU 资源敏感，并发线程与用户线程争抢 CPU，容易导致吞吐下降，尤其在四核以下机器上表现更明显。
适用边界很清晰
适合堆大小 ≤4GB、以响应时间为第一优先级、且能接受一定运维调优成本的系统。一旦堆超过 8GB，CMS 的并发失败概率陡增，碎片管理难度加大，此时 G1 已成为更稳妥的选择。值得注意的是，CMS 在 JDK 9 中被标记为废弃，JDK 14 起已彻底移除，新项目不应再选用。
