JVM—垃圾收集算法和HotSpot算法实现细节

1、分代回收策略

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。
分代垃圾回收采用分治的思想，进行代的划分，把不同生命周期放在不同代上，不同代采用最适合它的垃圾回收方法进行回收。

1.1 代际划分

1.2 垃圾回收

1.2.1 年轻代（新生代）

年轻代会划分出Eden区域与两个大小对等的Survivor区域。其比例一般为8：1：1，这是因为根据统计95%的对象朝生夕死，存活时间极短。

当新对象生成，并且在Eden申请空间失败时，就会触发GC，清理Eden中的非存活对象，并且把存活的对象移动到Survivor区，接下来整理两个Survivor区域。
这种方式不会影响到年老代，因为大部分对象都是从Eden区开始的，所以Eden区垃圾回收十分频繁，需要快速、高效的算法（一般采用复制算法）。

1.2.2 年轻代收集（Minor GC/Young GC）

当新对象在Eden区域内存分配失败时就会触发年轻代的垃圾回收，称之为“Minor GC”。
每个对象都有一个年龄，这个年龄就是指对象经历过Minor GC的次数。

如图一所示，对象刚分配到Eden时年龄为“0”，当Minor GC被触发时，所有存活的对象会被拷贝到其中一个Survivor区域中，同时年龄增长“1”，最后清除Eden区域非可达对象。

如图二所示，当第二次Minor GC被触发时、JVM会通过Mark算法（标记算法）找出Eden区域和Survivor1区域存活的对象并将他们拷贝到新的Survivor2区域，同时年龄增长加“1”，最后清除Eden区域和Survivor1区域非可达对象。

如图三所示，当对象年龄足够大（年龄通过JVM参数设置），并且Minor GC再次发生，他就会从Survivor内存区域升级到年老代中。

1.2.3 年老代

年老代是用来存放长时间存活的对象的内存区域。
当对象在新生代中经历了多次垃圾回收仍然存活时，它们会被晋升到年老代。
年老代的垃圾回收频率较低，并且每次回收的成本较高。

在年老代选择的垃圾回收算法取决于JVM采用的什么垃圾回收器

1.2.4 年老代收集（Major GC/Old GC）

当Minor GC发生时，又有对象从Survivor区域升级到Tenured区域，但是Tenured区域没有空间容纳新的对象，此时就会触发年老代的垃圾回收。
年老代的垃圾回收算法取决于JVM选择的垃圾回收器。

2、垃圾收集算法（Mark）

2.1 标记-清除算法（Mark-Sweep）

过程：

算法分为标记、清除两个过程。

首先标记出所有需要回收的对象/标记存活的对象。
接下来清除未被标记的对象。

标记清除算法是最基础的算法，后续收集算法基本上都是以标记-清除算法为基础。

标记-清除算法的主要缺点有两个：

执行效率不稳定，如果 Java堆中有大量对象并且其中大部分需要回收，这时必须进行大量的标记清除动作导致两个过程执行效率随对象数量增加而增大。
空间碎片化严重，会产生大量不连续的空间碎片，碎片太多分配较大对象会导致没有足够的连续内存从而发生垃圾回收。

标记-清除算法执行过程如图所示：

2.2 标记-复制算法（Mark-Copy）

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。

过程：

当其中一块内存用完时，将存活的对象复制到另一块上面。
然后清除使用过的这块内存。

标记-复制算法的缺点：

如果内存大多对象都是存活的，这种算法会产生大量的内存复制间的开销。
复制算法的代价就是将可用内存缩小了原来的一半，空间浪费较大。

标记-复制算法的执行过程：

2.3 标记-整理算法（Mark-Compact）

针对于年老代对象的存亡特征，提出了标记-整理算法，其标记过程和“标记-清除”算法一样，但是后续不是清除可回收对象而是让所有存活的对象都向内存空间一端移动。

标记-清除算法和标记-整理算法本质差异在于前者是一种非移动式的回收算法，而后者是移动的。
优点：这种方式避免碎片内存的产生，又不需要两块相同的内存
缺点：压缩操作需要进行局部对象移动

3、HotSpot算法的实现细节

3.1 根节点枚举

所谓“一致性”就是整个枚举期间不会出现枚举过程中，整个根节点集合的对象引用在不断发生变化。

主流Java虚拟机都是使用的准确式垃圾收集。当用户线程停下时，不需要一个不漏的检查所有执行上下文和全局引用位置。

在HotSpot的解决方案中：

使用一组称为OopMap的数据结构来达到目的。
一旦类加载完成，HotSpot就会将对象内什么偏移量上是什么类型的数据计算出来。
在即时编译中也会在特定位置（安全点）记录栈和寄存器里哪些位置是引用。

这样收集器扫描就可以直接得到这些信息，而不需要一个不漏的从方法区等待GC Roots查找。

3.2 安全点

导致OopMap内容变化的指令非常多，如果为每个指令生成对应的OopMap将需要大量的额外存储空间。
安全点决定了用户执行时不能在代码指令流的任意位置停下来进行GC，必须强制到达安全点才能执行GC。
安全点一般选取在“是否具有长时间执行特征”的地方，例如方法调用、循环跳转、异常跳转。

如何让垃圾收集发生时所有线程都跑到最近的安全点，然后停顿？

抢先式中断：在GC发生时，系统把用户线程全部中断，如果发现有中断的线程不在安全点上，就恢复这条线程执行，让它直到跑到安全点上中断。（现在几乎没有虚拟机采用这种方式）
主动式中断：需要中断线程时，不直接操作线程而是简单的设置一个标志位，各个线程执行时会不停的主动询问这个标志。一旦这个标志位为真就在自己最近的安全点上主动中断挂起。

3.3 安全区域

安全点似乎已经完美解决了停顿用户线程，让虚拟机进行垃圾回收状态。但是当程序“不执行”时，安全点就没有作用。

典型场景：用户线程处于Sleep状态/Blocked状态，这时线程无法响应虚拟机中断请求，不能走到安全的地方去中断挂起自己。

安全区是指确保在某一代码片段中，引用关系不会发生变化。因此这个区域任意地方发生垃圾回收都是安全的。
当用户线程执行安全区的代码，首先会标记自己已经进入了安全区域，这段时间虚拟机发起GC就不会管已声明自己在安全区的线程。
当线程需要离开安全区时，它会先检查虚拟机是否完成根节点枚举（或者GC过程中其他需要暂停用户线程的阶段）。如果完成那么线程就会继续执行，否则就会一直等待，直到收到离开安全区域的信号为止。