cms并发清理阶段的浮动垃圾无法被当次gc回收，是其固有特性；需通过gc日志识别堆积迹象（如老年代持续攀升、concurrent mode failure频发、预清理异常、清理量递减），定位新生代晋升、对象复活、大对象分配等诱因，并调优cmsinitiatingoccupancyfraction、禁用自适应策略、优化预清理及监控碎片来防控恶化。
CMS在并发清理阶段产生的浮动垃圾无法被当次GC回收，是其并发设计的固有特性，排查重点不是“消除”，而是识别堆积迹象、定位诱因、防止恶化为Concurrent Mode Failure或CMSParPromotionFailed等严重故障。
观察GC日志中的关键信号
启用详细GC日志（-XX:+PrintGCDetails -XX:+PrintGCTimeStamps），重点关注以下几类输出：
-
老年代使用率持续攀升但未触发CMS：比如老年代已占用75%–80%，却迟迟不进入initial-mark阶段，说明CMS启动阈值（
CMSInitiatingOccupancyFraction）设得过高，浮动垃圾在静默堆积 - 频繁出现“concurrent mode failure”：这是最直接的告警，表示CMS来不及清理，老年代已满，被迫退化为Full GC（STW），此时浮动垃圾+碎片已到临界点
- “CMS-concurrent-abortable-preclean”耗时异常长或失败：预清理阶段卡住，往往意味着新生代晋升压力大、跨代引用剧增，间接加剧浮动垃圾生成
- 每次CMS后老年代占用下降幅度明显变小：例如上次清掉50MB，这次只清掉10MB，说明大量新分配/复活对象逃过了标记，成了浮动垃圾
分析浮动垃圾的主要来源
浮动垃圾本质是「在并发标记结束后、并发清理开始前」这段时间内产生的新垃圾，或「本该被标记为垃圾但因引用变动而漏标」的对象。常见来源包括：
- 新生代快速晋升：Minor GC频繁，大量对象直接进入老年代，其中不少生命周期极短，在CMS清理时已不可达，但未被标记
-
对象“复活”：例如通过
finalize()方法将自身重新加入静态集合、缓存Map等，使原本应被回收的对象变为存活 - 大对象直接分配在老年代：尤其在分配速率高、CMS周期长时，这些对象可能很快失效，成为浮动垃圾主力
- 写屏障未覆盖场景：如使用了不兼容的JNI调用或反射操作，绕过JVM写屏障机制，导致卡表（Card Table）未及时标记脏卡，影响重新标记准确性
验证与调优关键参数
浮动垃圾本身不可避免，但可通过参数控制其规模和影响范围：
-
降低CMS启动阈值：根据历史GC日志中老年代实际占用最低触发点（如观察到最低72%触发），将
-XX:CMSInitiatingOccupancyFraction=62（即下调10个百分点），让CMS更早介入，缩短浮动窗口 -
关闭自适应策略干扰：JDK 7u4+默认开启
-XX:+UseAdaptiveSizePolicy，它会动态覆盖你的CMSInitiatingOccupancyFraction，务必显式添加-XX:-UseAdaptiveSizePolicy -
优化预清理行为：增加
-XX:CMSMaxAbortablePrecleanTime=5000（单位毫秒），避免预清理过早中止；配合-XX:+CMSScavengeBeforeRemark，强制在remark前做一次Minor GC，减少跨代引用扫描量 -
监控碎片程度：启用
-XX:+PrintGCDetails后，关注每次CMS后是否出现“coalesced X blocks”字样，若长期无合并或最大连续空闲块持续缩小，说明碎片+浮动垃圾共同恶化
辅助工具与长期观测建议
单靠日志难以定位具体对象，需结合运行时工具交叉验证：
-
jstat持续采样：执行
jstat -gc <pid> 1s</pid>，观察OU（老年代使用量）波动趋势、OC（老年代容量）是否稳定、YGC/FGC频次比是否异常升高 -
jmap + MAT分析堆快照：在CMS频繁失败前后执行
jmap -dump:format=b,file=heap.hprof <pid></pid>，用MAT查看老年代中大量短命对象（如临时byte[]、StringBuilder）、重复创建的DTO实例、未清理的监听器引用等典型浮动垃圾载体 - 设置浮动垃圾预警阈值：例如定义“连续3次CMS后老年代占用下降＜15MB”为风险信号，自动触发告警并启动深度排查
