概述
本文尝试回答两个问题
- CMS的浮动垃圾是什么，怎么产生的？
- CMS 为什么要有4个阶段
CMS 和相关知识点简介
CMS 全称 concurrent mark sweep, 并发标记清除
因为是 mark sweep 的，所以有内存碎片化问题，当碎片太多的时候，需要 serial old （标记整理 mark -compact 来兜底进行内存整理）
三色标记
因为是并发的，所以gc线程需要知道上一次到哪里了，方便接着上次的进度继续跑，那么就需要一个东西记录上次运行到哪里了，这个状态就是“颜色”， 黑色、灰色、白色，三种，是存在java对象头里的
黑色，并发标记扫描到了这个节点，且所有的子节点全部找到了，就把这个节点标记为黑色
灰色，并发标记扫描到了这个节点，但是子节点还没有开始找，或者没有找完，此时是灰度（流程大概是gc扫描的时候一上来就设置灰色，只有找完了才设置黑色，找完之前线程切走了，所以节点颜色是灰色的）
白色，所有节点初始化颜色都是白色，表示还没有开始遍历、处理
写屏障+增量更新
Write barriers + Incremental Update
为了解决引用变化导致的一些问题，cms 用的是写屏障+增量更新 技术，这个选择有点小问题
引用变化分成三种，新增、删除、更新，但是更新可以被新增和删除包含，暂时认为只有两种：新增和删除
- 新增
如果新增黑色到白色的引用，那么jvm会通过写屏障，来把黑色置为灰色 - 删除
如果删除引用，jvm什么都不会做，这个导致了浮动垃圾
浮动垃圾
就是之前被gc 标记为 可达对象，也就是 存活对象，在两次gc线程之间被业务线程删除了引用，那么颜色不会更改，还是之前的颜色（黑色or灰色），但是其实是白色，所以这一次gc 无法对其回收，需要等下一次gc初始标记启动才会被刷成白色
重新标记
cms 流程如下
- 初始标记（initial mark）
- 并发标记（concurrent mark）
-
重新标记（remark） - 并发清除（concurrent sweep）
按理说并发标记可以找到所有的可达对象，就可以开始清除，也就是只需要三个阶段，那么为什么还需要重新标记呢？
和cms实现有关
- gc线程刚开始在处理c，从成员变量1开始处理，依次是1、2、3...
- 字段1处理完成之后，gc线程挂起了，换业务线程
- 业务线程此时在1上新增了一个指向 g 的引用，g此时是白色的
- 业务线程让位，换gc线程上场。此时gc线程接着处理，从c.2 开始处理，那么问题来了，g应该是可达的，不能被当成垃圾回收掉，但是gc线程又无法正常标记
- 所以cms没办法，只能再
stw一次，也就是重新标记
这个阶段就是停下来把可达节点全部再过一遍，修正一下
参考
https://juejin.cn/post/6987298527562956831
https://segmentfault.com/q/1010000013653267
