CMS的核心价值是大幅降低老年代GC停顿时间，仅需初始标记和重新标记两次短暂STW；但存在内存碎片、浮动垃圾、CPU开销大等问题，且JDK 14已移除，现代系统推荐G1或ZGC。
CMS 垃圾回收器的核心价值是大幅降低老年代 GC 的停顿时间，它专为对响应延迟敏感的系统（如 Web 服务、交易接口）设计，但并非“万能方案”，其优缺点都源于并发标记-清除的设计本质。
低停顿：两次短暂 STW 是最大优势
CMS 将耗时最长的标记和清除过程与用户线程并发执行，整个回收周期中仅需两次停顿：
- 初始标记：只扫描 GC Roots 直接引用的对象，毫秒级，与堆大小无关
- 重新标记：修正并发期间的引用变动，通常控制在几十毫秒内
这意味着绝大多数业务请求不会被 GC 中断，用户体验更平滑。
内存碎片：标记-清除算法的固有代价
它不移动对象，只清理未标记区域，长期运行后容易产生大量不连续空闲空间：
- 当需要分配大对象时，即使总剩余内存充足，也可能因找不到连续空间而触发 Full GC
- 一旦发生 Concurrent Mode Failure（比如老年代占用超阈值但 CMS 还没来得及启动），会降级使用 Serial Old，造成显著卡顿
可通过 -XX:+UseCMSCompactAtFullCollection 在 Full GC 时触发压缩缓解，但该操作本身是 STW 的。
浮动垃圾与 CPU 开销：并发带来的隐性成本
并发执行不是零代价：
- 浮动垃圾：并发清除阶段用户线程仍在生成新对象，这部分垃圾本次无法回收，只能等下次 GC
- CPU 竞争：并发标记和清除会占用额外 CPU 资源，可能影响吞吐量，尤其在高负载或 CPU 密集型应用中
- 可通过
-XX:ConcGCThreads调整并发线程数，平衡资源占用与回收效率
适用边界明确：不是所有场景都适合
CMS 有清晰的定位和前提条件：
- 必须搭配 ParNew（或 Serial）作为新生代收集器，不能与 Parallel Scavenge 搭配
- 主要作用于老年代，对年轻代无直接影响
- 在 JDK 9 中被标记为废弃，JDK 14 正式移除，现代系统推荐 G1 或 ZGC
如果你的应用堆较大（>4GB）、存活对象多、或追求稳定可预测的停顿，CMS 反而可能成为瓶颈。
