Java 虚拟机回收算法

一、分代收集类型

1. 部分收集（Partial GC）

非完整收集整个 Java 堆的垃圾收集，分为：

• 新生代收集（Minor GC / Young GC）
  只进行新生代的垃圾收集。
• 老年代收集（Major GC / Old GC）
  只进行老年代收集，目前只有 CMS 收集器会有单独收集老年代的行为。
• 混合收集（Mixed GC）
  目标是收集整个新生代及部分老年代的垃圾收集。目前只有 G1 收集器会有此行为。

2. 整堆收集（Full GC）

收集整个 Java 堆和方法区的垃圾收集。

二、收集算法及优缺点分析

1. 标记 — 清除算法

大多数垃圾收集算法的基础，其他算法是基于其缺点进行的改进。

思想

首先标记出所有需要回收的对象， 标记完成后，统一回收掉所有被标记的对象。也可以反过来，标记存活对象，统一回收未被标记的对象。

缺点

• 执行效率不稳定。当 Java 堆中包含大量对象，其中大部分是需要回收时，就必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率随对象增长而降低。
• 内存空间碎片化。标记、清除会产生大量不连续的内存碎片，后期若连续的内存不足以分配较大的对象时，必须再进行一次垃圾收集操作。

图解

图1. 标记—清除回收前状态

图2. 标记—清除回收后状态

黑色为标记的待回收的对象，白色为未分配内存区域，灰色为存活对象。垃圾回收进行后，待回收部分被全部清除。

2. 标记 — 复制算法

为解决标记 — 清除算法面对大量可回收对象时效率低的问题。

思想

将可用内存按容量划分为大小相等的两块，每次使用一块。当一块的内存用完，就将还存活着的对象复制到另一块上面，然后把已使用的内存空间一次清理掉，

缺点

• 可用内存缩小为了原来的一半。
• 当大多数对象存活时，会带来很大的内存间复制开销。

图解

图3. 标记—复制回收前状态

图4. 标记—复制回收后状态

半区复制算法

大多数商用的 Java 虚拟机都采用这种收集算法去回收新生代。上图以 1 : 1 的比例划分区域，但由于实际使用中新生代对象有 98% 熬不过首轮收集， 1 : 1 的比例显得过于浪费。

于是半区复制算法应运而生，具体方式为：将新生代分为一个较大的 Eden 空间和两个较小的 Survivor 空间，每次内存分配只使用 Eden 空间和其中一块 Survivor 空间。发生 GC 时，将 Eden 和 Survivor 中仍存活的对象一次性复制到另一个 Survivor 分区空间中，随后清除掉 Eden 和已用过的 Survivor 中所有的空间，HotSpot 中默认 Eden 和 Survivor 的大小比例是 8 : 1 ，即可用空间为整个新生代容量的 90%，大大提升了空间使用率。

HotSpot 的 Serial、ParNew 等新生代收集器内存布局均采用此策略。

单次存活对象内存空间占比 > 10% 时，单个 Survivor 无法进行存活对象的存放，如何进行回收？
此半区复制算法特意为此设计了一个充当 逃生门 的设计，当存活对象内存空间占比超过 10% 时，需要利用其他内存区域（多为老年代）进行分配担保，单个 Survivor 空间不足以容纳的部分将直接进入此内存区域。

3. 标记 — 整理算法

为解决标记 — 复制算法在对象存活率较高时需进行较多复制操作，导致效率变低，且当出现所有对象都存活时，需要使用其他内存区域。

思想

标记过程同标记 — 清除算法一样，但后续过程不是直接对可回收对象进行清理，而是让所有存活对象都向内存空间一端移动，随后清理边界以外的内存。相对于标记 — 清除这种非移动式的回收算法，标记 — 整理属于移动式回收算法。

缺点

• 老年代这种大量对象存活的区域，移动存活对象并更新所有引用这些对象的地方是一种极为负重的操作，这些操作须全程暂停用户线程才能进行。

图解

图5. 标记—整理回收前状态

图6. 标记—整理回收后状态

吞吐量分析

尽管标记 — 清除算法完全不用考虑移动和整理存活对象，但弥散在堆中的存活对象会导致空间碎片化，需依赖更复杂的内存分配器和内存访问器解决。而内存访问是用户程序最频繁的操作，内存碎片化会直接影响吞吐量。

抉择

移动对象 — 需要停顿，但吞吐量会更高。
不移动对象 — 不需要停顿，但吞吐量更低。

故更关注吞吐量的 Parrallel Old 收集器是基于标记 — 整理算法的，而更关注延迟的 CMS 收集器是在内存碎片化程度比较小时是基于标记 — 清除算法，当碎片化程度大到影响对象分配时，再采用标记 — 整理算法收集一次，换来更规整的空间。