JVM-垃圾回收-三色标记算法

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。这里引入“三色标记”来给大家解释下，把Gcroots可达性分析遍历对象过程中遇到的对象， 按照“是否访问过”这个条件标记成以下三种颜色；

• 黑色：

表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。

• 灰色：

表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。

• 白色：

表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。

黑色标识：分析完毕；

灰色标识：没有分析完毕；

白色标识：不可达无任何引用；

最后白色的对象就是可以回收的对象，因为没有任何引用且不可达对象；


/**
 * 类描述:  三色标记算法描述
 *
 * @author xxsd
 * @version 1.0.0
 * @date 2020/7/31 0031 下午 7:58
 */
public class TreeColorRemark {
    public static void main(String[] values){
        //从GC Roots根开始可达性算法进行查找，开始进行标记，触发初始标记
        A a = new A();

        //开始做并发标记
        //读
        D d = a.b.d;
        //写
        a.b.c = null;
        //写
        a.d = d;
    }

}

class A {
    //对于B的引用
    B b = new B();
    //为空标识为无效
    D d = null;
}

class B{
    //对于C的引用，但是C没有任何地方引用
    C c = new  C();
    //对于D的引用
    D d = new D();
}

class C{}
class D{}

在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“**浮动垃圾**”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。另外，**针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色**，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。本次GC可以不用关心，因为在下次标记的时候再去处理；

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： **增量更新（Incremental Update） 和原始快照（Snapshot At The Beginning，SATB）**。

**增量更新**：当黑色对象插入新的指向白色对象的引用关系时， 就将这个新插入的引用记录下来，新增的引用使用集合保存起来， 等并发扫描结束之后， 再将这些记录过的引用关系中的黑色对象为根， 重新扫描一次。 这可以简化理解为， **黑色对象一旦新插入了指向白色对象的引用之后， 它就变回灰色对象了**。重新标记的时候会暂停线程（STW）所以会保证对象所有的状态都是不变的，这就是CMS重新标记的原理；

**原始快照**：当灰色对象要删除指向白色对象的引用关系时， 就将这个要删除的引用记录下来， 在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根， 重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(**目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾**)以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过**写屏障**实现的。

给某个对象的成员变量赋值时，伪代码如下：

/**
 * @param field 某对象的成员变量，如 a.b.d
 * @param new_value 新值，如 null
 */
 void oop_field_store(oop* field, oop new_value) {
 *field = new_value; // 赋值操作
 }

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

void oop_field_store(oop* field, oop new_value) {
 pre_write_barrier(field); // 写屏障‐写前操作
 *field = new_value;
 post_write_barrier(field, value); // 写屏障‐写后操作
 }

当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将B原来成员变量的引用对象D记录下来：

void pre_write_barrier(oop* field) { oop old_value = *field; // 获取旧值 remark_set.add(old_value); // 记录原来的引用对象 }

当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D记录下来：

void post_write_barrier(oop* field, oop new_value) {
 remark_set.add(new_value); // 记录新引用的对象
 }

oop oop_field_load(oop* field) ｛
    pre_load_barrier(field); // 读屏障‐读取前操作
    return *field;
 }

现代追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色/黑色集合一般都不会出现（但是有其他体现颜色的地方）、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。

对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：

• CMS：写屏障 + 增量更新
• G1，Shenandoah：写屏障 + SATB
• ZGC：读屏障

工程实现中，读写屏障还有其他功能，比如写屏障可以用于记录跨代/区引用的变化，读屏障可以用于支持移动对象的并发执行等。功能之外，还有性能的考虑，所以对于选择哪种，每款垃圾回收器都有自己的想法。

我的理解：SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入GCRoots扫描范围。事实上并不只是新生代、 老年代之间才有跨代引用的问题， 所有涉及部分区域收集（Partial GC） 行为的垃圾收集器， 典型的如G1、 ZGC和Shenandoah收集器， 都会面临相同的问题。

垃圾收集场景中，收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨代引用指针的全部细节。

hotspot使用一种叫做“卡表”(cardtable)的方式实现记忆集，也是目前最常用的一种方式。关于卡表与记忆集的关系，可以类比为Java语言中HashMap与Map的关系。

卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”。

hotSpot使用的卡页是2^9大小，即512字节