HotSpot的准确式GC

前言
在上一篇文章我们学习到了Java虚拟机是如何利用可达性算法判断对象是否需要回收的，由于在GC进行时，必须暂停所有的Java执行线程（Sun称之为“Stop The World”），所以，虚拟机必须尽量的优化GC过程的效率，减少暂停的时间。那么对于GC Roots，HotSpot是如何快速确定的呢？

对象的创建
首先，我们需要知道在JVM中，对象是如何被创建的。

而对象的创建通常是通过new一个对象而已，当虚拟机接收到一个new指令时，它会做如下的操作:

（1）判断对象对应的类是否加载、链接、初始化

虚拟机接收到一条new指令时，首先会去检查这个指定的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被类加载器加载、链接和初始化过。如果没有则先执行相应的类加载过程。关于类加载器我们在前一篇文章中已经提到过，这里不再赘述。

（2）为对象分配内存

类加载完成后，接着会在Java堆中划分一块内存分配给对象。内存分配根据Java堆是否规整，有两种方式：

指针碰撞：如果Java堆的内存是规整，即所有用过的内存放在一边，而空闲的的放在另一边。分配内存时将位于中间的指针指示器向空闲的内存移动一段与对象大小相等的距离，这样便完成分配内存工作。

空闲列表：如果Java堆的内存不是规整的，则需要由虚拟机维护一个列表来记录那些内存是可用的，这样在分配的时候可以从列表中查询到足够大的内存分配给对象，并在分配后更新列表记录。

（3）处理并发安全问题

创建对象是一个非常频繁的操作，所以需要解决并发的问题，有两种方式：

对分配内存空间的动作进行同步处理，比如在虚拟机采用CAS算法并配上失败重试的方式保证更新操作的原子性。

每个线程在Java堆中预先分配一小块内存，这块内存称为本地线程分配缓冲（Thread Local Allocation Buffer）简写为TLAB，线程需要分配内存时，就在对应线程的TLAB上分配内存，当线程中的TLAB用完并且被分配到了新的TLAB时，这时候才需要同步锁定。通过-XX:+/-UseTLAB参数来设定虚拟机是否使用TLAB。

（4）初始化分配到的内存空间

将分配到的内存，除了对象头都初始化为零值。

（5）设置对象的对象头

将对象的所属类、对象的HashCode和对象的GC分代年龄等数据存储在对象的对象头中。

（6）执行init方法进行初始化

执行init方法，初始化对象的成员变量、调用类的构造方法，这样一个对象就被创建了出来。

对象的堆内存布局
在HotSpot虚拟机中，对象在堆内存的布局分为三个区域，分别是对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。

对象头：对象头包括两部分信息分别是Mark World和元数据指针，Mark World用于存储对象运行时的数据，比如HashCode、锁状态标志、GC分代年龄等。而元数据指针用于指向方法区的中目标类的类型信息，通过元数据指针可以确定对象的具体类型。

实例数据：用于存储对象中的各种类型的字段信息（包括从父类继承来的）。

对齐填充：对齐填充不一定存在，起到了占位符的作用，没有特别的含义。

对象分配如下图所示：

HotSpot的对象模型
HotSpot中采用了OOP-Klass模型，它是用来描述Java对象实例的一种模型，OOP（Ordinary Object Pointer）指的是普通对象指针，而Klass用来描述对象实例的具体类型。

HotSpot中，用instanceOopDesc 和 arrayOopDesc 来描述对象头，其中arrayOopDesc对象用于描述数组类型。

通过OOP-Klass模型，我们就知道了Java虚拟机是如何通过栈帧中的对象引用找到对应的对象实例，如下图所示：

从图中可以看出，通过栈帧中的对象引用找到Java堆中的instanceOopDesc对象，再通过instanceOopDesc中的元数据指针来找到方法区中的instanceKlass，从而确定该对象的具体类型。

HotSpot的准确式GC
HotSpot采用了准确式GC以提升GC roots的枚举速度。所谓准确式GC，就是让JVM知道内存中某位置数据的类型什么。比如当前内存位置中的数据究竟是一个整型变量还是一个引用类型。这样JVM可以很快确定所有引用类型的位置，从而更有针对性的进行GC roots枚举。

HotSpot是利用OopMap来实现准确式GC的。当类加载完成后，HotSpot 就将对象内存布局之中什么偏移量上数值是一个什么样的类型的数据这些信息存放到 OopMap 中；在 HotSpot 的 JIT 编译过程中，同样会插入相关指令来标明哪些位置存放的是对象引用等，这样在 GC 发生时，HotSpot 就可以直接扫描 OopMap 来获取对象引用的存储位置，从而进行 GC Roots 枚举。

HotSpot安全点
通过OopMap，HotSpot可以很快完成GC Roots的查找，但是，如果在每一行代码都有可能发生GC，那么也就意味着得为每一行代码的指令都生成OopMap，这样将占用大量的空间。实际上，HotSpot也不会这么做。

HotSpot只在特定的位置记录了OopMap，这些位置就叫做安全点（Safepoint），也就是说，程序并不能在任意地方都可以停下来进行GC，只有到达安全点时才能暂停进行GC。

在安全点中，HotSpot也会开始记录虚拟机的相关信息，如OopMap信息的录入。安全点的选择不能太少，否则GC等待时间太长；也不能太多，否则会增大运行负荷，其选择的原则为“是否具有让程序长时间执行的特征”，如方法调用，循环等等。具体安全点有下面几个：

(1) 循环的末尾 (防止大循环的时候一直不进入Safepoint，而其他线程在等待它进入Safepoint)
(2) 方法返回前
(3) 调用方法的call之后
(4) 抛出异常的位置

而安全点暂停线程运行的手段有两种：抢先式中断和主动式中断。

抢先式中断
不需要线程的执行代码主动配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上再暂停。不过现在的虚拟机几乎没有采用此算法的。

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

HotSpot安全区域
产生原因
安全点机制保证了程序执行时进入GC的问题。但是对于非执行态下，如线程Sleep或者Block下，由于此时程序（线程）无法响应JVM的中断请求，JVM也不太可能一直等待线程重新获取时间片，此时就需要安全区域(Safe Region)了。安全区域是指在一段代码片段内，引用关系不会发生变化，在这段区域内，任意地方开始GC都是安全的。

运行机理
在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region。当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了；当线程要离开Safe Region时，如果整个GC完成，那线程可继续执行，否则它必须等待直到收到可以安全离开Safe Region的信号为止。