JVM—HotSpot的算法细节实现

HotSpot的算法细节实现

一、根节点枚举

当前的JVM虽然在进行可达性分析时可以做到与用户线程并发执行，但是在根节点枚举时还是会导致STW （Stop The World），即暂时挂起所有用户线程。

但根节点枚举始终还是必须在一个能保障一致性的快照中才得以进行（“一致性”的意思是整个枚举期间执行子系统看起来就像被冻结在某个时间点上， 不会出现分析过程中， 根节点集合的对象引用关系还在不断变化的情况）， 若这点不能满足的话， 分析结果准确性也就无法保证。 这是导致垃圾收集过程必须停顿所有用户线程的其中一个重要原因， 即使是号称停顿时间可控， 或者（几乎） 不会发生停顿的CMS、 G1、ZGC等收集器， 枚举根节点时也是必须要停顿的。

目前主流Java虚拟机使用的都是准确式垃圾收集，所以当用户线程停顿下来之后， 其实并不需要一个不漏地检查完所有执行上下文（例如虚拟机栈中的局部变量表）和全局的引用（例如常量或类静态属性）位置。在HotSpot的解决方案里， 是使用一组称为OopMap的数据结构来直接得到哪些地方存放着对象引用的。

类加载完成时，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在JIT过程中，JVM也会在特定位置记录下栈里和寄存器里哪些位置是引用，这样收集器在扫描时就可以直接得知这些信息了， 并不需要真正一个不漏地从方法区等GC Roots开始查找。

二、安全点（Safepoint）

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点（Safepoint） ”

• 安全点的选择很重要，如果太少，则会导致GC等待时间过长；如果太多则会频繁触发GC，严重影响性能。
• 大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择些执行时间较长的指令作为Safe Point， 如方法调用、循环跳转和异常跳转等。

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

• 抢先式中断： （目前没有虚拟机采用了） 首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。应该很容易就看出此方式性能很差了吧

• 主动式中断： 设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。

• 因为轮询操作在代码中频繁出现，所以在HotSpot中，把轮询的操作精简到只有一条汇编指令的程度。

当需要暂停用户线程时，虚拟机把0x160100的内存页设置为不可读，当线程执行到test指令时，此时就会产生一个自陷异常信号，用异常处理器将自己线程挂起。

三、安全区域（Safe Region）

Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint 。但是，程序“不执行”的时候呢？例如线程处于Sleep 状态或Blocked状态，这时候线程无法响应JVM的中断请求，“走” 到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域（Safe Region）来解决。
 安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region 看做是被扩展了的Safepoint。

• 可以把安全点理解为古代时候的驿站，而安全区域则是两个驿站之间的区域。

实际执行时:

• 当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程；
• 当线程即将离开Safe Region时， 会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开SafeRegion的信号为止

四、记忆集与卡表（Remembered Set And Card Table）

记忆集(Remembered Set)与卡表就是为了解决跨代引用带来的问题，以避免在进行可达性分析时，把整个老年代加入到GC Roots扫描范围。实际上，并不只有新生代、老年代之间才会存在跨代引用的问题，所有涉及到部分区域收集（Partial GC） 行为的垃圾收集器（ G1、 ZGC和Shenandoah收集器 ）都会存在相同问题。

以下Remembered Set简称Rset

记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。 每个Region默认按照512Kb划分成多个Card，所以RSet需要记录的东西应该是 xx Region的 xx Card。 如果不考虑效率和成本的话， 最简单的实现可以用非收集区域中所有含跨代引用的对象数组来实现这个数据结构：

Class RememberedSet { 
    Object[] set[OBJECT_INTERGENERATIONAL_REFERENCE_SIZE];
}

如下图，Region2就是需要被收集区域，Region1和Region3是非收集区域

• 关于Region描述请参考《JVM—垃圾收集器详细介绍》中的5.2小结；跨代引用问题请参考《JVM—垃圾回收算法》中的3.1小结

收集器只需要通过记忆集判断某个内存区域是否存在跨代引用就可以，将收集区域分成若干个区域，记忆集保存的是这些区域中是否有跨代引用。

列举出几种不同精度的解决方案：

• 字长精度：每个记录精确到机器字长(就是CPU的寻址长度，比如32位、64位，该精度决定机器访问物理内存地址的指针长度)，该字中包括跨代指针。
• 对象精度：每个记录精确到对象，该对象中有字段包含跨代指针。
• 卡精度：每个记录精确到一块内存区域，该内存区域中含有跨代指针的对象。

第三种卡精度是一种“卡表(Card Table)”的方式去实现的Rset，这也是目前最常用的一种Rset实现方式。

卡表最简单的的形式可以只是一个字节数组，Hotspot确实也是这样实现的：

CARD_TABLE [this address >> 9] = 0;

字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块， 这个内存块被称作“卡页”（Card Page） 。 一般来说， 卡页大小都是以2的N次幂的字节数， 通过上面代码可以看出HotSpot中使用的卡页是2的9次幂， 即512字节（地址右移9位， 相当于用地址除以512），这也与开头说到的“每个Region默认按照512Kb划分成多个Card”相对应。

4.1 Rest解决跨代引用问题的原理

一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多）对象的字段存在着跨代指针，那就将对应卡表的数组元素的值标识为1， 称为这个元素变脏（Dirty），没有则标识为0。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它们加入GC Roots中一并扫描。

五、 写屏障

为了解决卡表元素维护问题（ 例如它们何时变脏、 谁来把它们变脏等），引出了写屏障。

卡表元素是在有其他分代区域中对象引用本区域的对象时，对应的卡表元素应该变脏，即引用类型赋值的那一刻。

如何在赋值时刻维护卡表元素呢？

• 如果JVM是解释执行字节码，虚拟机负责每条字节码指令的执行， 有充分的介入空间
• 如果是编译执行，编译后的代码已经是纯粹的机器指令流了，无法控制

在HotSpot虚拟机里是通过写屏障（Write Barrier）技术维护卡表状态的。 屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形（Around）通知，供程序执行额外的动作。

写屏障分为写前屏障（ 赋值前的部分）和写后屏障（ 赋值前的部分）。但直至G1收集器出现之前， 其他收集器都只用到了写后屏障

应用写屏障后， 虚拟机就会为所有赋值操作生成相应的指令， 每次只要对引用(卡表元素)进行更新，就会产生额外的开销。

除了在写屏障需要有开销以外，卡表还面临一个问题：伪共享(False Sharing)问题，具体就是由于现代CPU的缓存系统用的是缓存行，而当多线程修改相互独立的变量时，而这些变量又处于同一行，就会彼此影响，导致性能下降

六、 并发的可达性分析

先提出一个问题：为什么遍历对象图的时候必须在一个能保障一致性的快照中？

为了说明这个问题，先看一下“三色标记”。

在遍历对象图的过程中，把需要遍历的对象按照“是否访问过”分为以下三种颜色。

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

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

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

上图是在可达性分析的扫描过程中，如果只有垃圾回收线程在工作，那肯定不会有任何问题。

如果用户线程和GC线程并发执行时，就会出现对象消失的情况。如下图

看完上图，是不是有点理解了开头那个问题：为什么遍历对象图必须在一个保障一致性的快照中。

• 如果不保障一致性，对象会消失。

下面就来说一下如何解决这个问题。

一个叫Wilson的大佬，他在1994年在理论上证明了，当且仅当以下两个条件同时满足时，会产生"对象消失"的问题，原来应该是黑色的对象被误标为了白色：

• 条件一：赋值器插入了一条或者多条从黑色对象到白色对象的新引用。

• 条件二：赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

反过来想，是不是破坏其中一个条件，就不会存在对象消失的情况了吧。

因此，我们要解决并发扫描时的对象消失问题，只需破坏这两个条件的任意一个即可。由此分别产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB） 。

• 增量更新(Incremental Update)：打破了第一个条件，在扫描过程中，如果黑色对象插入了新的白色对象引用，那么就将这些黑色对象记录起来作为GC Roots，在扫描结束的时候重新扫描以这些为Root的引用链。其实就可以很简单的理解成，在黑色对象插入新的白色对象引用以后，就重新变成了灰色对象。
• 原始快照(Snapshot At The Beginning,SATB):打破了第二个条件。在扫描过程中，如果出现灰色对象删除白色对象的引用时，就将这些灰色对象记录下来。在扫描结束后，对这些灰色对象重新扫描一遍。

以上无论是对引用关系记录的插入还是删除 “写屏障”来完成。

• 增量更新使用的是写后屏障（记录插入后的新引用）
• 原始快照使用的是写前屏障（记录删除后的前引用）

在HotSpot虚拟机中， 增量更新和原始快照这两种解决方案都有实际应用， 譬如， CMS是基于增量更新来做并发标记的， G1、 Shenandoah则是用原始快照来实现。

• 在《JVM—垃圾收集器详细介绍》中的5.3.2小节简单提到了SATB算法