现在的大部分虚拟机都遵循了“分代收集”的理论进行设计，主要是建立在两个假说之上：

• 弱分代假说：绝大多数对象都是朝生夕灭的。
• 强分代假说：熬过越多次垃圾收集过程的对象就难以消亡。

这两个假说奠定了我们垃圾收集器的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（熬过垃圾收集过程的次数）分配到不同的区域之中存储。也正是因为有了如此划分之后，我们才有针对某个区域进行回收的回收类型和回收算法的设计。

分代收集划分

我们的在将分代收集理论具体运用到虚拟机之后，设计者一般考虑将Java堆划分为了新生代和老年代两个区域。顾名思义，在新生代中，每次垃圾收集时都发现有大批对象死去，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。

我们在划分区域之后就可以针对不同的区域使用不同的收集类型，但是我们假设如果进行一次新生代区域的收集，但新生代的对象却是完全有可能被老年代所引用！所以需要为了可达性分析结果的正确性，来遍历一次老年代。但是老年代划分的区域都是比较庞大的，所以这显然会给我们的内存回收带来很大的性能负担。

所以，针对这个问题，对分代收集理论提出了第三条的经验法则：

跨代引用假说：跨代引用相对于同代引用来说仅占极少数。所以存在互相引用的两个对象，应该是同时消亡或者同时生存的。比如我们老年代的对象存活周期长，于是我们在新生代中的引用也难以消亡，在熬过多次收集之后，这个新生代的对象就晋升到了老年代，这个时候跨代引用也就消除了。

针对这个假说，我们设计一个全局的数据结构——记忆集。这个结构把老年代划分成若干个小块，标识出老年代的哪一块内存会存在跨代引用。此时如果发生了新生代的收集的时候，我们就不必要对整个老年代进行扫描，而是针对只有包含了跨代引用的小块内存里的对象才会被加入到GCRoots进行扫描，可达性分析。这比起之前直接扫描整个老年代来查看谁引用了显然划算的多！

针对分代收集，我们有以下这些专属名词：

部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，又分为了：

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

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

常见GC算法

标记-清除算法

最早出现的垃圾收集算法，算法顾名思义，分为了“标记”和“清除”两个阶段。首先首先从每个 GC Roots 出发依次标记有引用关系的对象，最后清除没有标记的对象。也可以反过来，标记没有引用关系的对象，最后清除有标记的对象。

缺点：

• 执行效率不稳定，如果堆包含大量对象且大部分需要回收，必须进行大量标记清除，导致效率随对象数量增长而降低。
• 存在内存空间碎片化问题，会产生大量不连续的内存碎片，导致以后需要分配大对象时因为内存不足而容易触发 Full GC。

标记-复制算法

为了解决内存碎片化的问题，我们于是提出了标记-复制算法。我们将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当使用的这块空间用完了，就将存活对象复制到另一块，再把已使用过的内存空间一次清理掉。主要用于进行新生代。虽然增加了复制的开销，但是因为大部分对象都是可回收的，所以还是可以接受的。

缺点：因为只使用一半空间，所以空间利用率不高。

不过我们的HotSpot虚拟机通过这种策略设计了新生代的内存布局，将新生代的内存分成了一个Eden区和两个Survivor区来比配这种标记-复制算法。每次分配内存只使用 Eden 和其中一块 Survivor。垃圾收集时将 Eden 和 Survivor 中仍然存活的对象一次性复制到另一块 Survivor 上，然后直接清理掉 Eden 和已用过的那块 Survivor。HotSpot 默认Eden 和 Survivor 的大小比例是 8:1，即每次新生代中可用空间为整个新生代的 90%。更具体的解释可以参考这一篇博文，点击跳转

标记-整理算法

标记-复制算法在对象存活率较高时就要进行较多的复制操作，效率将会降低。如果不想浪费我们不使用的那段空间，就需要有额外空间分配担保，应对被使用内存中所有对象都存活的极端情况，所以老年代一般不使用此算法。

所以针对老年代的特性，我们提出了标记-整理算法。我们首先会让所有存活的对象都向内存空间一段移动，然后然后清理掉边界以外的内存。

标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是移动式的。但是如果移动对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行 。但是不移动的话，弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。

所以说，无论是使用标记-清除还是标记-整理对老年代来说都是有弊端的。但是综合起来，从整个程序的吞吐量来看，移动对象会更划算。（HotSpot虚拟机里面关注吞吐量的ParallelScavenge收集器是基于标记-整理算法的，而关注延迟的CMS收集器则是基于标记-清除算法的，也是基于这两种弊端设计的。）

不过，我们还有一种混合使用方式，做法是让虚拟机平时多数时间都采用标记-清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记-整理算法收集一次，以获得规整的内存空间。前面提到的基于标记-清除算法的CMS收集器面临空间碎片过多时采用的就是这种处理办法。

参考资料

深入理解Java虚拟机（第三版）