jvm垃圾收集器

概述

如果说GC算法是内存回收的方法论，那么垃圾回收器就是内存回收的具体实现。

本文讨论的收集器是基于JDK1.7 Update 14之后的HotSpot虚拟机（在这个版本正式提供了商用的G1收集器），这个虚拟机包含的所有收集器如下图：

上图展示了7种作用于不同分代的垃圾回收器，如果两个垃圾回收器之间存在连线，说明他们可以搭配使用。
本文将逐一介绍这些垃圾回收器的特性，基本原理，使用场景，并重点分析CMS和G1这两款相对比较复杂的收集器。

Serial收集器

看名字就知道，这是个单线程收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一个收集线程去完成垃圾回收工作。更重要的是在他进行垃圾收集时，必须暂停其他所有的工作线程（Stop the world），直到它收集结束。

serial / serial old收集器的运行示意图如下：

注：本文的收集器运行示意图中一个横向的箭头代表一个运行中的线程

serial收集器很老（since JDK1.3），但实际上到目前为止，它依然是虚拟机在Client模式下默认的新生代收集器。

它也有优于其他收集器的地方：简单而高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

ParNew收集器

ParNew其实就是Serial的多线程版本，除了使用多线程进行垃圾收集外，其余行为基本都与Serial相同。事实上这两个收集器也共用了相当多的代码。

ParNew收集器运行示意图如下：

ParNew是Server模式下新生代首选的收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器，目前只有ParNew收集器能与CMS收集器配合工作。CMS是JDK1.5时HotSpot推出的在强交互应用中几乎可认为有划时代的垃圾收集器——CMS收集器（Concurrent Mark Sweep本文稍后介绍）这款收集器是Hotspot虚拟机上第一款真正意义上的并发（Concurrent）收集器。它第一次实现了让垃圾回收线程和用户线程（基本上）同时工作。

注意并行和并发的区别：并行是指多条垃圾线程并行工作，但此时用户线程乃出于等待状态。并发是指用户线程和垃圾收集线程一起执行（但不一定并行，可能交替执行），用户线程继续执行，而垃圾收集线程运行在另一个CPU上。

ParNew收集器在单个CPU环境中绝对不会比Serial有更好的收集效果，甚至由于线程交互的开销，ParNew通过超线程实现的两个CPU下的收集器也不能保证百分百比Serial效果好，当然随着CPU核数的增加，ParNew对GC时系统资源的有效利用还是很有效果的。

Parallel scavenge收集器

Parallel Scavenge是一个新生代收集器，它也是复制算法收集器，又是并行的多线程收集器，看上去和ParNew都一样。但Parallel Scanverge收集器特点和其他收集器的关注点不同，CMS等收集器的关注点是尽可能的缩短垃圾收集时用户停顿时间，而Parallel scanvenge收集器的目的是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总耗时的比值，即：

           吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）

停顿时间越短越适合与用户交互的程序，良好的相应速度能提升用户体验。

而高吞吐量则可以高效率的利用CPU时间，尽快完成程序的运算任务，主要适合后台运算，不需要太多交互的任务。

Parallel scavenge 提供了两个参数用来精准控制吞吐量：

1. -XX:MaxGCPauseMills 控制最大垃圾收集器回收时间
2. -XX GCTimeRatio 直接设置吞吐量大小，0-100整数，例如设置为19，那么吞吐量就是1/(1+19)

parallel scavenge收集器还提供了一个开关参数：-XX:+UseAdaptiveSizePoilicy，当这个参数打开后，就不需要手动指定新生代的大小（-Xmn）、Eden、Surviver的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况手机性能监控信息，动态调控这些参数以提供最合适的最大停顿时间和吞吐率。

由于与吞吐量关系密切，parallel scavenge收集器也经常称为“吞吐量优先”收集器。

Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义是给CLient模式下的虚拟机使用。其运行示意图见上面serial收集器。

Parallel Old收集器

Parallel Old是Parallel scavenge 的老年代版本，使用多线程和“标记-整理”算法。这个收集器用JDK1.6才开始提供，在这之前新生代的Parallel Scavenge只能和Serial Old搭配使用，由于单线程的Serial Old无法使用服务器端多CPU的处理能力，Parallel Scavenge的性能被严重拖累。

直到Parallel Old处理器出现后，Parallel Scavenge终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合。都可以优先考虑Parallel scavenge 加parallel Old组合。其运行示意图如下：

CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收时间为目标的收集器。目前很大部分Java应用在互联网或者B/S系统的服务端上，这类应用尤其注重服务器的相应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常适合这类应用。

CMS收集器是基于“标记-清除”实现的，它的运行过程相对上面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：

1. 初始标记
2. 并发标记
3. 重新标记
4. 并发清除

其中初始标记和重新标记还是需要“Stop the World”。

初始标记仅仅只是标记一下GC Roots能直接关联的到的对象，速度很快。

并发标记阶段就是进行GC Roots Tracing过程。

重新标记阶段则是为了修正并发标记期间因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般比初始阶段长一些，但远比并发标记时间短。

由于整个过程中耗时最长的并发标记和并发清除收集器都可以与用户线程一起工作，所以，从总体上讲CMS的内存回收过程是和用户线程一起并发执行的。运行示意图如下：

CMS 是一款优秀的收集器，它的主要优点是：并发收集、低停顿。所以也称之为低停顿收集器，但是CMS还远达不到完美的程度，它主要有下面3个缺点：

1. CMS收集器对CPU资源非常敏感。其实面向并发设计的程序对CPU资源都比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是由于占用了一部分CPU资源而导致应用程序变慢，总吞吐量变低。
2. CMS收集器无法处理“浮动垃圾”，可能出现“concurrent Mode Failure”而导致Full GC 。由于CMS并发清理阶段，用户线程也在工作，伴随着程序运行自然会有新的垃圾产生，这一部分垃圾出现在标记过程后，CMS无法再当次收集过程中处理掉他们，只好留到下一次GC时再清理，这一部分垃圾就称为“浮动垃圾”。
3. CMS是基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

G1收集器

G1（Garbage-First）收集器是当今收集器技术发展最前沿的成果之一。使用G1收集器时，Java内存分布与其他收集器有很大差别，它把整个Java堆划分为多个大小相等的独立区域（Region）,虽然还保留了新生代和老年代的概念，但新生代和老年代不再物理隔离了，它们都是一部分Region（不连续的）的集合。

这种将O区划分成多块的理念源于：当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。G1跟踪每个Region里面垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要的经验值），在后台维护一个优先队列，每次根据允许的收集时间，优先回收价值最大的Region（这就是Garbage-First的由来）。这种使用Region划分内存空间以及优先级的区域回收方式，保证了G1收集器在有限时间内可以获取尽可能高的收集效率。

G1垃圾收集器的内存划分方式突出的问题：Region不可能是孤立的，一个对象分配在某个Region中，它并非只能被本Region的对象引用，而是可以被整个Java堆的任何对象发生引用关系。那在做可达性判定对象是否存活时，岂不是还得扫描整个Java堆才能保证正确性？

在G1收集器中，虚拟机使用REmembered Set来避免全堆扫描。G1中每个Region都有对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用是否处于不同的Region中（在分代的例子中就是检查是否老年代的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被应用对象所属的Region的Remembered Set之中。当进行内存回收时，在Gc根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

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

• 初始标记 ： 仅仅只标记GC ROOTs能直接关联到的对象，这个阶段需要停顿线程，但是耗时很短。
• 并发标记 ： 从GC ROOTs 开始对堆中对象进行可达性分析，耗时长，但与用户线程并发执行。
• 最终标记 ： 修改并发标记阶段，因用户线程继续运行而导致标记产生变化的那一部分标记记录，虚拟机将标记变化记录到Remembered Set Logs里面，需要在这个阶段合并带Remembered Set中，停顿线程，并发执行。
• 筛选回收 ： 首先根据各个Region的可回收价值和回收时间进行排序，根据用户希望的停顿时间来指定回收计划。

 G1 与Ps/Ps old相比，最大的好处是停顿时间更可控、可预测。如果你的应用追求低停顿，那么G1已经可以作为一个可尝试的选择，如果你的应用追求吞吐量，那么目前G1并不会为你带来特别的好处。