HotSpot算法实现

之前介绍了对象存活算法和垃圾收集算法，在HotSpot上实现这些算法时，对于算法的执行效率必须严格考量，才能保证算法高效执行。

1.可达性分析算法

以可达性分析算法中从GC Roots节点查找引用链操作为例,对于时间的敏感体现在两个方面：

1.1引用检查时间

作为GC Roots节点的主要在全局性引用（例如常量或者静态属性）与执行上下文（栈帧中的本地变量表），现在的应用中，仅仅方法区就有数百兆，如果如果要逐个检查里面的引用，必然会消耗很多的时间。

1.2Stop The World

可达性分析对于时间的敏感还体现在GC的卡顿上，因为这一项分析工作必须在一个能确保一致性的快照中进行；这里的“一致性”指的是在整个分析期间整个系统就像是被冻结在某个时间点上，不可以存在在分析期间整个系统的引用还在不断变化的情况，该点不满足的话，分析结果的准确性就无法得到保证。这一点是GC进行时，应用必须停顿所有执行线程的一个重要原因，Sun公司称这件事情为，StopThe World。

在HotSpot的实现中，为了直接得知哪些地方存放着对象的引用，使用一组称为OopMap的数据结构来打到这个目的，在类加载完成的时候HotSpot就把对象内什么偏移量上是什么类型的数据记录下来，在JIT编译过程中，在“特定位置”记录下栈和寄存器哪些位置是引用，这样GC在扫描时就可以直接得到这些信息了。

2.安全点

在OopMap的帮助下，HotSpot可以快速而且准确的完成GC Roots枚举，但是一个很现实的问题随之而来：OopMap内容变化的指令非常多，如果为每一条指令都对应生成OopMap，那就会需要大量的而外空间，这样GC的空间成本就会很高。实际上Hospot也不会为每一条指令生成对应的OopMap，前面已经提到只有在“特点的位置”才记录了这些信息，这些特定的位置称之为“安全点”（Safepoint），程序在执行的过程中，并不是在所有的地方都可以停顿下来进行GC，只有在到达安全点时才能暂停。

安全点选定太少导致GC等待时间太长，过多导致过分增大系统运行时负荷，安全点的选定基本上是以程序“是否具有让程序长时间执行”的特征，为标准进行选定的，因为指令都是非常短暂的，程序不可能因为指令流长度太长而长时间运行，“长时间运行”的最明显的特征就是指令序列的复用，例如方法调用，循环跳转，异常跳转等，所有只有这些功能的指令才能产生安全点（Safepoint）。

对Safepoint需要考虑的另一个问题就是：如何在GC发生时让所有线程（这里不包括JNI执行线程）都“跑”到最近的安全点上再停顿下来？

抢先式中断：

在GC发生时，首先把所有线程全部中断，如果发现有线程中断不在安全点上，就回复线程，让它“跑”到安全点上。现在，几乎没有虚拟机采用抢先式中断来中断线程响应GC事件。

主动式中断：

当GC需要中断线程的时候，不直接对线程进行操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时则中断挂起，轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

3.安全区域

使用Safepoint似乎已经完美地解决了如何进入GC的问题，但是实际情况却不一定。Safepoint保证了程序执行时，在不太长的时间内就遇到可进入GC的Safepoint，但是程序不执行的时候尼？

程序不执行就是没有分配到CPU时间，典型的情况就是线程处于Sleep或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也不太可能等到线程重新被分配CPU时间，这种情况就需要安全区域来解决，安全区域是指在一段代码之内，引用关系不会发生变化，在这个区域的任何地方开始GC都是安全的，我们也可以把安全区域看作是扩展了的Safepoint。

当线程执行到安全区域代码时，就标识自己已经进入到了安全区域，那么JVM在这段时间进行GC时就不用管已经标识自己为Safe Region状态的线程了，在线程要离开Safe Region时，就需要检查系统是否已经完成了枚举根节点（或者是整个GC过程），如果完成则代码继续往下执行，没有它就必须等到收到可以离开安全区域的信号为止。