本文已收录至 Github，举荐浏览 👉 Java 随想录
微信公众号：Java 随想录
CSDN：码农 BookSea
你愈是少说你的平凡，我将愈想到你的平凡。——培根
面试官：咱们先从 JVM 根底开始问，理解三色标记算法吗？
我：额 …… 不理解。
面试官：进来的时候记得把门带上。
当初 Java 面试真的曾经是越来越卷了，很喜爱问底层实现原理。本篇来聊聊三色标记算法，也是 Java 面试的常客。
三色标记算法能够扯出增量更新和原始快照，聊好了会让面试官感觉你这小伙子有点货色。
三色标记算法
既然叫三色标记算法，首先咱们要搞明确是哪三色，三色是：彩色，红色，灰色。
把遍历对象图过程中遇到的对象，依照 是否拜访过 这个条件标记成以下三种色彩：
- 红色：示意对象尚未被垃圾收集器拜访过。显然在可达性剖析刚刚开始的阶段，所有的对象都是红色的，若在剖析完结的阶段，依然是红色的对象，即代表不可达。
- 彩色：示意对象曾经被垃圾收集器拜访过，且这个对象的所有援用都曾经扫描过。彩色的对象代表曾经扫描过，它是平安存活的，如果有其余对象援用指向了彩色对象，毋庸从新扫描一遍。彩色对象不可能间接（不通过灰色对象）指向某个红色对象。
- 灰色：示意对象曾经被垃圾收集器拜访过，但这个对象上至多存在一个援用还没有被扫描过。
原书中的图画的很好，高深莫测。
因为一些垃圾回收器存在垃圾回收线程和用户线程并发的状况（例如 CMS 的并发阶段），那么三色标记会有 2 个问题：
- 一种是把本来沦亡的对象谬误标记为存活，这不是坏事，但其实是能够容忍的，只不过产生了一点逃过本次收集的浮动垃圾而已，下次收集清理掉就好。
- 另一种是把本来存活的对象谬误标记为已沦亡，这就是十分致命的结果了，程序必定会因而产生谬误。
Wilson 于 1994 年在实践上证实了，当且仅当以下两个条件同时满足时，会产生“对象隐没”的问题，即本来应该是彩色的对象被误标为红色：
- 赋值器插入了一条或多条从彩色对象到红色对象的新援用。
- 赋值器删除了全副从灰色对象到该红色对象的间接或间接援用。
因而，咱们要解决并发扫描时的对象隐没问题，只需毁坏这两个条件的任意一个即可。由此别离产生了两种解决方案：增量更新（Incremental Update）和 原始快照（Snapshot At The Beginning，SATB）。
这 2 种解决方案各毁坏一个条件
增量更新
增量更新要毁坏的是第一个条件，当彩色对象插入新的指向红色对象的援用关系时，就将这个新插入的援用记录下来，等并发扫描完结之后，再将这些记录过的援用关系中的彩色对象为根，从新扫描一次。这能够简化了解为，彩色对象一旦新插入了指向红色对象的援用之后，它就变回灰色对象了。
这其实有点像之前讲过相似 OopMap 的思维，实质也是保护了个映射关系，从新扫描的时候扫描这个映射关系就行了，不必全表扫描。
原始快照
原始快照要毁坏的是第二个条件，当灰色对象要删除指向红色对象的援用关系时，就将这个要删除的援用记录下来，在并发扫描完结之后，再将这些记录过的援用关系中的灰色对象为根，从新扫描一次。这也能够简化了解为，无论援用关系删除与否，都会依照刚刚开始扫描那一刻的对象图快照来进行搜寻。
以上无论是对援用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。写屏障，咱们之前讲记忆集与卡表的时候介绍过的，能够了解为 Spring 中的 AOP，目前为止卡表状态的保护，增量更新，原始快照都是基于写屏障。
另外，CMS 应用的是增量更新，G1 应用的是原始快照。
本篇文章就到这里，如果再遇见面试官问你相似的问题，你能够好好跟他扯皮咯。
如果本篇博客有任何谬误和倡议，欢送给我留言斧正。文章继续更新，能够关注公众号第一工夫浏览。