JVM：常见的垃圾回收算法

常见的垃圾回收算法

分代收集理论

当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”（Generational Collection）[1]的理论进行设计，分代收集名为理论，实质是一套符合大多数程序运行实际情况的经验法则。

1）经验法则1：绝大多数对象都是朝生夕灭的。

2）经验法则2 ：熬过越多次垃圾收集过程的对象就越难以消亡。

实际上，这两个经验法则共同奠定了多款常用的垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储

这个设计原则带来的回报：如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，那么把它们集中放在一起，每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象，就能以较低代价回收到大量的空间；如果剩下的都是难以消亡的对象，那把它们集中放在一块， 虚拟机便可以使用较低的频率来回收这个区域，这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。

所以在Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或者某些部分的区域。（Minor GC”“Major GC”“Full GC）

然而分代收集并非只是简单划分一下内存区域那么容易，它至少存在一个明显的困难：对象不是孤立的，对象之间会存在跨代引用。

假如要现在进行一次只局限于新生代区域内的收集（Minor GC），但新生代中的对象是完全有可能被老年代所引用的，为了找出该区域中的存活对象，不得不在固定的GC Roots之外，再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性，反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行，但无疑会为内存回收带来很大的性能负担

3）经验法则3：跨代引用相对于同代引用来说仅占极少数。

依据这条经验法则，我们就不应再为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用，只需在新生代上建立一个全局的数据结构（记忆集，这个东西在理解垃圾收集的原理比较重要，后面统一说）。

标记-清除算法

如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象

缺点：

1. 执行效率不稳定

   如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低

2. 内存空间的碎片化问题

   标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

标记-复制算法

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

缺点：

1. 如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销
2. 会浪费一半的存储空间。

Java虚拟机中，大多都优先采用了这种收集算法去回收新生代。然后，并没有如算法说的直接就浪费了年轻代50% 的内存空间。

背景：IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此并不需要按照1∶1的比例来划分新生代的内存空间。 

意味着什么？意味着会有2%的存活对象的复制开销，同时也不需要预留50%的空间，理论上只需要预留浪费年轻代的2%空间即可。

针对具备“朝生夕灭”特点的对象，他们提出了一种更优化的半区复制分代策略（8：1：1）（也即每次新生代中可用内存空间为整个新
生代容量的90%，0%的新生代是会被“浪费”的）

标记-整理算法

其标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存，标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是移动

式的。

这两个算法的本质差异非常重要，是否移动回收后的存活对象是一项优缺点并存的。如何理解呢？

很多人在刷面试题时就理解到这里了，我觉得这还不够，还要思考这意味着什么？

• 如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须stop the world的。你可以预想一下在垃圾收集器移动对象和用户业务线程并发的场景。

• 那不移动对象的话，又会存在内存空间碎片化问题，这时就内存分配时会更复杂，需要内存分配器和内存访问器来解决

  （可以简单理解为，在分配新对象内存时，由于空间碎片，在申请一些连续大内存时内存不够，就需要做一些额外的工作，比如出发stw 整理空间或者通过分区空闲分配链表（通过一个额外的数据结构把碎片化的内存空间连起来，我理解有点像虚拟文件系统。））
  

而内存的访问是用户程序最频繁的操作，甚至都没有之一，假如在这个环节上增加了额外的负担，势必会直接影响应用程序的吞吐量。

基于以上两点，是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更复杂。

通过上面的分析，结论就是：不移动对象停顿时间会更短，甚至可以不需要停顿（追求低停顿），但是从整个程序的吞吐量来看，移动对象会更划算（追求吞吐量）。所有在追求低停顿（比如关注延迟的CMS收集器则是基于标记-清除算法）还是追求吞吐量（关注吞吐量的Parallel Scavenge收集器是基于标记-整理算法）的垃圾收集器时，基本原理就是按照上面的分析去选择算法的。