JVM各种垃圾收集器的简介

原 作者 李猛 | 发表于 | 分类于 2016级

本以为JVM中有一个强大的垃圾收集器，能够实时监控资源并即时清除已经死掉的对象。事实上直到现在为止还没有万能的收集器，我们选择的只是对具体应用最合适的收集器，下面就简单说说集中收集器吧。

Serial 收集器

最基本、发展历史最悠久的收集器，在JDK 1.3.1之前是虚拟机新生代收集的唯一选择。它是一个单线程收集器，在它就行垃圾收集工作时，必须暂停其他所有的线程，直到它收集结束。

具有简单高效的优点（没有线程交互的开销），现在依然是虚拟机运行在Client模式下的默认新生代收集器。

ParNew 收集器

Serial收集器的多线程版本，除了多线程收集之外，与Serial相比并没有太多创新。除了Serial收集器外，目前只有ParNew收集器能与CMS收集器配合工作，是运行在Server模式下虚拟机中首选的新生代收集器。

在单CPU的环境下，ParNew收集器不会比Serial收集器有更好的效果，但是随着CPU数量的增加，对GC时系统资源的有效利用还是有很多好处的。

Parallel Scavenge 收集器

使用复制算法的新生代收集器，它的目标是达到一个可控制的吞吐量（Throughput），吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。

高吞吐量可以高效地利用CPU时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务；停顿时间短适合需要与用户交互的程序，能够提升用户体验。

-XX:MaxGCPauseMillis参数可以用来控制最大垃圾收集时间，允许设置一个大于0的毫秒数，不要以为将其设置小一点就能使垃圾收集的速度变快，GC停顿时间的缩短是以牺牲吞吐量和新生代空间来换取的，值调小使停顿时间下降的同时吞吐量也下降了。

-XX:GCTimeRatio参数的值应该是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数，默认值是99，就是允许最大1%（即1 / (1 + 99)）的垃圾收集时间。

-XX:+UseAdaptiveSizePolicy，是一个开关参数，打开后虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间和最大的吞吐量，这种调节方式称为GC自适应调节策略。

Serial Old 收集器

Serial收集器的老年代版本，是一个使用“标记-整理”算法的点线程收集器。主要给Client模式下的虚拟机使用；但是在Server模式下，有两个用途:

  1. 在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用。
  2. 作为CMS收集器的后背预案，在并发收集发生Concurrent Mode Failure 时使用。

Parallel Old 收集器

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

CMS 收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，适用于注重服务的响应速度的应用。

收集过程：

  1. 初始标记：需要中断用户线程，标记一下GC Roots能直接关联到的对象，速度很快。
  2. 并发标记：不需要中断用户线程，进行GC Roots Tracing。
  3. 重新标记：需要中断用户线程，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
  4. 并发清除：不需要中断用户线程，采用“标记-清除”法清除被标记过的记录。

优点：并发收集、低停顿。

缺点：

  1. 对CPU资源十分敏感。在并发阶段，收集线程会占用一部分CPU资源而导致应用程序变慢，总吞吐量降低。CMS默认启动的回收线程数是(CPU数量+3)/4，当CPU在4个以上，并发回收时垃圾收集线程占不小于25%的资源，并且随着CPU数量的增加而下降；但是当CPU不足4个，CMS对用户程序的影响就可能变得很大。
  2. 无法处理浮动垃圾。由于CMS在并发清理阶段用户线程还在运行，自然还会有新的垃圾不断产生，这一部分出现在标记过程之后，只能下一次GC时清理，这一部分垃圾就称为“浮动垃圾”。如果在CMS运行期间预留的内存无法满足程序的需要，就会出现“Concurrent Mode Failure”，虚拟机临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿的时间就很长了。
  3. 采用“标记-清除”法会有大量的空间碎片产生。空间碎片过多时，往往会出现老年代还有很大空间剩余，但无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。CMS提供了内存整理的功能，但是停顿的时间变长了，如果不想每次都进行内存整理，可以设置在执行多少次不压缩的Full GC后，跟着来一次带压缩的。

G1收集器

G1是一个面向服务端应用的垃圾收集器，是当今收集器技术发展的最前沿成果之一。

特点：

  1. 并行与并发：充分利用多CPU、多核环境下的硬件优势来缩短Stop-The-World停顿时间，部分其他收集器原本需要停顿Java线程执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
  2. 分代收集：不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新新对象和旧对象以获取更好的收集效果。
  3. 空间整合：从整体上来看基于“标记-整理”算法，从局部上来看基于“复制”算法。这就表明G1运作期间不会产生内存碎片，收集后能提供规整的可用内存。
  4. 可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型，能够让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。

G1收集器将Java堆划分为多个大小相等的独立区域，虽还保留新生代和老年代的概念，但新生代和老年代不是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

G1跟踪各个Region里面的垃圾堆积的价值大小（回收所得空间的大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。

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

G1收集器运作的大致步骤：

  1. 初始标记：标记GC Roots能直接关联到的对象，并且修改TAMS的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。
  2. 并发标记：从GC Root开始对堆中的对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
  3. 最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录。虚拟机把并发期间对象变化记录在线程Remembered Set Logs，最终标记阶段要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停止线程，但是可并行执行。
  4. 筛选回收：根据收集时间，优先回收价值最大的Region。

如果应用追求低停顿，那么G1现可以作为一个可尝试的选择，它的停顿时间更加可控、可预测；如果应用追求吞吐量，G1不会带来特别的好处。


参考

《深入理解Java虚拟机》