Java中的垃圾收集器

1. Serial收集器

Serial收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

Serial收集器到现在为止，它依然是JAVA虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

2. ParNer收集器

ParNew收集器是Java虚拟机中垃圾收集器的一种。它是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器一致）

ParNew是许多运行在Server模式下的虚拟机中首选的新生代收集器，在JDK1.6以及之前的版本中，除了Serial收集器外，只有它能与CMS收集器配合工作。

3. Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代回收器，它是使用复制算法的收集器。

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器关注点是尽可能的缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则使达到一个可控值的吞吐量。所谓吞吐量就是CPU运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

Parallel Scanvenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集器停顿时间的 -XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的 -XX:GCTimeRatio。

MaxGCPauseMills参数允许的值时一个大于0的毫秒数，收集器尽可能地保证内存回收花费的时间不超过设定值。GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB的时间肯定比收集500MB的时间快，这也导致垃圾收集发生得更频繁一些，原来10秒收集一次，每次停顿100毫秒，现在变成5秒停顿一次，每次停顿70毫秒。停顿的时间的确在下降，但吞吐量也下降了。

GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。如果把参数设置为19，那允许的最大GC时间就占总时间的5%（即1/(1+19)），默认值为99，就是最大允许1%的垃圾收集时间。

Parallel Scavenge收集器还有一个参数-XX:UseAdaptiveSizePolicy。这个一个开关参数，当这个参数打开以后，就不需要手工指定新生代的小小（-Xmn）、Eden区与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代的大小（-XX:PretenureSSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态的调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

4. Serial Old收集器

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

5. Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代Parallel Scavenge收集器一直处于比较尴尬的状态。原因是新生代选择了Parallel Scavenge收集器，那么老年代除了选择Serial Old收集器之外别无选择。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得较大吞吐量的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力。在老年代很大且硬件比较高的环境中，这种组合的吞吐量还不一定有ParNew加CMS的组合大。

知道Parallel Old收集器出现后，”吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenage加Parallel Old收集器。

6. CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它是一个多线程收集器，采用“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些。整过程分为以下4个步骤：

1) 初始标记（CMS inital mark）2) 并发标记（CMS concurrent mark）3) 重新标记（CMS remark）4) 并发清除（CMS concurrent sweep）

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

CMS是一款优秀的收集器，但还是有以下3个明显的缺点

1) CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一些资源而导致应用程序变慢，总吞吐量降低。2) CMS收集器无法处理浮动垃圾，可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法再档次收集过程中处理掉它们。只好留待下一次GC时再清除掉。3) CMS是一款基于"标记-清理"算法实现的收集器。当收集结束后会有大量的空间碎片产生，空间碎片过多时，将会给大对象分配带来麻烦，旺旺老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

7. G1收集器

G1是一款面向服务端应用的垃圾收集器。与其他收集器相比，G1具备以下特点：

1) 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势、使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行GC动作，G1收集器仍然可以通过并发地方式让Java程序继续执行。2) 分代收集：与其他收集器一样，分代概念在G1中依然保留。谁然G1可以不需要其他收集器独立整理整个GC对，但它能够采用不同的方式来处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更高的收集效果。3) 空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运行期间不会产生内存空间随便，收集后能提供规整的可用内存。这种特征有利于程序长时间运行，分配大对象不会因为无法找到练习内存空间而提前触发下一次GC。4) 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。

在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不在是这样，使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代已经不再是物理隔离的了，它们都是Region（不需要连续的集合）。

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

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

• 初始标记
• 并发标记
• 最终标记
• 筛选回收