CMS是JDK 8及之前面向老年代的低停顿GC，通过并发标记清除减少STW，但存在浮动垃圾和Concurrent Mode Failure问题；需合理配置-XX:+UseConcMarkSweepGC、-XX:CMSInitiatingOccupancyFraction等参数，并监控日志调优。
CMS（Concurrent Mark-Sweep）收集器是 JDK 8 及之前版本中面向老年代的低停顿垃圾收集器，适用于对响应时间敏感、老年代对象生命周期较长的应用。它通过并发标记和清除减少 STW（Stop-The-World）时间，但存在浮动垃圾（Floating Garbage）和 Concurrent Mode Failure 等典型问题。合理配置参数并理解其触发机制，是稳定运行的关键。
核心 CMS 启动参数配置
启用 CMS 需显式指定垃圾收集器，并配合关键行为控制参数：
- -XX:+UseConcMarkSweepGC：启用 CMS（JDK 9+ 已废弃，仅限 JDK 7/8）
- -XX:CMSInitiatingOccupancyFraction=N：设定老年代使用率达到 N% 时启动 CMS 周期（默认约 68%，建议根据应用浮动垃圾量调低至 50–70）
- -XX:+UseCMSInitiatingOccupancyOnly：禁用 JVM 动态调整触发阈值，确保每次按设定值触发（强烈推荐开启）
- -XX:+CMSParallelRemarkEnabled：启用并行重新标记，缩短 remark 阶段 STW 时间
- -XX:CMSMaxAbortablePrecleanTime=5000：限制可中断预清理阶段最长时间（毫秒），避免过长等待影响及时回收
- -XX:+CMSScavengeBeforeRemark：在 remark 前强制一次 Young GC，减少年轻代对象晋升到老年代，从而降低 remark 扫描压力和浮动垃圾基数
浮动垃圾的成因与应对策略
浮动垃圾指 CMS 并发标记阶段之后、并发清除阶段之前新产生的、已不可达但仍被老年代引用的对象。由于 CMS 不做压缩，这些对象无法在本次周期中被回收，只能等下一次 GC。
- 根本原因：CMS 的并发性导致“标记”与“应用线程执行”重叠，新死亡对象未被本轮标记覆盖
- 风险放大场景：高对象创建/销毁速率、长事务或批量处理期间大量临时对象晋升
- 缓解方式：降低 CMS 触发阈值（如设为 60），让回收更频繁；配合 ParNew 控制年轻代回收节奏，减少突增晋升；避免大对象直接进入老年代（调小 -XX:PretenureSizeThreshold 或增大年轻代）
避免 Concurrent Mode Failure 的关键操作
当 CMS 还未完成并发周期，老年代就已满，就会退化为 Serial Old 全停顿回收，造成严重延迟。这是浮动垃圾失控的直接后果。
立即学习“Java免费学习笔记（深入）”；
- 监控指标：关注 GC 日志中的 concurrent mode failure 或 promotion failed
- 前置扩容：适当增大老年代（-Xmx/-Xms 且保持相等，避免动态伸缩干扰 CMS 判断）
- 预留空间：通过 -XX:CMSInitiatingOccupancyFraction 预留足够缓冲（例如堆 4G，老年代 3G，则设为 60 表示 1.8G 即触发）
- 紧急兜底：添加 -XX:+UseCMSCompactAtFullCollection 和 -XX:CMSFullGCsBeforeCompaction=1（JDK 6/7），使 Full GC 后进行内存压缩（注意：影响性能，仅作保底）
替代建议与现实考量
CMS 在 JDK 9 中被标记为废弃，JDK 14 彻底移除。当前新项目应优先考虑 G1 或 ZGC：
- G1 通过分区机制天然控制停顿，支持可预测 GC，且能自动处理浮动垃圾（通过 Remembered Set 和并发标记更新）
- ZGC/Shenandoah 更进一步，将大部分标记与清除工作完全并发，STW 通常低于 10ms
- 若必须维持 CMS（如遗留系统），务必结合 GC 日志（-XX:+PrintGCDetails -XX:+PrintGCTimeStamps）持续观察 CMS-initial-mark、remark 耗时及失败频率，动态调优参数
