Java虚拟机(五)——垃圾收集机制

垃圾回收介绍

   Java虚拟机内存划分讲到了Java 内存运行时区域的各个部分，其中程序计数器，虚拟机栈，本地方法栈三个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来是就已知了。因此这几个区域的内存分配和回收都具有确定性，在这几个区域就需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java 堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的。而垃圾收集器所关注的是这部分内存。

垃圾对象的判定方法

  在堆里存放着Java中几乎所有的对象实例，在进行垃圾回收之前，首先要确定哪些对象应该被回收。

引用计数算法

引用计数法是大家所熟知的一种方法。

算法过程如下：

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减一；任何时候计数器为0的对象就是不可能再被使用的。

这种方法特点就是，实现简单，判定效率也很高，大部分情况下都是一个不错的选择。但是很多主流的Java虚拟机没有选择使用引用计数法类管理内存，主要原因它很难解决对象之间相互循环引用的问题。

public class MyObject {
    public Object ref = null;
    public static void main(String[] args) {
        MyObject myObject1 = new MyObject();
        MyObject myObject2 = new MyObject();
        myObject1.ref = myObject2;
        myObject2.ref = myObject1;
        myObject1 = null;
        myObject2 = null;
    }
}

循环引用导致myObject1和myObject2两个被引用次数均为2， 即使当两个对象都被置为null后，引用次数仍然为1，导致两个对象无法被回收。

可达性分析算法

在主流的商用程序语言（例如Java，C#）的主流实现中，都是通过可达性分析来判定对象是否存活的。

算法过程如下：

   这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链。当一个对象到GC roots没有任何引用链相连时，则证明此对象是不可用的。如下图所示，对象object5,object6,object7虽然互相有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

Java 中，可作为GC Roots的对象包括下面几种：

1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
2. 方法区中类静态属性引用的对象。
3. 方法区中常量引用的对象。
4. 本地方法栈中JNI(即一般说的Native方法)引用的对象。

   即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”,要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为”没有必要执行“。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个虚拟机自动建立的，低优先级的Finalizer线程中去执行它。这里所谓的”执行”是指虚拟机会触发这个方法，但并不会保证会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环(极端情况)，将很可能导致F-Queue队列中其他对象处于永久等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize(）中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出”即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。

垃圾收集算法

   实际上垃圾收集算法的实现涉及到大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此我们只讨论几种算法的基本思想。常见的垃圾收集算法主要涉及到这几种，标记——清除算法，复制算法，标记整理算法，分代收集算法等，下面一一作为介绍。

标记——清除算法

   这是一种最基础的收集算法（Mark-Sweep）。分为标记-清除两个阶段。

标记阶段：先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，它的标记过程其实就是上述的可达性分析算法中的标记过程。它是最基础的算法，后续的收集算法都是基于这种思路并对其不足进行改进而得到的。

不足之处主要有两个：
1.效率问题，标记和清除两个过程效率都不高。
2.空间问题，标记清除之后会产生大量不连续的碎片，可能会导致后续程序需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。其执行过程如下图所示：

复制算法

   在上述标记——清除算法的基础上，为了解决效率问题，复制算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动对顶指针，按顺序分配内存即可，实现简单，运行高效。

缺点就是，将内存缩小为原来的一半，代价较高；当对象存活率较高时就要进行较多的复制操作，效率将会变低。

应用场景：应用于当今主流商业虚拟机新生代收集算法，所不同的是，实际的新生代收集算法，并不是将内存简单划分为等分的两半，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次只使用Eden和其中的一块Survivor。关于堆区和新生代等的具体内容可以参考 这篇《Java虚拟机(二)——堆内存划分》。

标记——整理算法

   复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以老年代一般不能直接选用这种算法。

标记-整理算法（Mark-Compact）的标记过程与”标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存货的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

   分代收集算法是当前商业虚拟机的垃圾收集机制都采用的算法。 分代收集算法并不是一种新的算法模型，它只是一种根据对象存活周期的不同特点而对不同收集算法的综合运用。具体来说就是对堆区所采用的垃圾收集方案。堆区分为新生代和老年代，新生代的特点就是，每次垃圾收集都会发现大批对象死去，只有少量存活，那么采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集，这就是所谓的Minor GC 。老年代的特点就是对象存活率高，没有额外空间的对它进行分配担保，那么就必须使用 “标记-清除”或者”标记-整理”算法。

常见垃圾收集器实现

   垃圾收集器是内存回收的具体实现。当然Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，实际上到目前为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。

Serial 收集器

  它是最基本，发展历史最悠久的收集器，曾经是虚拟机新生代收集的唯一选择。特点就是，它是一个“单线程”的收集器，所谓“单线程”是指它不仅仅只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是，在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。这显然是很让人难以接受的，但是现代虚拟机不断优化，不断缩减停顿时间，将停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，那么只要不是频繁发生，这点停顿完全可以接受。针对运行在Client模式下的虚拟机来说，例如用户的桌面应用场景，分配给虚拟机管理的内存一般来说不会太大，收集几十兆甚至一两百兆的新生代，Serial收集器完全够用。其主要优点在于，没有线程交互开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

parNew收集器

   parNew是Serial的多线程版本，其核心就是就是运用多个线程进行垃圾收集。但是在单CPU的环境下绝对不会比Serial收集器有更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不可能百分之百地保证可以超越Serial收集器。但当可用CPU数量增多时，能够更加高效的利用系统资源。
parNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中一个原因就是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

Parallel Scavenge收集器

  Parallel Scavenge收集器它是一个新生代收集器。其特别之处在于，其他收集器的关注点都是尽可能地缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge收集器的目标则是达到一个控制的吞吐量。吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，假设虚拟机运行100分钟，垃圾收集花费1分钟，那么吞吐量就是99%。Parallel Scavenge收集器提供了很多可精确设置的细节参数，可以精确控制最大垃圾收集停顿时间还有吞吐量的大小，特别的，当自适应参数打开后，就不需要手动去指定新生代的大小等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或或者最大的吞吐量，这种方式就是所谓的GC 自适应调节策略。

自适应策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

Serial Old收集器

   Serial Old收集器是Serial收集器的老年代版本，同样是单线程的，使用“标记-整理算法”。这个收集器主要意义也是在于给Client模式下的虚拟机使用。

Parallel Old收集器

   Parallel Old收集器是 Parallel Scavenge的老年代版本，使用多线程和“标记-整理”算法。JDK 1.6 之后才开始提供了这个收集器。
在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old 收集器。

CMS收集器

   CMS（Concurrent Mark Sweep）收集器是基于“标记-清除”算法实现的，它使用多线程的算法去扫描堆（标记）并对发现的未使用的对象进行回收（清除）。整个过程分为6个步骤，包括：

初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
并发预清理（CMS-concurrent-preclean）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
并发重置（CMS-concurrent-reset）

   其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。其他动作都是并发的。

   需要注意的是，CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数以获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高将会很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。

   还有一个缺点，CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费附送一个碎片整理过程，内存整理的过程是无法并发的。空间碎片问题没有了，但停顿时间不得不变长了。虚拟机设计者们还提供了另外一个参数-XX: CMSFullGCsBeforeCompaction，这个参数用于设置在执行多少次不压缩的Full GC后，跟着来一次带压缩的。

   该算法与并行收集器的另一个缺点是吞吐量的它使用更多的 CPU，为了使应用程序提供更好的体验，通过使用多个线程来执行扫描和收集。这种情况长时间的运行会使应用程序停顿下来，可以使用提高空间来换取高效的运行。但是，这种算法的使用不是默认的。您必须指定 XX： + USeParNewGC来使用它。如果你可以提供更多的CPU资源的话以避免应用程序暂停，那么你可以使用CMS收集器。假设你的堆的大小小于 4 Gb你必须分配大于 4 GB的资源。

G1收集器

   G1垃圾收集器在JDK7 update 4之后对大于4G的堆有了更好的支持，G1是一个针对多处理器大容量内存的服务器端的垃圾收集器，其目标是在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。G1在执行一些Java堆空间中的全区域操作（如：全局标记）时是和应用程序线程并发进行的，因此减少了Java堆空间的中断比例。（译者注：可简单理解为减少了Stop-the-World的时间比例）。

   它与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片，这对于长时间运行的应用系统来说非常重要。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，具备了一些实时Java（RTSJ）的垃圾收集器的特征。

   首先将Java堆空间划分为一些大小相等的区域（region），每个区域都是虚拟机中的一段连续内存空间。G1通过执行并发的全局标记来确定整个Java堆空间中存活的对象。标记阶段完成后，G1就知道哪些区域基本上是空闲的。在回收内存时优先回收这些区域，这样通常都会回收相当数量的内存。这就是为什么它叫做Garbage-First的原因。顾名思义G1关注某些区域的回收和整理，这些区域中的对象很有可能被完全回收。而且G1使用了一个暂停时间预测模型使得暂停时间控制在用户指定的暂停时间内，并根据用户指定的暂停时间来选择合适的区域回收内存。

   G1确定了可回收的区域后就是筛选回收（evacuation）阶段了。在此阶段将对象从一个或多个区域复制到单一区域，同时整理和释放内存。该阶段是在多个处理器上多个线程并行进行的，因此减少了暂停时间并提高了吞吐量。G1在每一次的垃圾收集过程中都不断地减少碎片，并能够将暂停时间控制在一定范围内。这些已经是以前的垃圾收集器无法完成的了。比如：CMS收集器并不做内存整理。ParallelOld收集器只是对整个Java堆空间做整理，这样导致相当长的暂停时间。