浅谈JVM垃圾收集——并发的可达性分析

前言

当前主流编程语言的垃圾收集器基本上都是依靠可达性分析算法来判定对象 是否存活的，可达性分析算法理论上要求全过程都基于一个能保障一致性的快照中才能够进行分析， 这意味着必须全程冻结用户线程的运行。

在前面的文章分析中，根节点枚举在OopMap的帮助下，它带来的停顿已经是非常短暂且相对固定（不随堆容量而增长）的了。

详情看：OopMap和安全点

可从GC Roots再继续往下遍历对象图，这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了：堆越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长。那有没有办法能使用户线程和引用链分析一起并发执行呢？

三色标记

首先先搞清楚可达性分析为什么必须在一个能保障一致性的快照上才能进行对象图的遍历？为了能解释清楚这个问题，我们引入三色标记（Tri-color Marking）作为工具来辅 助推导，把遍历对象图过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色：

• 白色： 表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是 白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。
• 黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代 表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
• 灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

对象消失

但如果用户线程与收集器是并发工作，收集器在对象图上标记颜色，同时用户线程在修改引用关系——即修改对象图的结构，这样可能出现两种后果。

• 一种是把原本消亡的对象错误标记为存活，可以容忍，产生了一点逃过本次收集的浮动垃圾，下次收集可继续清理。
• 另一种是把原本存活的对象错误标记为已消亡，这是致命的错误。也叫“对象消失”。

理论证明，当且仅当以下两个条件同时满足时，会产生“对象消失”的问题，即原本应该是黑色的对象被误标为白色：

• 赋值器插入了一条或多条从黑色对象到白色对象的新引用；
• 赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

增量更新和原始快照

因此，我们要解决并发扫描时的对象消失问题，只需破坏这两个条件的任意一个即可。由此分别产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning， SATB）。

• 增量更新要破坏的是第一个条件，当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象 了。
• 原始快照要破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描 一次。这也可以简化理解为，无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来 进行搜索。

对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。在HotSpot虚拟机中，CMS是基于增量更新 来做并发标记的，G1、Shenandoah则是用原始快照来实现。

总结

这篇文章主要是引出三色标记算法，增量更新和原始快照，因为后面的CMS，G1，ZGC等并发收集的垃圾收集器就有这些概念。
三色标记

• 白色： 表示对象尚未被垃圾收集器访问过
• 黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。
• 灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

要想实现用户线程与引用链并发执行，就要破坏触发对象消失的两个条件：

• 赋值器插入了一条或多条从黑色对象到白色对象的新引用；
• 赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

解决对象消失的方案有增量更新和原始快照，CMS用的增量更新，G1、Shenandoah用的原始快照。
增量更新

• 增量更新： 这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象 了。
• 原始快照：这可以简化理解为，无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。