垃圾收集算法：分代收集算法、标记-清除算法、标记-复制算法、标记-整理算法

本文链接：https://blog.csdn.net/lena7/article/details/115563235

垃圾收集算法

分代收集算法

当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”的理论进行设计，分代收集建立在两个分代假说之上：
1. 弱分代假说：绝大多数对象都是朝生夕灭的。
2. 强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡。
这两个分代假说共同奠定了多款常用垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（即对象熬过垃圾收集过程的次数）分配到不同区域之中存储。如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，那么把它们集中放在一起，每次回收只关注如何保留少量存活而不是去标记那些大量将要被回收的对象，就能以低代价回收到大量的空间；如果剩下的都是难以消亡的对象，那把他们集中放在一起，虚拟机便可以使用较低的频率来回收这个区域，这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。
在Java堆划分出不同的区域之后，垃圾收集器才可以每次指挥手其中某一个或者某些部分的区域——因而才有了“Minor GC”、“Major GC”、“Full GC”这样的回收类型的划分，也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法——标记复制算法、标记清除算法、标记整理算法等针对性的垃圾收集算法。

部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集器，其中又分为：
新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。（Major GC在不同资料有不同所指，需根据上下文区分是老年代收集还是整堆收集）
混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。

整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

分代收集并不是简单划分一下内存区域那么容易，它至少存在一个明显的困难：对象不是孤立的，对象之间会存在跨代引用。存在互相引用关系的两个对象是应该倾向于同时生存或者同时消亡的。假如现在要进行一次只局限于新生代区域内的收集，但新生代的对象完全有可能被老年代所引用，为了找出该区域中的存活对象，不得不在固定的GC Roots之外，在额外遍历整个老年代中所有对象来确保可达性分析结果的正确性。遍历整个老年代所有对象的方案虽然理论上可行，但无疑会为内存回收带来很大的性能负担，因此分代收集理论添加了第三条经验法则：
1. 跨代引用假说：跨代引用相对于跨代引用来说仅占极少数。
依据这条假说，我们不应该为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用，只需在新生代上建立一个全局的数据结构（该结构被称为“记忆集”），这个结构把老年代划分成若干小块，标识出老年代哪一块内存会存在跨代引用。当发生Minor GC，只有包含了跨代引用的小块内存里的对象会被加入到GC Roots进行扫描。

标记-清除算法

标记-清除算法是最早出现也是最基础的垃圾收集算法。
执行过程：算法可分为两个阶段（标记和清除）：首先标记处所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。（其中，标记过程就是判断对象是否属于垃圾。）
缺点：
1. 执行效率不稳定。如果Java堆中包含大量对象，且其中大部分都是需要被回收的，这时必须进行大量标记和清除动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低。
2. 内存空间的碎片化问题。标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序允许过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

标记-复制算法

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，1969年Fenichel提出了“半区复制”垃圾收集算法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对虾，而且每次都是针对整个半区进行回收，分配内存是也就不用考虑有空间碎片的复杂清空，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效，不过空间浪费大，将可用内存缩小为原来的一半。
现在商用Java虚拟机大多优先采用这种算法回收新生代。
1989年，Andrew Appel提出了一种更优化的半区复制分代策略，现在成为“Appel式回收”。Appel式回收具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾收集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和那块已经用过的Survivor空间。Appel式回收回收还有“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor GC存活的对象时，就需要依赖其他内存区域进行分配担保。分配担保：如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，这些对象便将通过分配担保机制直接进入老年代，这对虚拟机来说就是安全的。
标记-复制算法在对象存活率较高的时候就要进行较多的复制操作，效率会降低。而且如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

标记-整理算法

标记-整理算法其中的标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都像内存空间一端移动（而标记-复制是复制对象到另一区），然后直接清理掉边界以外的内存。
标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是移动式的。
是否移动存活对象是一个优缺点并存的风险决策：移动则内存回收时会更复杂（需要暂停用户应用程序才能进行，否则会出现同时用户线程有对象新引用情况的出现），不移动则内存分配时会更复杂（内存空间碎片化问题）。从垃圾收集的停顿时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，但从整个程序的吞吐量看，移动对象会更划算。

*本文内容是阅读《深入理解Java虚拟机》第三章的学习笔记。*