引言:在JVM中，使用可达性分析算法来判断一个对象是否存活。在Serial和Parallel收集器中，可达性分析的过程是STW的，这意味着在标记的过程中，对象的引用关系没有发生改变，从GC Root开始扫描，可以得到全部存活的对象。但是在CMS，G1等垃圾收集器中，采用了并发标记的方式来遍历对象图，毫无疑问，这缩短了STW的时间，但是也带来了新的问题，而增量更新和原始快照就是用来解决这个问题的不同方式。

一 并发标记的问题

采用了并发标记，可以让用户线程和GC线程同时工作，但是也带来了新的问题。

1 浮动垃圾

在进行并发标记的时候，无法处理初始标记以后产生的对象，这些对象称为浮动垃圾，这些浮动垃圾如果过多，会导致堆没有空间可以存放这些对象，因为这时候还在进行GC，旧的对象没有被回收。但这相对来说还是可控的，可以适当调整触发GC的堆大小的阈值来尽量避免这种情况的发生。

2 对象消失

在并发标记的时候，用户能够操作对象，这就有可能使得引用关系发生修改，使得所有指向本来活的对象的引用全部消失，那按照可达性分析算法，此时对象会被判定为死亡，但是实际这个对象是存活的。由于这个问题相对来说比较严重，所以我们下文以说明如何解决对象消失问题为主。

上面是用户线程修改引用关系前后的对比图。虚线代表引用已经被删除。
当同时满足以下两个条件时，就会出现对象消失的情况。

1 从黑色对象到白色对象增加了新的引用关系。
2 灰色对象直接或间接删除了到这个白色对象的全部引用关系。

因为黑色对象是不能再被访问的，而灰色对象又删除了到这个白色对象的全部引用关系，所以就造成了该白色对象本来是存活的，但是因为在扫描路径中没有出现而被当成死亡对象。

二 如何解决对象消失

为了解决对象消失的问题，在JVM中有两种方式，分别是增量更新和原始快照。在CMS垃圾收集器中使用增量更新，在G1垃圾收集器中使用原始快照。

增量更新（Increment Update）

在上文我们提到两个条件同时满足，那么对象就会“消失”，所以我们只需要破坏其中一个条件即可。增量更新破坏的就是第一个条件。
增量更新的做法是把新增白色对象变为灰色对象并记录下引用修改，具体的是做法是利用记忆集和写后屏障技术，但是在这里传统的记忆集并不能满足CMS垃圾收集器对于引用修改追踪的要求。原因是这样的，在并发标记的过程中，有可能独立进行多次Young GC，这时候Card Table就会频繁被修改，导致原有的dirty card变成了clean card，这样就导致在并发标记过程中不能记录下完整的引用关系。

所以这时候JVM就引入了Mod-Union Table。Mod-Union Table本质上也是一个Byte数组，它是所有并发标记过程中发生的Change Card Table的合集，它的作用是在Young GC发生前检查Crad Table的某一位是否dirty，也就是这一位的数值是否变成1，如果变成1，就记录到Mod-Union Table中。Mod-Union Table和Card Table的位是一一对应的关系。
下面为CMS论文关于Set Mod-Union Table Bit的原文：
This invariant ismaintained by young-generation collections, which set the mod union bits for all cards dirty in the card table before scanning those dirty cards.
在每次Young GC扫描dirty card前都在Mod-Union Table中记录下dirty card，这样就保证了即使在后面的Change Card Table中， Card Table中元素的数值发生过改变，但是在Mod-Union Table对应元素的数值始终为1。

从正常角度来讲，Card Table能记录下所有到老年代的引用修改，但是实际的应用中，Card Table没有被用来跟踪新生代到老年代的引用修改，因为新生代的对象朝生夕灭，引用更新频繁，这样新生代基本全为dirty card，而处理这些dirty card也需要消耗资源，不如直接扫描新生代划算。在具体实现中，JVM用扫描整个新生代来代替处理Card Table中新生代到老年代引用关系的变化，而用Card Table和Mod-Union Table记录下老年代到老年代的引用修改，并在Remark阶段进行处理。
所以总的来说，用增量更新实现的最终标记阶段是通过 以下三个步骤来完成的。
1 重新扫描新生代。
2 重新扫描并发标记结束时老年代的Card Table记录下的对象。
3 重新扫描并发标记结束时老年代的Mod-Union Table记录下的对象。
步骤2和步骤3的具体做法是把dirty page里面的黑色对象中新增的灰色对象字段重新扫描一遍。

原始快照（ Snapshot At The Beginning SATB）

上文讲述的是利用增量更新来解决CMS并发标记过程中出现的对象消失问题。而在G1垃圾收集器中则使用原始快照的方式来解决这个问题。
原始快照破坏的是第二个条件，在灰色对象到白色对象的直接引用或者间接引用关系修改前，会把这个引用记录下来，放进当前用户线程私有的SATB Queue中，最终汇集到一个全局的SATB Queue Set中，在最终标记阶段再扫描这些记录下来的引用记录。

上文我们提到增量更新使用到了写屏障技术，但是上文提到的写屏障只用到了写后屏障，在原始快照中运用到了写前屏障，因为要在引用被删除前把灰色对象到白色对象的关系记录下来。

1 写前屏障的具体实现

下面是G1论文中关于写屏障的伪代码和解释：

Below we show pseudocode for the marking write barrier for a write of the value in rY to offset FieldOffset in an object whose address is in rX. Its operation is explained below.

The actual pointer store [rX, FieldOffset] := rY would follow. The first two lines of the barrier skip the remainder if marking is not in progress; for many programs, this filters out a large majority of the dynamically executed barriers. Lines 3 and 4 load the value in the object field, and check whether it is null. It is only necessary to log non-null values. In many programs the majority of pointer writes are initializing writes to previously-null fields, so this further filtering is quite effective.

大致意思是SATB只记录发生在并发标记阶段的引用修改，并且要记录的这个引用的值不能为空，当以上两者都满足的时候，就把这个引用放到当前用户线程私有的SATB Queue中。

2 并发标记阶段对于SATB Queue 的处理

The satb enqueue operation adds the pointer value to the thread’s current marking buffer. As with remembered set buffers, if the enqueue fills the buffer, it then adds it to the global set of completed marking buffers. The concurrent marking thread checks the size of this set at regular intervals, interrupting its heap traversal to process filled buffers.
在并发标记阶段，有可能因为引用修改较为频繁，SATB Queue的大小超过了分配给线程的缓冲区域，这时候SATB Queue会被添加进Global SATB Queue Set中（下文用GSQS代替），再给当前用户线程换一个全新的SATB Queue供其记录引用。
当GSQS中的队列越来越多，整体大小也超过了阈值，那么并发标记阶段就会对GSQS中的引用进行处理，G1收集器使用GC线程把这些SATB Queue记录下的引用取出并压入标记栈（marking stack）中。此时并发标记阶段没有结束，GC线程会从标记栈中取出引用并扫描。

3 最终标记阶段对于SATB Queue 的处理

It is very simple: any unprocessed completed log buffers are processed as above, and the partially completed per-thread buffers are processed in the same way. This process is done in parallel, to guard against programs with many mutator threads with partially filled marking log buffers causing long pause times or parallel scaling issues.

到最终标记阶段的时候，暂停全部用户线程，并发处理每个用户线程的log buffers （即STAB Queue）中的引用。

三 解决浮动垃圾的策略

对于并发标记的问题，在上文我们主要关心的是“对象消失”的问题，该问题一旦发生，后果将非常严重，因为用户正在使用的对象是绝对不能被当成死亡对象回收的。而在下文，将讲述两者解决浮动垃圾问题的策略。
在CMS垃圾收集器中使用的是增量更新，增量更新追踪的是黑色对象到白色对象的直接引用，所以除了并发阶段的新增对象，在原始对象图中应该死亡的对象，增量更新算法都能够察觉到。
但是对于G1中的原始快照，记录的是直接引用或间接引用，此时在原始对象图中有一部分对象本来是死亡的，但是会被标记成存活的。另外原始快照也是无法回收并发阶段的新增对象。

在上述对象图中，对象A是死亡的，但是在原始快照算法中，它会被标记为存活对象。

四 总结

（1）原始快照的Remark阶段比增量更新快，因为增量更新要重新扫描新生代，原始快照只需要处理记录下的引用修改。
（2）对于对象消失问题，两者都能解决。
（3）原始快照的浮动垃圾比增量更新多。

五 参考资料

（1） CMS论文地址：http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=708077E17B9BF4DEB8C8A850D34C8D60?doi=10.1.1.22.8915&rep=rep1&type=pdf
（2）G1论文地址：
https://dl.acm.org/doi/pdf/10.1145/1029873.1029879
（3）RednaxelaFX的博客：
https://hllvm-group.iteye.com/group/topic/44381