浮动垃圾不是错误，而是cms为实现低停顿所必须接受的代价；它由并发标记结束后新分配或断开引用的对象构成，无法在本轮gc回收，需待下一轮初始标记时重新判定可达性，若仍不可达则被正常清理。
浮动垃圾不是错误，而是 CMS 为实现低停顿所必须接受的代价。它不会在本轮 GC 中被回收，而是自然留待下一轮 GC 的标记阶段重新判断——若仍不可达，就正常清理；若已被复活或仍在使用，就保留。关键不在“清除”，而在控制其规模与影响。
浮动垃圾是怎么来的
本质是用户线程和 GC 线程并发运行导致的标记滞后：
- 并发标记结束后，新分配的对象默认为“白色”，未被标记，也来不及进入本轮清理范围
- 标记完成后，程序立刻断开引用（比如局部变量出作用域、集合 remove），对象瞬间变为不可达，但已错过标记时机
- 对象通过
finalize()复活后又被弃用，或 JNI/反射绕过写屏障，导致引用变更未被重新标记捕获 - 新生代频繁晋升短命对象到老年代，这些对象在 CMS 清理时已不可达，但未被标记为死亡
下一次 GC 怎么处理它
浮动垃圾的回收完全依赖标准三色标记逻辑，不靠特殊机制：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 下一轮初始标记触发时，JVM 从 GC Roots 开始重新扫描，所有真正不可达的对象都会被识别为“白色”
- 随后的并发标记会将其保留在白色集合中，最终在并发清除阶段释放内存
- 如果该对象在下轮标记开始前又被其他存活对象引用（如加入缓存、静态 Map），它就不再是垃圾，自然不回收
- CMS 不压缩，所以只要标记准确，清理就能归还空间——浮动垃圾是否被回收，只取决于它在下轮标记起点是否可达
怎么防止它引发问题
重点不是消灭浮动垃圾，而是避免它堆积触发严重故障：
- 调低
-XX:CMSInitiatingOccupancyFraction（例如设为 65），让 CMS 更早启动，缩短浮动窗口，给垃圾留出缓冲空间 - 启用
-XX:+CMSScavengeBeforeRemark，在重新标记前强制一次 Minor GC，减少跨代引用干扰，降低漏标率 - 关闭自适应阈值：
-XX:-UseCMSInitiatingOccupancyOnly，防止 JVM 动态覆盖你设定的触发点 - 监控 GC 日志：关注老年代使用率是否持续爬升却不触发 CMS、
concurrent mode failure是否频发、每次 CMS 后老年代回收量是否明显萎缩
什么情况下它会“消失”
浮动垃圾本身不会自动消失，但以下情况会让它退出生命周期：
- 被下一轮 CMS 正常标记并清除（最常见）
- 因老年代空间不足触发
Concurrent Mode Failure，JVM 退化为 Serial Old Full GC——这次 STW GC 会完整遍历，一并回收所有浮动垃圾 - 应用重启，整个堆重置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
