根节点枚举

固定可作为GC Roots的节点主要存在全局性引用（例如常量或者类静态属性）与执行上下文（例如栈帧中的本地变量表）中，尽管目标比较明确但是要高效查找这些节点并非易事。迄今为止，所有收集器的根节点枚举这一步都需要暂停用户线程的，毫无疑问枚举根节点需要面临”Stop the world“的困扰。现在可达性分析算法耗时最长的查找引用链的过程已经可以做到与用户线程一起并发（CMS），但根节点的枚举始终还是必须在一个能保障一致性（整个枚举期间执行子系统看起来像被冻结在某个时间点上）的快照中才得以进行，不会出现分析过程中，根节点集合的跟节点引用关心还在不断变化的情况，若这点不能满足的话，分析结果的准确性就无法保证。这是导致垃圾收集过程必须停顿所有用户线程的其中一个重要原因，即使号称停顿时间可控，或者几乎不会发生停顿的CMS、G1、ZGC等收集器，枚举根节点时也是必须要停顿的。
目前主流的Java虚拟机使用的都是准确式的垃圾收集，所有当用户线程停顿下来之后，其实并不需要一个不漏的检查完所有执行上下文和全局的引用位置，虚拟机应当有办法直接得到哪些地方存放着对象引用的。在HotSpot的解决方案中，是使用一组成为OopMap（Ordinary Object Pointer，OOP）的数据结构来达到这个目的的。一旦类加载动作完成的时候，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信息了，并不需要真正一个不漏的从方法区等GC Roots开始查找。

安全点

在OopMap的协助下，HotSpot可以快速准确的完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说导致OopMap的内容变化的指令非常多，如果为每一条指令都生成OopMap，那将需要大量的额外的内存空间去存储。
实际上HotSpot并没有为每条指令生成OopMap，只是在特定位置记录了这些信息，称之为安全点（SafePoint）。有了安全点的设定，也就是决定了用户程序执行时并非在代码指令流的任意位置都能停顿下来进行垃圾收集，而是强制要求必须执行到安全点后才能暂停。因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太多以至于过分增大运行时的内存负荷。安全点位置的选取基本是以”是否具有让程序长时间执行的特征“为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，”长时间执行“的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等属于指令序列复用，所以只有这些工功能的指令才会产生安全点。
垃圾收集发生时，如何让所有线程（不包括执行JNI【Java Native Interface】调用的线程）都跑到最近的安全点，然后停顿下来，这里提供了两种方式：
（1）抢断式中断：抢断式中断不需要线程的执行代码配合，在垃圾收集的时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它跑到最近的安全点上。现在几乎没有虚拟机实现采用抢断式中断来暂停线响应GC事件
（2）主动式中断：当垃圾收集时需要中断用户线程时，不需要直接对线程操作，仅仅简单的设置一个标志位，各个线程执行过程时，会不停的主动轮询这个标志位。一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的，另外还要加上所有创建对象和其他需要在Java堆上分配内存的地方，这是为了方便检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。

安全区域

使用安全点似乎完美解决了如何停顿用户线程，让虚拟机进入垃圾回收状态的问题了，但实际情况并不一定，安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾收集过程的安全点，但是程序“不执行”的时候呢？程序不执行就是没有分配处理器时间，典型的场景就是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方再中断挂起自己，虚拟机也显然不可能等待线程被重新激活分配处理器时间，对于这种情况采用安全区域（Safe Region）来解决。
当用户线程执行到安全区域的代码片段中，引用关系就不会发生变化，因此这个区域中任意位置开始垃圾手机都是安全的，我们也可以把安全域看作被拉伸了的安全点。
当用户线程执行到安全区域的代码时，首先会标识自己已经进入安全域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全域，它要检查虚拟机是否已经完成了根节点的枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那么线程继续执行，否则就一直等待，直到收到可以离开安全域的信号为止。

记忆集与卡表

分代垃圾收集中为了解决对象跨代引用的问题，垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免把整个老年代加进GC Roots扫描范围。事实上并不是只有新新生代、老年代之间才有跨带引用问题，所有涉及部分区域手机行为的垃圾收集器，如G1、ZGC和Shenandoah收集器，都会面临跨代引用的问题。
记忆集是用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。如果不考虑效率和成本的话，最简单的实现可以用非收集区域中所包含跨代引用的对象数组来实现这个数据结构。这个只记录全部含跨代引用对象的实现方案，无论是空间占用还是维护成本都非常高昂。而在垃圾收集的场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨带指针的全部细节。那设计者可以选择比较粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择（当然也可以选择这个范围以外的）的记录精度：
（1）字长精度：记录精确到一个机器字长（就是处理器的寻址位数，如常见的32位或64位，这个精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。
（2）对象精度：每个记录精确到一个对象，该对象里有字段患有跨代指针。
（3）卡精度：每个记录精确到一块内存区域。该区域内有对象含有跨代指针。

其中卡精度是采用一种卡表（Card Table）的方式去实现记忆集，这也是目前最常用的一种记忆集实现形式。记忆集是一种抽象的“数据结构”，而卡表是记忆集的一种具体实现，它定义了记忆集的记录精度、与堆内存的映射关系等。卡表的最简单的形式可以只是一个字节数组，HotSpot虚拟机确实也是这样做的。如下代码为HotSpot的默认卡表实现

CARD_TABLE [this address >> 9] =0

字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称之为卡页。一般来说卡页的大小都是以2的N次幂的字节数，通过上面代码可以看出HotSpot中使用卡页是2的9次幂，即512字节（地址右移9位，相当于除以512）。如果卡表内存起始地址为0x0000的话，数组CARD_TABLE的第0、1、2号元素，分别对应了0x0000~0x001FF、0x0200~0x03FF、0x0400~0x05FF的卡也内存。如图所示：

Card Table and Card Page

写屏障

我们使用记忆集的方式来解决了GC Roots扫描范围的问题，但是还没有解决“卡表”的维护问题，例如它们何时变脏，由谁负责将它们变脏。
卡表何时变脏是明确的——其他分代区域中有对象引用了本区域对象时，其对应的卡表元素就应该变脏，变脏是时间点原则上应该发生在引用类型赋值的那一刻，但如何变脏，即如何在对象赋值的那一刻去更新维护卡表呢？加入是解释执行的字节码，那相对好处理，虚拟机负责每条字节码的执行，有充分的介入空间，但在编译执行的场景下，即时编译后的代码已经是纯碎的机器指令流了，这就必须找到一个在机器码层面的手段，把维护卡表的动作放在每一个赋值操作中。
在HotSpot虚拟机中，是通过写屏障（Write Barrier）技术维护卡表状态。写屏障可以看做虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用类型赋值时，会产生一个环绕通知（Around），供程序执行额外的动作，也就是赋值的前后都是在写屏障的覆盖范围之内。在赋值前的部分的写屏障称为写前屏障（Pre-write Barrier），在赋值之后的称为写后屏障。HotSpot虚拟机除了G1收集器，其他的收集器都只用到了写屏障。 如下代码是写后屏障更新卡表：

void oop_field_store(oop* field,oop new_value){
   //引用类型字段赋值
   *field = new_value;
   // 写后屏障，更新卡表信息
   post_write_barrier(field,new_value);
}

应用写屏障后，虚拟机会为所有赋值操作生成相应的指令，一旦收集器在写屏障中增加了更新卡表操作，无论更新的是不是老年代对新生代的引用，每次只要对引用进行更新，就会产生额外的开销，不过这个开销与Minor GC时扫描整个老年代的代价相比要低很多。
除了写屏障的开销外，卡表在高并发场景下还面临着“伪共享（False Sharing）”问题。伪共享是处理并发底层细节时一种经常需要考虑的问题，现在中央处理器的缓存系统是以缓存行（Cache Line）为单位存储的，当多线程修改相互独立变量时，如果这些变量恰巧共享一个缓存行，就会彼此影响（写回、无效或者同步）而导致性能降低，这是伪共享问题。
假设处理器缓存行大小为64字节，由于一个卡表元素占用一个字节，64个卡表元素将共享同一个缓存行。这64个卡表元素对应的卡页总的内存为32KB（64*512字节），也就是说不同的卡表正好写入同一个缓存行而影响性能，只有当该卡表元素未被标记过时才将其标记为变脏，即卡表更新将加上以下判断逻辑：

if(CARD_TABLE[this address>>9] !=0 ){
    CARD_TABLE[this address>>9] =0;
}

在JDK1.7之后，HotSpot虚拟机增加了一个新的参数-XX:+UseCondCardMark，用来决定时候开启卡表更新的判断逻辑，开启之后会增加一次额外的判断开销，但能避免伪共享问题，两者各有性能损耗，时候开启根据实际运行情况来测试权衡。

并发的可达性分析

当前主流编程语言的垃圾收集器基本上都是依靠可达性分析算法来判定对象是否存活，可达性分析算法理论上要求全过程都基于一个能保障一致性的快照中才能够进行分析，这意味着必须全程都基于一个能保障一致性的快照中才能够进行分析，这就意味着必须全程冻结用户线程的运行。在根节点枚举这个步骤中，由于GC Roots相比整个堆中全部对象相对还是极少数，且还存在各种优化手段（OopMap）的加持下，它带来的停顿已经是非常短暂且相对固定的了（不随堆精简打增长而增长）。可是从GC Roots再往下遍历对象图，这一步骤的停顿时间必定与Java堆空间容量成正比：堆空间越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长久。
“标记”阶段是所有追踪链式垃圾收集算法的共同特征，如果这个阶段会随着堆变大而等比例增加停顿时间，其影响就会波及几乎所有的垃圾收集器，如果能够削弱这部分的停顿时间的话，收益就会是系统性的。
想解决或者降低用户线程的停顿，首先搞清楚为什么要在一个能保证一致性的快照上才能进行对象图的遍历，这边我们引入三色标记（Tri-color Marking）最为工具来辅助推导，我们把遍历对象图过程中的对象，按照“是否访问过”这个条件分成一下三种颜色：
（1）白色：表示对象尚未被垃圾收集器访问过 。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。
（2）黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过，他是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
（3）灰色：表示对象已经被垃圾收集访问过，但这个对象至少存在一个引用还没有被扫描过。

可达性分析过程中，如果是冻结用户线程的情况下，只有收集器线程在工作，不会有任何问题。如果用户线程和收集器是并发工作的情况下，收集器在对象上标记颜色，同时用户线程在修改引用关系——即修改对象的图结构，这样可能出现两种后果。一种是把原本标记消亡的对象错误标记为存活，这种还是可以容忍的，只是产生了一些逃过收集的浮动垃圾而已，下次清理掉就好了。另一种是把原本存活的对象错误标记为已消亡，这就是非常致命的后果，程序肯定会发生错误。下图为对象并发标记时产生错误过程示意图：

在这里插入图片描述

扫一扫