CMS并发收集的核心缺陷是设计取舍导致的固有局限：为降低停顿而放弃对内存变化的完全掌控，引发Concurrent Mode Failure、CPU争抢加剧吞吐下降及空间碎片累积三大问题。
CMS并发收集的核心缺陷不是“逻辑错误”，而是设计取舍带来的固有局限：它为换取低停顿，主动放弃了对运行中内存变化的完全掌控。问题不在于代码写错了，而在于并发场景下资源竞争、状态漂移和算法约束共同导致的不可控后果。
浮动垃圾引发的Concurrent Mode Failure
在并发标记与并发清理阶段，用户线程持续分配新对象、修改引用关系，产生一批“标记之后才出现”的垃圾——即浮动垃圾。CMS无法在本轮回收中处理它们，只能依赖预留空间暂存。一旦老年代已用空间 + 预估浮动垃圾量 > 老年代总容量，就会触发Concurrent Mode Failure。
此时JVM会立即终止CMS流程，退回到Serial Old进行STW式Full GC，停顿时间陡增数倍甚至十倍。
- 默认触发阈值在JDK 6+为92%，但实际浮动垃圾量波动大，固定百分比容易失效
- 尤其在流量突增、对象创建速率飙升时，预留空间迅速被填满
- 该失败本质是“空间预估失准”，而非标记逻辑出错
CPU资源争抢加剧吞吐下降
CMS的并发阶段虽不STW，却需占用真实计算资源。其默认回收线程数为(CPU核心数 + 3) / 4，在2核机器上即占1个完整核心（50% CPU），4核机器占约25%，8核仅约12.5%。
当应用本身CPU密集（如高频计算、序列化、加解密），CMS线程与业务线程形成硬性争抢，表现为响应延迟升高、吞吐量断崖下跌，而非GC日志报错。
- 线程数不可设为0，最小为1；低配环境无法关闭并发开销
- 并发标记阶段遍历对象图耗CPU，且随堆中存活对象增多而线性增长
- 无动态降频机制：即使系统负载已达95%，CMS仍按计划并发执行
标记-清除导致的空间碎片累积
CMS不移动对象，仅清除死亡区域，长期运行后老年代布满大小不一的空闲块。当需要分配大对象（如缓存批量加载、大数组、NIO direct buffer）时，即使总空闲内存充足，也会因无连续空间而失败。
此时触发两种降级路径：一是直接分配失败抛OutOfMemoryError；二是触发Concurrent Mode Failure，诱使Full GC启动——而Serial Old在Full GC中仍不压缩，碎片进一步恶化。
- 碎片无法通过CMS自身修复，必须依赖额外STW整理动作
- -XX:+UseCMSCompactAtFullCollection仅在Full GC后生效，属被动补救
- 没有实时碎片监控指标，运维难以提前干预
可行的修复与缓解路径
修复不是重写CMS，而是围绕其边界做精准调控与替代升级：
- 调高-XX:CMSInitiatingOccupancyFraction至75%~85%，配合监控老年代增长速率动态调整，留足浮动垃圾缓冲空间
- 启用-XX:+UseCMSInitiatingOccupancyOnly，禁用JVM自动修正阈值，避免策略漂移
- 设置-XX:CMSFullGCsBeforeCompaction=1，确保每次Full GC都强制压缩，抑制碎片雪崩
- 对新生代压力大的系统，改用ParNew + CMS组合，并调小-XX:NewRatio，减少晋升冲击
- 生产环境建议迁移到G1或ZGC：G1通过分区+复制天然规避碎片，ZGC实现真正并发标记与移动，彻底消除Concurrent Mode Failure
