网站建设帮助中心,网上在哪里注册公司,无锡有哪些互联网公司,seo怎么推广并发的可达性分析
前面在介绍对象是否已死那一节有说到可达性分析算法#xff0c;它理论上是要求全过程都基于一个能保障一致性的快照#xff08;类比 MySQL 的MVCC#xff09;中才能够进行分析#xff0c;也就意味着必须全程冻结用户线程的运行#xff08;STW#xff0…并发的可达性分析
前面在介绍对象是否已死那一节有说到可达性分析算法它理论上是要求全过程都基于一个能保障一致性的快照类比 MySQL 的MVCC中才能够进行分析也就意味着必须全程冻结用户线程的运行STW。
在根节点枚举这个步骤中说到它是 STW 的。但 GC Roots 在整个Java堆中全部的对象毕竟还算是极少数且在各种优化技巧如OopMap的加持下它带来的停顿已经是非常短暂且相对固定不随堆容量而增长的了。可从GC Roots再继续往下遍历对象图这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了致命的也就是堆越大、存储的对象越多、对象图结构越复杂那么要标记更多对象而产生的停顿时间就更长。然而衡量一个垃圾收集器的好坏停顿时间是一个非常重要的指标。如果你是追求极致性能的垃圾收集器的设计者你肯定不甘于在可达性分析过程中停顿用户线程。所以他们期望在这个过程中可以并发。那他们怎么解决这个问题呢
想解决或者降低用户线程的停顿就要先搞清楚为什么必须在一个能保障一致性的快照上才能进行对象图的遍历
其实你也可以先想象一下在并发可达性分析过程中不采取任何技术手段会出现什么问题。比如在某一个GC roots 的对象图 已经标记完成了此时用户线程再创建一个对象引用到前面已经编辑完成的对象图中那么由于新插入的对象引用没有对标记到那么再GC 时大概率就会被清除这样的结果是致命的类比下日常工作中的情况。
可能我这样说有点通俗啊我们也可以一起看下官方的叙述说明他们是怎么解释这个问题的
为了能解释清楚这个问题他们引入三色标记作为工具来辅助推导把遍历对象图过程中遇到的对象按照“是否访问过”这个条件标记成以下三种颜色
白色表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段所有的对象都是白色的若在分析结束的阶段仍然是白色的对象即代表不可达。黑色表示对象已经被垃圾收集器访问过且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过它是安全存活的如果有其他对象引用指向了黑色对象无须重新扫描一遍。黑色对象不可能直接不经过灰色对象指向某个白色对象。灰色表示对象已经被垃圾收集器访问过但这个对象上至少存在一个引用还没有被扫描过。去到图二解释下 总结收集器在对象图上标记颜色同时用户线程在修改引用关系——即修改对象图的结构这样可能出现两种后果
一种是把原本消亡的对象错误标记为存活这不是好事但其实是可以容忍的只不过产生了一点逃过本次收集的浮动垃圾而已下次收集清理掉就好问题不大。另一种是把原本存活的对象错误标记为已消亡这就是非常致命的后果了程序肯定会因此发生错误。
如何解决这个问题
Wilson于1994年在理论上证明了当且仅当以下两个条件同时满足时会产生“对象消失”的问题即原本应该是黑色的对象被误标为白色
并发中插入了一条或多条从黑色对象到白色对象的新引用并发中删除了全部从灰色对象到该白色对象的直接或间接引用。
因此我们要解决并发扫描时的对象消失问题只需破坏这两个条件的任意一个即可类似于避免死锁的思路。由此分别产生了两种解决方案增量更新Incremental Update和原始快照Snapshot At The Beginning SATB。
增量更新破坏的是第一个条件当黑色对象插入新的指向白色对象的引用关系时就将这个新插入的引用记录下来等并发扫描结束之后再将这些记录过的引用关系中的黑色对象为根重新扫描一次。通俗的讲就是黑色对象一旦新插入了指向白色对象的引用之后它就变回灰色对象了。
**原始快照破坏的是第二个条件**当灰色对象要删除指向白色对象的引用关系时就将这个要删除的引用记录下来在并发扫描结束之后再将这些记录过的引用关系中的灰色对象为根重新扫描一次。通俗的讲就是论引用关系删除与否都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。
以上无论是对引用关系记录的插入还是删除虚拟机的记录操作都是通过写屏障实现的。在HotSpot虚拟机中增量更新和原始快照这两种解决方案都有实际应用譬如CMS是基于增量更新来做并发标记的G1、Shenandoah则是用原始快照来实现。
