关于CMS 浮动垃圾的一些理解

概述

本文尝试回答两个问题

1. CMS的浮动垃圾是什么，怎么产生的？
2. CMS 为什么要有4个阶段

CMS 和相关知识点简介

CMS 全称 concurrent mark sweep, 并发标记清除
因为是 mark sweep 的，所以有内存碎片化问题，当碎片太多的时候，需要 serial old （标记整理 mark -compact 来兜底进行内存整理）

三色标记

因为是并发的，所以gc线程需要知道上一次到哪里了，方便接着上次的进度继续跑，那么就需要一个东西记录上次运行到哪里了，这个状态就是“颜色”， 黑色、灰色、白色，三种，是存在java对象头里的

黑色，并发标记扫描到了这个节点，且所有的子节点全部找到了，就把这个节点标记为黑色
灰色，并发标记扫描到了这个节点，但是子节点还没有开始找，或者没有找完，此时是灰度（流程大概是gc扫描的时候一上来就设置灰色，只有找完了才设置黑色，找完之前线程切走了，所以节点颜色是灰色的）
白色，所有节点初始化颜色都是白色，表示还没有开始遍历、处理

写屏障+增量更新

Write barriers + Incremental Update
为了解决引用变化导致的一些问题，cms 用的是写屏障+增量更新 技术，这个选择有点小问题
引用变化分成三种，新增、删除、更新，但是更新可以被新增和删除包含，暂时认为只有两种：新增和删除

• 新增
  如果新增黑色到白色的引用，那么jvm会通过写屏障，来把黑色置为灰色
• 删除
  如果删除引用，jvm什么都不会做，这个导致了浮动垃圾

浮动垃圾

image.png

就是之前被gc 标记为 可达对象，也就是 存活对象，在两次gc线程之间被业务线程删除了引用，那么颜色不会更改，还是之前的颜色（黑色or灰色），但是其实是白色，所以这一次gc 无法对其回收，需要等下一次gc初始标记启动才会被刷成白色

重新标记

cms 流程如下

• 初始标记（initial mark）
• 并发标记（concurrent mark）
• 重新标记（remark）
• 并发清除（concurrent sweep）

按理说并发标记可以找到所有的可达对象，就可以开始清除，也就是只需要三个阶段，那么为什么还需要重新标记呢？
和cms实现有关

image.png

1. gc线程刚开始在处理c，从成员变量1开始处理，依次是1、2、3...
2. 字段1处理完成之后，gc线程挂起了，换业务线程
3. 业务线程此时在1上新增了一个指向 g 的引用，g此时是白色的
4. 业务线程让位，换gc线程上场。此时gc线程接着处理，从c.2 开始处理，那么问题来了，g应该是可达的，不能被当成垃圾回收掉，但是gc线程又无法正常标记
5. 所以cms没办法，只能再 stw 一次，也就是 重新标记
   这个阶段就是停下来把可达节点全部再过一遍，修正一下

参考

https://juejin.cn/post/6987298527562956831
https://segmentfault.com/q/1010000013653267