前言算法
本文主要介绍了三色标记法的基本思路、多标致使的浮动垃圾、漏标的处理方案(读写屏障)等。缓存
1. 垃圾回收的简单回顾安全
关于垃圾回收算法，基本就是那么几种：标记-清除、标记-复制、标记-整理。在此基础上能够增长分代(新生代/老年代)，每代采起不一样的回收算法，以提升总体的分配和回收效率。并发
不管使用哪一种算法，标记老是必要的一步。这是理算固然的，你不先找到垃圾，怎么进行回收?oop
垃圾回收器的工做流程大致以下：post
标记出哪些对象是存活的，哪些是垃圾(可回收);性能
进行回收(清除/复制/整理)，若是有移动过对象(复制/整理)，还须要更新引用。优化
本文着重来看下标记的部分。spa
2. 三色标记法.net
2.1 基本算法
要找出存活对象，根据可达性分析，从GC Roots开始进行遍历访问，可达的则为存活对象：
最终结果：A/D/E/F/G 可达
咱们把遍历对象图过程当中遇到的对象，按“是否访问过”这个条件标记成如下三种颜色：
白色：还没有访问过。
黑色：本对象已访问过，并且本对象 引用到 的其余对象 也所有访问过了。
灰色：本对象已访问过，可是本对象 引用到 的其余对象 还没有所有访问完。所有访问后，会转换为黑色。
三色标记遍历过程
假设如今有白、灰、黑三个集合(表示当前对象的颜色)，其遍历访问过程为：
初始时，全部对象都在 【白色集合】中;
将GC Roots 直接引用到的对象 挪到 【灰色集合】中;
从灰色集合中获取对象：
3.1. 将本对象 引用到的 其余对象 所有挪到 【灰色集合】中;
3.2. 将本对象 挪到 【黑色集合】里面。
重复步骤3，直至【灰色集合】为空时结束。
结束后，仍在【白色集合】的对象即为GC Roots 不可达，能够进行回收。
注：若是标记结束后对象仍为白色，意味着已经“找不到”该对象在哪了，不可能会再被从新引用。
当Stop The World (如下简称 STW)时，对象间的引用 是不会发生变化的，能够轻松完成标记。
而当须要支持并发标记时，即标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的状况就有可能发生。
2.2 多标-浮动垃圾
假设已经遍历到E(变为灰色了)，此时应用执行了 objD.fieldE = null ：
D > E 的引用断开
此刻以后，对象E/F/G是“应该”被回收的。然而由于E已经变为灰色了，其仍会被看成存活对象继续遍历下去。最终的结果是：这部分对象仍会被标记为存活，即本轮GC不会回收这部份内存。
这部分本应该回收 可是 没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响应用程序的正确性，只是须要等到下一轮垃圾回收中才被清除。
另外，针对并发标记开始后的新对象，一般的作法是直接所有当成黑色，本轮不会进行清除。这部分对象期间可能会变为垃圾，这也算是浮动垃圾的一部分。
2.3 漏标-读写屏障
假设GC线程已经遍历到E(变为灰色了)，此时应用线程先执行了：
var G = objE.fieldG;
objE.fieldG = null; // 灰色E 断开引用 白色G
objD.fieldG = G; // 黑色D 引用 白色G
E > G 断开，D引用 G
此时切回GC线程继续跑，由于E已经没有对G的引用了，因此不会将G放到灰色集合;尽管由于D从新引用了G，但由于D已是黑色了，不会再从新作遍历处理。
最终致使的结果是：G会一直停留在白色集合中，最后被看成垃圾进行清除。这直接影响到了应用程序的正确性，是不可接受的。
不难分析，漏标只有同时知足如下两个条件时才会发生：
条件一：灰色对象 断开了 白色对象的引用;即灰色对象 原来成员变量的引用 发生了变化。
条件二：黑色对象 从新引用了 该白色对象;即黑色对象 成员变量增长了 新的引用。
从代码的角度看：
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给记录下来。
2.3.1 写屏障(Store Barrier)
给某个对象的成员变量赋值时，其底层代码大概长这样：
/**
* @param field 某对象的成员变量，如 D.fieldG
* @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); // 写屏障-写后操做
}
(1) 写屏障 + 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); // 记录 原来的引用对象
}
}
(2) 写屏障 + 增量更新
当对象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)。
增量更新破坏了条件二：【黑色对象 从新引用了 该白色对象】，从而保证了不会漏标。
2.3.2 读屏障(Load Barrier)
oop oop_field_load(oop* field) {
pre_load_barrier(field); // 读屏障-读取前操做 郑州专业的男科医院http://www.zzchanghong110.com/
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); // 记录读取到的对象
} 郑州看男科医院哪家好http://www.120zzxbyy.com/
}
这种作法是保守的，但也是安全的。由于条件二中【黑色对象 从新引用了 该白色对象】，从新引用的前提是：得获取到该白色对象，此时已经读屏障就发挥做用了。
2.4 三色标记法与现代垃圾回收器
现代追踪式(可达性分析)的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：好比白色/黑色集合通常都不会出现(可是有其余体现颜色的地方)、灰色集合能够经过栈/队列/缓存日志等方式进行实现、遍历方式能够是广度/深度遍历等等。
对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案以下：
CMS：写屏障 + 增量更新
G1：写屏障 + SATB
ZGC：读屏障
工程实现中，读写屏障还有其余功能，好比写屏障能够用于记录跨代/区引用的变化，读屏障能够用于支持移动对象的并发执行等。功能以外，还有性能的考虑，因此对于选择哪一种，每款垃圾回收器都有本身的想法。
值得注意的是，CMS中使用的增量更新，在从新标记阶段，除了须要遍历 写屏障的记录，还须要从新扫描遍历GC Roots(固然标记过的无需再遍历了)，这是因为CMS对于astore_x等指令不添加写屏障的缘由，具体可参考这里。