GC中的 三色标记法

最近在看JVM 查资料的时候看到一篇关于三色标记法的文章觉得不错。拿过来收藏一下。因为他的配图是gif。让人一目了然啊。
原文地址

三色标记法：

首先要知道 在JVM中如何找到碎片采用的是根可达算法 root searching方法。找到以后进行mark sweep 方法进行标记。然后再root searching 一遍进行回收。所以mark sweep的特点是 地址不连续，再标记的过程中也会有新的对象被放到老年区，这时就会出现碎片，因为要扫两次所以效率略低。
三色标记法就是根据mark sweep来实现的，他是遍历过程按照是否扫描访问检查等等说法是否执行过没把对象分为了三种：

• 白色：尚未访问过。
• 黑色：本对象已访问过，而且本对象 引用到 的其他对象 也全部访问过了。
• 灰色：本对象已访问过，但是本对象 引用到 的其他对象 尚未全部访问完。全部访问后，会转换为黑色。

具体的标记程

一张动图解释一切

1. 开始的时候，会任务所有的对象都是白色的；
2. 利用根可达算法将根下的引用对象都标记为灰色
3. 移动到 灰色对象中，将本对象 标记为黑色；
4. 将灰色对象中所有引用对象标记为灰色；
5. 重复第3第4步，直至扫完所有灰色对象；
6. 完成后没有被标记为黑色的，或者全部是白色的，就为mark sweep出来的垃圾对象可以进行回收。

当FGC的时候如存在 STW （Stop The World ，线程停止，不允许向老年代中存放任何对象，类似一个阻塞的状态 ）那么就没关系，不会出现碎片。但是没有STW的时候就会出现浮动碎片，这些碎片也只能等着下一次FGC的时候来收掉了。
当然具体的FGC操作还是还需要配合其他的技术来实现。这里只是把三色标记法的原理讲一下。

漏标

但是还有一种比较关键的是漏标

假设GC线程已经遍历到E（变为灰色了），此时应用线程先执行了：

var G = objE.fieldG; 
objE.fieldG = null;  // 灰色E 断开引用 白色G 
objD.fieldG = G;  // 黑色D 引用 白色G

此时切回GC线程继续跑，因为E已经没有对G的引用了，所以不会将G放到灰色集合；尽管因为D重新引用了G，但因为D已经是黑色了，不会再重新做遍历处理。
最终导致的结果是：G会一直停留在白色集合中，最后被当作垃圾进行清除。这直接影响到了应用程序的正确性，是不可接受的。

漏标只有同时满足以下两个条件时才会发生：
条件一：灰色对象 断开了 白色对象的引用；即灰色对象 原来成员变量的引用 发生了变化。
条件二：黑色对象 重新引用了 该白色对象；即黑色对象 成员变量增加了 新的引用。

漏标的解决方案

知道了触发漏标的必然条件有两条，那么打破其中一条即可解决漏标的问题。
解决办法：

• inremental update 增量更新 关注引用的增加，当对象增加引用时把对象重新标记为灰色，以便下一次重新扫描，CMS 使用
• SATB Snapshot At The Beginning 开始快照 ， 关注引用的删除，当删除引用时把，这个引用推给GC的堆栈，让GC可以还可以找到这个引用。G1使用

具体办法如下：

var G = objE.fieldG; // 1.读
objE.fieldG = null;  // 2.写
objD.fieldG = G;     // 3.写

读取 对象E的成员变量fieldG的引用值，即对象G；
对象E 往其成员变量fieldG，写入 null值。
对象D 往其成员变量fieldG，写入 对象G ；
我们只要在上面这三步中的任意一步中做一些“手脚”，将对象G记录起来，然后作为灰色对象再进行遍历即可。比如放到一个特定的集合，等初始的GC Roots遍历完（并发标记），该集合的对象 遍历即可（重新标记）。

重新标记是需要STW的，因为应用程序一直在跑的话，该集合可能会一直增加新的对象，导致永远都跑不完。当然，并发标记期间也可以将该集合中的大部分先跑了，从而缩短重新标记STW的时间，这个是优化问题了。

写屏障用于拦截第二和第三步；而读屏障则是拦截第一步。
它们的拦截的目的很简单：就是在读写前后，将对象G给记录下来

写屏障

给某个对象的成员变量赋值时，其底层代码大概长这样：

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

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）这里的读写屏障完全和jvm读写屏障和 内存读写屏障是完全不同的两个概念。：

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

写屏障 + SATB

当对象E的成员变量的引用发生变化时（objE.fieldG = null;），我们可以利用写屏障，将E原来成员变量的引用对象G记录下来：

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

【当原来成员变量的引用发生变化之前，记录下原来的引用对象】
这种做法的思路是：尝试保留开始时的对象图，即原始快照（Snapshot At The Beginning，SATB），当某个时刻 的GC Roots确定后，当时的对象图就已经确定了。
比如 当时 D是引用着G的，那后续的标记也应该是按照这个时刻的对象图走（D引用着G）。如果期间发生变化，则可以记录起来，保证标记依然按照原本的视图来。

值得一提的是，扫描所有GC Roots 这个操作（即初始标记）通常是需要STW的，否则有可能永远都扫不完，因为并发期间可能增加新的GC Roots。

SATB破坏了条件一：【灰色对象 断开了 白色对象的引用】，从而保证了不会漏标。

一点小优化：如果不是处于垃圾回收的并发标记阶段，或者已经被标记过了，其实是没必要再记录了，所以可以加个简单的判断：

void pre_write_barrier(oop* field) {
  // 处于GC并发标记阶段 且 该对象没有被标记（访问）过
  if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) { 
      oop old_value = *field; // 获取旧值
      remark_set.add(old_value); // 记录  原来的引用对象
  }
}

G1中的漏标处理

写屏障 + 增量更新

当对象D的成员变量的引用发生变化时（objD.fieldG = G;），我们可以利用写屏障，将D新的成员变量引用对象G记录下来：

void post_write_barrier(oop* field, oop new_value) {  
  if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
      remark_set.add(new_value); // 记录新引用的对象
  }
}

【当有新引用插入进来时，记录下新的引用对象】
这种做法的思路是：不要求保留原始快照，而是针对新增的引用，将其记录下来等待遍历，即增量更新（Incremental Update）。

增量更新破坏了条件二：【黑色对象 重新引用了 该白色对象】，从而保证了不会漏标。

读屏障（Load Barrier）

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

读屏障是直接针对第一步：var G = objE.fieldG;，当读取成员变量时，一律记录下来：

void pre_load_barrier(oop* field, oop old_value) {  
  if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
      oop old_value = *field;
      remark_set.add(old_value); // 记录读取到的对象
  }
}

这种做法是保守的，但也是安全的。因为条件二中【黑色对象 重新引用了 该白色对象】，重新引用的前提是：得获取到该白色对象，此时已经读屏障就发挥作用了。