彻底理解JVM垃圾回收-重要概念理解（九）

根节点枚举

固定可作为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）主动式中断：当垃圾收集时需要中断用户线程时，不需要直接对线程操作，仅仅简单的设置一个标志位，各个线程执行过程时，会不停的主动轮询这个标志位。一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的，另外还