《深入理解Java虚拟机》垃圾收集器

 

说起垃圾收集（Garbage Collection，GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史远比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当List还在胚胎时期时，人们就在思考GC需要完成的3件事情：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

虽然目前动态分配与内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，但只有了其内在，才能让我们写好每一句代码。接下来就以上这三个问题逐一揭晓。

 

哪些内存需要回收？

 

从JVM区域结构看，可将这些区域划分为“静态内存”和“动态内存”两类。程序计数器、虚拟机栈、本地方法3个区域是“静态”的，因为这几个区域的内存分配和回收都具备确定性，都随着线程而生，随着线程而灭。但Java堆和方法区不一样，内存分配都存在不确定性，只有在程序处于运行期间才能知道会创建哪些对象，这部分内存和回收都是动态的，垃圾收集器所关注的是这部分内存。

 

“静态”区域的内存分配和回收已经很明确了，但“动态”区域到底是如何确定哪些内存该回收，哪些内存不该回收呢？我们都知道，Java是一种面向对象语言，在“动态”内存区域堆中的内存分配都是以“对象”为单位存在（方法区后面再说）。如果要回收，肯定是回收哪些没有用的对象了，那么又怎么确定对象已经没用呢？

 

判断方法1：引用计数法

 

分配对象时给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是没有再被使用了。客观地说，引用计数法（Reference Counting）的实现简单，判断效率也很高，但是在主流的Java虚拟机里面没有选用引用计数法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。例如：

public class ReferenceCountingGC {

    public Object instance = null;
    private byte[] bigsize = new byte[2*1024*1024];
    
    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        
        objA.instance = objB;
        objB.instance = objA;
        
        objA = null;
        objB = null;
        
        System.gc();
    }
}

 

判断方法2：可达性分析算法

 

可达性分析（Reachability Analysis）的基本思想是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时（也就是GC Roots到这个对象不可达），则证明此对象是不可用的。如下图所示：

对象Object5、Object6、Object7相互虽然有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。在Java语言中，可作为GC Roots的对象包括下面几种：

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

 

无论是引用计数法还是可达性分析算法，都用到了引用的概念，从JDK1.2开始，Java对引用的概念进行了扩充，讲引用分为强引用（Strong Reference）、软引用（Softe Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，增强引用的适用性。

• 强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只有强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用也是用来描述一些有用但并非必要的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用也是用来描述非必要对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。但垃圾收集工作时，无论当前内存是否足够，都会回收掉只内弱引用关联的对象。
• 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。因为finalize函数（后续会讲）被调用的不确定性，所以无法预知对象是否被回收，所在这里虚引用就起作用了。

 

即使在可达性分析算法中不可达的对象，也并非“非死不可”的，这个时候它们暂时处于缓刑阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。第一次是在可达性分析后发现没有与GC Roots相连接的引用链并同时进行一次筛选，如果筛选出此对象没有必要执行finalize方法（当前对象没有覆盖finalize方法或此方法已经被执行过了，注意：finalize方法在整个对象生命周期只会被调用一次而已）。没有必要执行finalize方法的对象确认已经死亡。如果有必要执行finalize方法的对象则会将此对象放入一个叫做F-Queue的队列之中，并稍后有一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这也是对象最后的自救时刻，它可在finalize方法把自己（this）赋值给某个类变量或者对象的成员变量来自救不在这次垃圾回收掉。但在“虚引用”中已经提到，这个finalize方法的调用存在不确定性。因为虚拟机不承诺会等待整个F-Queue执行完，因为不排除有部分finalize方法存在死循环等极端情况造成F-Queue永远等待。所以说，finalize()方法是对象逃脱死亡的最后一个机会，但不一定被调用且在整个生命周期只会被调用一次，稍后GC将对F-Queue中的对象进行第二次小规模标记。如果没有成功逃脱，那这个对象真的会被回收了。

 

方法区收回

 

方法区（或者说HotSpot虚拟机中的永久代）的垃圾收集主要回收两部分内容：废弃的常量和无用的类。但永久代的回收效率远没有堆的回收效率高。判断一个常量是否“废弃常量”跟堆中判断对象非常相似，而要判断一个类是否是“无用的类”的条件相抵苛刻：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

但是需要注意，就算满足以上三种条件也未必一定会回收。可能永久代的效果不理想，在JDK8中，已经没有永久代的概念了，原先这块区域被放置到本地内存了。

 

什么时候回收？

 

上一节讲到了哪些对象需要被回收，那么这一节主要讲解的是这些对象什么时候被回收？在主流的语言中（如Java）使用的使用的都是可达性分析算法来判断对象的存活。而可达性分析算法是根据GC Roots的向下关联性来寻找没有被关联的对象。如果逐个区域检查是非常耗时的，目前比较主流的Java虚拟机（例如HotSpot）使用的都是准确式GC。HotSpot使用一种称为OopMap的数据结构来记录某个时刻栈和寄存器的哪些具体的地址是引用地址，从而可以快速找到GC roots来进行对象的标记操作。这里所说的“某个时刻”就是大名鼎鼎的Stop The World。虚拟机为了分析GC Roots这项工作必须在一个能确保一致性的快照中进行，这里的“一致性”的意思就是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上——这叫安全点。当然，程序执行时并非在所有地方都能停顿下来开始GC，只有到达安全点时才能暂停。安全点选址也有规定的，选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的。这里的长时间执行的最明显特征是指令列复用，例如方法调用、循环跳转、异常跳转等。

 

虚拟机为了能让所有线程都“跑”到安全点上停顿下来，设计了两个方案：抢先式中断和主动式中断。其中抢先式中断是虚拟机发生GC时，首先把所有线程全部中断，如果发生有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。这种方式现在比较用了。而主动式中断是虚拟机需要GC时仅仅简单的设置一个标志，各个线程执行到安全点时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。

 

安全点机制只保证了执行时的程序可以收到“通知”，但对于“不执行”的程序（如等待CPU时间的程序）如何是好？例如线程处于Sleep状态或者Blocked状态，这时线程无法响应JVM的中断强求。对于这种情况，JVM使用了安全区域（Safe Region）来解决。安全区域是指一段代码片段之中，引用关系不会发生变化的，在这个区域中任意地方开始GC都是安全的。例如线程执行到安全区域中的代码时，首先标识自己已经进入了安全区域。那么JVM发起GC时，就不用管那些已经被标自己为Safe Region状态的线程了。当这些线程要离开安全区域时，它同时要检查系统是否已经完成了根节点枚举（或者是整个GC过程）才能继续执行，否则必须等待收到可以安全离开安全区域的信号为止。

 

如何回收？

 

垃圾收集器是回收以上描述无用对象的具体实现，而垃圾收集算法又是垃圾收集器的方法论。所以，在介绍垃圾收集器之前，先了解一下这些垃圾收集算法，有助于理解后续的垃圾收集器的实现。

 

标记-清除（Mark-Sweep）算法

 

这是最基础的算法，就像它名字一样，算法分为“标记”和“清除”两个阶段：首先标记处所有需要回收的对象（如哪些内存需要回收所描述的对象），对标记完成后统一回收所有被标记的对象，如下图所示：

缺点：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除后悔产生大量的不连续的内存碎片，可能会导致后续无法分配大对象而导致再一次触发垃圾收集动作。

 

 

复制算法

 

为了针对标记-清除算法的不足，复制算法将可用内存容量划分为大小相等的两块，每次只使用一块。当一块的内存用完了，就将还存活的对象复制到另一块上面去。然后把已使用过的内存空间一次清理掉，如下图所示：

缺点：使用内存比原来缩小了一半。

现在的商业虚拟机都采用这种收集算法来回收新生代，有企业分析的得出其实并不需求将内存按1:1的比例划分，因为新生代中的对象大部分都是“朝生夕死”的。所以，HotSpot虚拟机默认的Eden和Survivor的大小比例是8:1。一块Eden和两块Survivor，每次使用一块Eden和一块Survivor，也就是说只有10%是浪费的。如果另一块Survivor都无法存放上次垃圾回收的对象时，那这些对象将通过“担保机制”进入老年代了。

 

 

标记-整理（Mark-Compact）算法

 

复制算法一般是对对象存活率较低的一种回收操作，但对于对象存活率较高的内存区域（老年代）来说，效果就不是那么理想了，标记-整理算法因此诞生了。标记-整理算法和标记-清除算法差不多，都是一开始对回收对象进行标记，但后续不是直接对对象清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，如下图所示：

 

 

分代收集算法

 

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法只是根据对象存活周期的不同将内存划分为几块，一般把Java堆分为新生代和来年代，这样就可以根据各个年代的特点采用最适当的收集算法。

 

 

上面已经介绍完了垃圾收集的算法，接下来就开始介绍实现这些算法的一下垃圾收集器了：

 

Serial收器

 

Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器，当它工作时必须暂停其他线程的工作，也就是Stop The World。这显示是它的缺点， 这也是垃圾收集器一直努力的方向。当然，对于相比其它单线程收集器，Serial收集器简单而高效。对于桌面应用来说，分配的管理内存不会太多，停顿时间完全可以控制在几十毫秒最多一百毫秒以内。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。下图为Serial结合Serial Old收集器（后续介绍）的运行过程：

 

 

ParNew收集器

 

ParNew收集器其实就是Serial收集器的多线程版本（多CPU下使用效果较好），下图为ParNew结合Serial Old收集器（后续介绍）的运行过程：

ParNew收集器对于Serial来说并没有太多的创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial收集器外，剩下只有它能与CMS收集器（后续介绍）配合工作了。所以，遗憾的是CMS作为老年代的收集器，却无法与JDK1.4中已经存在的新生代收集器Parallel Scavenge配合工作。

 

Parallel Scavenge收集器

 

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去跟ParNew差不多。但是Parallel Scavenge收集器与其他收集器不同在于CMS等收集器的关注点在于尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓的吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花费1分钟，那吞吐量就是99%。

 

Parallel Scavenge收集器分别可通过-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间以及直接设置吞吐量大小的-XX:GCTimeRatio参数。Parallel Scavenge收集器还有一个-XX:UseAdaptiveSizePolicy开关参数，打开参数后就不需要手动指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整相关参数。这种调节方式叫自适应的调节策略，也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

 

 

Serial Old收集器

 

Serial Old是一个老年代收集器，它同样是一个单线程收集器，使用的是“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；另一种用途就是作为CMS收集器的后备方案，在并发收集发生ConCurrent Mode Failure时使用。

 

 

Parallel Old收集器

 

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是新生代如果选择了Parallel Scavenge收集器，老年代除了Serial Old收集器别无选择（因为它无法与CMS配合使用）。在都CPU时代，由于Serial Old收集器在服务端性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。直到Parallel Old收集器的出现后，“吞吐量优先”收集器才有了比较名副其实的应用组合。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器，如下图所示：

 

 

CMS收集器

 

CMS（Concurrent Mark Sweep）收集器是一种以获得最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。从名字上就可以看出，CMS收集器是基于“标记-清除”算法实现的。但它的实际运作过程对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是进行GC Roots Tracing的过程；而重新标记阶段则是为了修正并发标记期间用用户程序继续运作而导致标记产生的那一部分对象的标记记录。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短。由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的（注意并发与并行的概念），如下图所示：

CMS是一款优秀的收集器，但是还远达不到的完美程度，它有以下3个明显缺点：

• CMS收集器对CPU资源非常敏感。因为在并发阶段，它会占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
• CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理它们，只好留待在下一次GC时再清理掉，这一部分垃圾就称为“浮动垃圾”。
• 还有最后一点，CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量的空间碎片产生。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullColletion开关参数（默认是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片合并整理过程，内存整理的过程是无法并发的，空间的碎片问题没有了，但停顿的时间不得不变长了。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。

 

 

G1收集器

 

G1（Garbage First）收集器是当今收集器技术发展的最前沿成果之一，从JDK 6u14中开始就有Early Acsess版本的G1收集器供开发人员实验、试用，由此开始G1收集器的 “Experimental” 状态持续了数年时间，直到JDK7u4，Sun公司才认为它达到足够成熟的商用程度，移除了“Experimental”的标识。G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。其与其它收集器相比，G1具备如下特点：

• 并行与并发：和CMS类似。
• 分代收集：分代概念在G1中依然得以保留。虽然G1可以不需要其它收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。也就是说G1可以自己管理新生代和老年代了。
• 空间整合：由于G1使用了独立区域（Region）概念，G1从整体来看是基于“标记-整理”算法实现收集，从局部（两个Region）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片。
• 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用这明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

 

与其它收集器相比，G1变化较大的是它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留了新生代和来年代的概念，但新生代和老年代不再是物理隔离的了它们都是一部分Region（不需要连续）的集合。同时，为了避免全堆扫描，G1使用了Remembered Set来管理相关的对象引用信息。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏了。

 

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

• 初始标记（Initial Making）
• 并发标记（Concurrent Marking）
• 最终标记（Final Marking）
• 筛选回收（Live Data Counting and Evacuation）

看上去跟CMS收集器的运作过程有几分相似，不过确实也这样。初始阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以用的Region中创建新对象，这个阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，这一阶段耗时较长但能与用户线程并发运行。而最终标记阶段需要吧Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这一过程同样是需要停顿线程的，但Sun公司透露这个阶段其实也可以做到并发，但考虑到停顿线程将大幅度提高收集效率，所以选择停顿。下图为G1收集器运行示意图：