HotSpot垃圾回收算法实现细节和经典收集器

HotSpot的垃圾回收算法实现细节

根节点枚举

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

安全点

在OopMap的帮助下，HotSpot可以快速准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本会变得无法忍受。
实际上HotSpot也的确没有为每条指令都生成OopMap，只是在”特定的位置“记录了这些信息，这些位置被称为安全点（Safepoint）。有了安全点的设定，也就决定了用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太过频繁以至于过分增大运行时的内存负荷。安全点的位置选取基本上时以”是否具有让程序长时间执行的特征“为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，”长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。
对于安全点，另一个需要考虑的问题是，如何在垃圾收集发生时让所有线程（这里其实不包括执行JNI调用的线程）都跑到最近的安全点，然后停顿下来。这里又两种方案可供选择：抢先式终端（Preemptive Suspension）和主动式中断（Voluntary Suspension）。

抢先式中断

抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先要把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

主动式中断

主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时，就自己在最近的安全点上主动中断挂起。轮询标志地地方和安全点时重合的，另外还要加上所有创建对象和其他需要在Java堆上而非你陪内存的地方，这是为了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。
由于轮询操作在代码中会频繁出现，这要求它必须要足够高效。HotSpot使用内存保护陷阱的方式，把轮询操作精简至只有一条汇编指令的程度。

安全区域

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

记忆集与卡表

讲解分代收集理论的时候，提到了为解决对象跨代引用所带来的问题，垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免把整个老年代加进GC Roots扫描范围。事实上并不只是新生代、老年代之间才有跨代引用的问题，所有涉及部分区域收集（Pratial GC）行为的垃圾收集器，典型的如G1、ZGC和Shenandoah收集器都会面临相同的问题，因此有必要进一步理清记忆集的原理和实现方式。
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。如果不考虑效率和成本的话，最简单的实现可以用非收集区域中含有所有跨代引用的对象数组来实现这个数据结构。
这种及记录全部含跨代引用的实现方案，无论是空间占用还是维护成本都相当高昂。而在垃圾收集场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。那设计者在实现记忆集的时候，便可以选择更为粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择的记录精度：

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

文章参考：
《深入理解Java虚拟机第三版》