对增量跟新和原始快照理解

最近在复盘jvm模块的学习内容时 遇到个问题想了好几天,贴一下自己的理解

在hostpot虚拟机实现细节里有一个三色标记算法,

首先先理解三色标记

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

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

灰色：表示对象已经被垃圾回收器访问过，但这个对象至少存在一个引用还没有被扫描过。标记结束，不存在灰色对象

图1:

如上图,在和用户线程并发标记的过程中可能会出现以上两种情况:

1. 把原本消亡的对象错误标记为存活， 产生浮动垃圾而已，但可以下次收集清理

2.是把原本存活的对象错误标记为已消亡，这就是非常致命的后果了，程序会因此发生错误

jvm也说了需要同时满足下面两个条件会产生“对象消失”的问题，即原本应该是黑色的对象被误标为白色

1.赋值器插入了一条或多条从黑色对象到白色对象的新引用；

2· 赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

正文开始:

 

我们把图一中的第一行看作原始快照

在第三行中,用户线程对6进行操作 断开6对9的引用, 5开始引用9,这个时候不管用增量更新把5变成灰色重新扫描一遍 或者用原始快照(原始快照第一行,这里9原来就是在root链上的可达对象,所以也不会被回收掉)再次进行扫描,都不会把9当成垃圾对象回收掉; 

ok,那么问题来了,如果这个时候5引用了1,1应该变为黑色的可达对象才对,如果用增量更新,这里5会变成灰色对象,会重新扫描,最终扫描结果 5 1 6 9都会变成黑色的可达对象,ok这是没有问题的;

再说说使用原始快照的情况下:在并发标记过程中由于5本身就是黑色对象,黑色对象在并发标记过程中不会重新扫描,所以我们在并发标记结束后,1还会是白色的;现在并发标记结束,我们会有一个stw的重新标记,这个重新标记采用原始快照来判断,但是1在原始快照里就是白色的对象,是不可达的,还是要被判定成垃圾回收掉的, 那么这个时候肯定就不对了,被用户线程引用的对象怎么能被回收掉呢?

这个问题我想了好几天,也向周志明老师在github上提了issue(但还没人回答),经过好几天的思考还有和朋友的讨论,上面的关于被用户线程引用的对象怎么能被回收掉的问题有了答案.

先说答案:首先5是不能对1进行引用的,因为1是不可达对象,也就是说,从gcroots出发,或者说从所有活着的对象出发,是没有可达的对象对1进行引用的,除了jvm以外,是没有人知道这个对象的位置的,所以5对1的引用是不成立的.

在看前面jvm给出的产生“对象消失”的问题的两个必要条件:

1.赋值器插入了一条或多条从黑色对象到白色对象的新引用；

2·赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

这两个条件是需要同时满足的,我们再回来看5引用1这种情况,我们可以发现这是不满足条件2的,如果5引用1的话,根本就没有灰色对象对白色对象引用的删除.