基本原理
当前主流编程语言的垃圾收集器基本.上都是依靠可达性分析算法来判定对象是否存活的，可达性分析算法理论上要求全过程都基于-一个能保障一致性的快照中才能够进行分析，这意味着必须全程冻结用户线程的运行。由于GC Roots相比起整个Java堆中全部的对象毕竟还算是极少数，且在各种优化技巧(如OopMap) 的加持下，它带来的停顿已经是非常短暂且相对固定(不随堆容量而增长)的了。可从GC Roots再继续往下遍历对象图，停顿时间就必定会与Java堆容量直接成正比例关系了:堆越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长
想解决或者降低用户线程的停顿，就要先搞清楚为什么必须在一一个能保障-致性的快照上才
能进行对象图的遍历?为了能解释清楚这个问题，很多垃圾处理器都引入三色标记(Tri- color Marking)如CMS、G1等。
按照“是否访问过”这个条件标记成以下三种颜色:
- 白色:表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。
- 黑色:表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接(不经过灰色对象)指向某个白色对象。
- 灰色:表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
具体有以下几种情况
多标（浮动垃圾）
- 黑色节点断了后面灰色节点的引用，会导致后面断的灰色节点实际上应该变成白色，但是最终会变成黑色，导致不可回收，因此被称为浮动垃圾
漏标（对象消失）
只有同时满足以下两个条件时才会发生：
- 从一个黑色节点新增一条或多条白色节点
- 删除该白色节点所关联的全部灰色节点的直接或间接引用（该白色节点不被其他灰色节点饮用）
解决漏标
由上述原理可知，只要破坏漏标其中一个条件即可保证漏标现象不出现，不同的垃圾处理器采取不同的方式。
增量更新
增量更新要破坏的是第一一个条件， 当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。CMS 采取的就是这种解决方案。
原始快照（SATB）
原始快照要破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个
要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。这也可以简化理解为，无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。G1采取的就是这种解决方案。
标签：灰色,白色,对象,标记,扫描,引用,节点 来源： https://blog.csdn.net/zhangxiaohui4445/article/details/121608686
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。