理解Java虚拟机（五）HopSpot虚拟机的算法具体实现

  Java虚拟机实现垃圾收集算法时，必须对算法的执行效率有严格的考量，才能保证虚拟机高效运行。

一、根节点枚举

  所有收集器在根节点枚举这一步骤时都是必须暂停用户线程的。让执行子系统看起来就像被冻结在某个时间点上，不会出现分析过程中，根节点集合的对象引用关系还在不断变化的情况。

  而跟节点枚举这个操作是非常耗时的，必须做到高效。

  HotSpot 使用一组称为OopMap的数据结构作为优化。一旦类加载动作完成，HotSpot就会把对象内哪些偏移量上是哪些类型的数据计算出来，在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信息。

二、安全点

  在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本就会高昂到无法忍受。

  解决方案之一是在“特定的位置”记录信息，生成OopMap，这些记录位置点被称为安全点（Safepoint）。

  对于安全点，如何在垃圾收集发生时让所有线程都跑到最近的安全点，然后停顿下来，有两种方式：

2.1 抢先式中断 （Preemptive Suspension）

  抢先式中断不需要线程的执行代码主动去配合。

  在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。

  现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

2.2 主动式中断（Voluntary Suspension）

  仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。

  轮询标志的地方和安全点是重合的，另外还要加上所有创建对象和其他需要在Java堆上分配内存的地方，这是为了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。

三、安全区域

  上文提到的安全点方法存在一个隐患，如果程序没有被分配处理器时间，比如用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己。

  另外一种解决方案就是安全区域，指能够确保在某一段代码片段之中，引用关系不会发生变化的区域。在这个区域中任意地方开始垃圾收集都是安全的。我们也可以把安全区域看作被扩展拉伸了的安全点。

• 当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。

• 当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那线程就当作没事发生过，继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止。

四、记忆集与卡表

  记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。

  最简单的实现可以用非收集区域中所有含跨代引用的对象数组来实现这个数据结构。有三种实现方式：

• 字长精度：每个记录精确到一个机器字长（就是处理器的寻址位数，如常见的32位或64位这个 精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。

• 对象精度：每个记录精确到一个对象，该对象里有字段含有跨代指针。

• 卡精度：每个记录精确到一块内存区域，该区域内有对象含有跨代指针。

  其中，第三种“卡精度”所指的是用一种称为“卡表”（Card Table）的方式去实现记忆集，这也是目前最常用的一种记忆集实现形式。

  卡表最简单的形式可以只是一个字节数组，而HotSpot虚拟机确实也是这样做的。 （之所以使用byte数组而不是bit数组主要是速度上的考量，现代计算机硬件都是最小按字节寻址的， 没有直接存储一个bit的指令，所以要用bit的话就不得不多消耗几条shift+mask指令。具体可见HotSpot 应用写屏障实现记忆集的原始论文《A Fast Write Barrier for Generational Garbage Collectors》 （http://www.hoelzle.org/publications/write-barrier.pdf））

  字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”（Card Page）。HotSpot中使用的卡页是2的9次幂，即512字节。

五、如何维护高并发下的卡表

5.1 写屏障

  如何在对象赋值的那一刻去更新维护卡表呢？ 假如是解释执行的字节码，那相对好处理，虚拟机负责每条字节码指令的执行，有充分的介入空间；

  但在编译执行的场景中呢？

  经过即时编译后的代码已经是纯粹的机器指令流了，这就必须找到一个在机器码层面的手段，把维护卡表的动作放到每一个赋值操作之中。

  写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面。

  在引用对象赋值时会产生一个环形（Around）通知，供程序执行额外的动作，也就是说赋值的 前后都在写屏障的覆盖范畴内。在赋值前的部分的写屏障叫作写前屏障（Pre-Write Barrier），在赋值后的则叫作写后屏障（Post-Write Barrier）。

5.2 伪共享

  伪共享（False Sharing）是处理并发底层细节时一种经常需要考虑的问题，现代中央处理器的缓存系统中是以缓存行（Cache Line） 为单位存储的，当多线程修改互相独立的变量时，如果这些变量恰好共享同一个缓存行，就会彼此影响（写回、无效化或者同步）而导致性能降低。

为了避免伪共享问题，一种简单的解决方案是不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表元素未被标记过时才将其标记。

六、并发的可达性分析

6.1 并发存在的问题

  想解决或者降低用户线程的停顿，就要先搞清楚为什么必须在一个能保障一致性的快照上才能进行对象图的遍历？

用户线程同时在修改引用关系——即修改对象图的结构，这样可能出现两种后果。

• 把原本消亡的对象错误标记为存活， 这不是好事，但其实是可以容忍的，只不过产生了一点逃过本次收集的浮动垃圾而已，下次收集清理掉就好。

• 把原本存活的对象错误标记为已消亡，这就是非常致命的后果了，程序肯定会因此发生错误。

6.2 并发的解决方法

  有两种方法可以解决并发存在的问题，增量更新和原始快照。

6.2.1 增量更新

  当已被垃圾收集器访问过的对象插入新的未被垃圾收集器访问过的对象引用关系时，就将这个新插入的引用记录下来，等并发扫描结束后，再将这些记录过的为根，重新扫描一次。

6.2.2 原始快照

  当未被垃圾收集器完全访问的对象要删除指向从未被垃圾收集器访问的对象引用关系时，就将这个要删除的引用记录下来，在并发扫描结束后，再将这些记录过的为根，重新扫描一次。

  以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。在 HotSpot虚拟机中，增量更新和原始快照这两种解决方案都有实际应用，譬如，CMS是基于增量更新 来做并发标记的，G1、Shenandoah则是用原始快照来实现。

七、小结

  本篇介绍HotSpot虚拟机垃圾收集算法的具体实现，可以看到，实际实现碰到的问题很多，需要严谨的考量，才能真正确保执行效率。