CMS并发清理阶段遗留浮动垃圾是因其仅清理上一次并发标记后未被新引用的对象，而清理时应用线程持续运行，导致新分配对象、新引用或对象复活使部分垃圾逃逸，这是CMS并发设计的必然代价。
并发清理阶段为什么留了一堆浮动垃圾
因为 CMS 的 concurrent cleanup 阶段只清理「上一次并发标记后没被新引用的对象」，而清理过程中应用线程还在跑，新分配对象、新建立引用、甚至老对象被复活（比如 finalizer 重新把对象塞进静态集合），都会导致部分本该回收的垃圾“逃过一劫”。这不是 bug，是 CMS 并发设计的必然代价。
- 典型现象：
concurrent cleanup日志里出现Found X objects in finalizable queue或清理耗时突然变长，但老年代使用率没明显下降 - 关键限制：CMS 不做浮动垃圾的二次扫描，它把这部分压力推给了下一次 GC 的初始标记（
initial-mark）——所以浮动垃圾会堆积，直到触发下一次 CMS 周期 - 影响最直接的是老年代碎片化加剧，尤其在长期运行、大量短生命周期大对象的场景下，容易提前触发
concurrent mode failure
CMSParPromotionFailed 和 promotion failed 的区别
CMSParPromotionFailed 是年轻代 GC（ParNew）尝试晋升对象到老年代时，发现 CMS 老年代虽有空间但无法找到连续块容纳该对象；而普通 promotion failed 多见于 Serial/Parallel GC，通常意味着老年代真的满了。前者本质是碎片问题，后者更偏向容量问题。
-
CMSParPromotionFailed高频出现，基本可断定浮动垃圾 + 碎片已积累到临界点 - 注意日志位置：它出现在 ParNew GC 的末尾，不是 CMS 自身阶段，容易误判为年轻代问题
- 触发后 JVM 会退化为 Full GC（STW），但此时 CMS 已无法并发执行，等价于停掉所有应用线程强行整理内存
-XX:CMSInitiatingOccupancyFraction 设置多少才靠谱
这个参数控制 CMS 启动并发周期的老年代占用阈值，设太高（比如 90）等于等快爆了才动手，浮动垃圾没时间消化；设太低（比如 60）又会导致频繁并发周期，吞 CPU 还可能干扰应用吞吐。真实环境里，它必须和实际浮动垃圾量匹配，不能拍脑袋定。
- 先用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps跑几天，看每次 CMS 开始前老年代占用率是否稳定在某个区间（比如 72%–78%） - 把
CMSInitiatingOccupancyFraction设为该区间的下限再减 5–10 个百分点（例如观察到最低 72%，就设 62–67） - 禁用
-XX:+UseCMSInitiatingOccupancyOnly：否则 JVM 会忽略动态预测，死守你写的数字，反而更不稳 - JDK 7u4 之后默认启用
UseAdaptiveSizePolicy，它会悄悄覆盖你的CMSInitiatingOccupancyFraction，如需精确控制，得显式关闭它
浮动垃圾能靠 CMSIncrementalMode 拉回来吗
不能。CMSIncrementalMode 只是把并发阶段（主要是并发标记和并发预清理）拆成小片，在 STW 间隙里穿插执行，目标是降低单次暂停时间，对浮动垃圾的产生和清理路径完全没影响。它甚至可能因调度碎片化，让并发清理更难覆盖到新产生的浮动对象。
- 这个参数在 JDK 8 中已被废弃，JVM 启动时会打印警告：
XX:+CMSIncrementalMode is deprecated - 真正缓解浮动垃圾，得靠缩短 CMS 周期（调低
CMSInitiatingOccupancyFraction）、减少新引用风暴（比如避免在 CMS 运行中批量往缓存塞对象），或干脆换 G1 - 如果看到日志里
concurrent abortable preclean频繁超时，说明应用写屏障开销太大，浮动垃圾生成速度远超 CMS 清理能力——这时候调参数已经没用了
浮动垃圾不是配置能抹平的，它是 CMS 并发模型在高吞吐写负载下的固有毛刺。压得越紧，它越容易从缝隙里漏出来。
