JVM 学习总结（六）——垃圾收集器

垃圾收集算法是内存回收的方法论，垃圾收集器是内存回收的实践者。衡量垃圾收集器的三项最重要的指标是：内存占用（Footprint）、吞吐量（Throughput）和延迟（Latency），三者共同构成了一个“不可能三角”。一款优秀的收集器通常最多可以同时达成其中的两项。

经典垃圾收集器

各款经典收集器之间的关系如下图：

一、新生代垃圾收集器

1、Serial收集器

Serial收集器是最基础、历史最悠久的收集器。在JDK1.3.1之前是HotSpot虚拟机新生代收集器的唯一选择。这个收集器时一个单线程工作的收集器，它只会使用一个处理器或一条收集线程去完成垃圾收集工作，并且在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束，即所谓的“Stop The World”。迄今为止，它是HotSpot虚拟机运行在客户端模式下的默认新生代收集器。适用于运行在客户端模式下的虚拟机，因新生代使用的内存不大，垃圾收集时停顿时间可接受。

优点： 简单而高效（相比于其他收集器的单线程相比），额外内存消耗最小（对于内存资源受限的环境下，相较于其他所有收集器），最高的单线程收集效率（对于单核处理器或处理器核心数较少的环境来说，因Serial收集器是单线程的，没有线程交互的开销，可以专心做垃圾收集）。

缺点： Stop The World

Serial/Serial Old收集器的运行过程如下图：

2、ParNew收集器

ParNew收集器实质上是Serial收集器的多线程并行版本，是一款面向低延迟目标的垃圾收集器。是不少运行在服务端模式下的HotSpot虚拟机，尤其是JDK7之前的遗留系统中首选的新生代收集器。除了Serial收集器外，目前只有它能与CMS收集器配合工作。ParNew收集器是激活CMS后的默认新生代收集器。

ParNew收集器和Serial收集器的异同点：
相同点： Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等ParNew收集器都与Serial收集器完全一致。
不同点： ParNew收集器同时使用多条线程进行垃圾收集，而Serial收集器是单线程进行垃圾收集。

ParNew收集器的优缺点：
优点： 能够多线程并行进行垃圾收集；在多核心处理器环境中，ParNew收集器进行垃圾收集时可以高效利用系统资源（默认开启的收集线程数与处理器核心数量相同）。
缺点： JDK9开始只能与CMS收集器搭配使用；ParNew收集器在单核心处理器的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程（Hyper-Threading）技术实现实现的伪双核处理器环境中都不能百分之百保证超越Serial收集器。

ParNew/Serial Old收集器的工作过程如下图：

3、Parallel Scavenge收集器

Parallel Scavenge收集器也被称作“吞吐量优先收集器”，是一款新生代垃圾收集器，基于标记-复制算法，能够多线程并行进行垃圾收集。该收集器的目标是达到一个可控制的吞吐量（Throughput）。

吞吐量： 处理器用于运行用户代码的时间与处理器总消耗时间的比值，即：

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。可以使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成。

Parallel Scavenge收集器区别于ParNew收集器的一个重要特性为自适应调节策略。

二、老年代垃圾收集器

1、Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，同样也是一个单线程收集器，使用标记-整理算法。主要供客户端模式下的HotSpot虚拟机使用。

Serial Old在服务端模式下也可能有两种用途：

1. 在JDK5之前的版本中与Parallel Scavenge收集器搭配使用。
2. 作为CMS收集器发生失败时的后备方案，在并发收集发生Concurrent Mode Failure时使用。

Serial/Serial Old收集器的工作过程如下图：

2、Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并行收集，基于标记-整理算法实现，JDK6时开始提供该收集器。在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合。

Parallel Scavenge/Parallel Old收集器的工作过程如下图：

3、CMS收集器

CMS（Concurrent Mark Sweep）收集器也称之为“并发低停顿收集器（Concurrent Low Pause Collector）”，是HotSpot虚拟机中第一款真正意义上支持并发的，以获得最短回收停顿时间为目标的收集器。它首次实现了让垃圾收集线程与用户线程（基本上）同时工作。关注点是尽可能地缩短垃圾收集时用户线程的停顿时间。

CMS收集器是基于标记-清除算法实现的。它的运作过程分为四个步骤：

1. 初始标记（CMS initial mark）: 仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
2. 并发标记（CMS concurrent mark）: 从GC Roots的直接关联对象开始遍历整个对象图，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。（CMS收集器采用增量更新算法的方式实现在并发标记阶段保证收集线程与用户线程互不干扰地运行。）
3. 重新标记（CMS remark）: 修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍微长一些，但也远比并发标记阶段的时间短。
4. 并发清除（CMS concurrent sweep）： 清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
   初始标记、重新标记这两个步骤仍然需要“Stop The World”.
   CMS收集器的工作过程如下图：
   

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

缺点：

1. CMS收集器对处理器资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低总吞吐量。CMS默认启动的回收线程数是（处理器核心数+3）/4，如果处理器核心数在四个或以上，并发回收时垃圾收集器线程只占用不超过25%的处理器运算资源，并且会随着处理器核心数量的增加而下降。当处理器核心数量不足四个时，CMS对用户程序的影响就可能变得很大。为缓解这种情况，虚拟机曾提供了一种称为“增量式并发收集器”（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器的变种，在并发标记、并发清理的时候让收集器线程、用户线程交替运行，尽量减少垃圾收集线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得较少一些。i-CMS从JDK7开始以被声明为“deprecated”,到JDK9发布后被完全废弃。
2. CMS收集器由于无法处理“浮动垃圾”（Floating Garbage），有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC的产生。由于垃圾收集线程与用户线程并发运行，因此CMS收集器不能等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。CMS收集器的默认启动阈值为92%，即当老年代使用了92%的空间后就会激活CMS收集器进行垃圾收集。
3. CMS收集器在收集结束时会有大量空间碎片产生。空间碎片过多时，可能会导致老年代还有很多剩余空间，但是无法找到足够大的连续空间来分配给大对象，而不得不提前触发一次Full GC。解决方式，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认是开启的，JDK9开始废弃），用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的。这样空间碎片问题是解决了，但停顿时间又会变长，因此虚拟机还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction（JDK9开始废弃），这个参数的作用是要求CMS收集器在执行过若干次（数值由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理）。

注：
所谓浮动垃圾是指在CMS并发标记和并发清理阶段，用户线程还在继续运行时产生的新的垃圾对象，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法再当次收集中处理掉它们，只好留到下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾。”

三、全功能垃圾收集器（Fully Featured Garbage Collector）

G1收集器

Garbage First（简称G1）收集器是一款主要面向服务端应用的，面向全堆的垃圾收集器，它采用了面向局部收集的设计思路和基于Region的内存布局形式。从JDK9开始，G1取代了Parallel Scavenge+Parallel Old组合，成为服务端模式下的默认垃圾收集器，同时CMS被声明为Deprecate的收集器。

G1的目标是实现“停顿时间模型（Pause Prediction Model）”，停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间大概率不超过N毫秒的目标。它并非纯粹地追求低延迟，而是在延迟可控的情况下获得尽可能高的吞吐量。
G1收集器采用Mixed GC模式，即它可以面向堆内存任何部分来组成回收集（Collection Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大。

Region： G1收集器的堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region）,每个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不用的策略去处理，使得新创建的对象或者已经存活一段时间、熬过多次收集的旧对象都能获取很好的收集效果。G1收集器Region分区示意图如下：

Humongous: Region中的一类特殊区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。可以通过-XX:G1HeapRegionSize设定每个Region的大小，取值范围为1MB~32MB，且应为2的N次幂。而超过了整个Region容量的超级大对象，将会被存放在N个连续的humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分进行看待。

G1收集器的运作过程大致可划分为以下四个步骤：

• 初始标记（Initial Marking）： 仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实并没有额外的停顿。
• 并发标记（Concurrent Marking）： 从GC Roots开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找到要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
• 最终标记（Final Marking）： 对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
• 筛选回收（Live Data Counting and Evacuation）： 负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

G1收集器运行过程如下图：

G1收集器和CMS收集器都非常关注停顿时间的控制。
G1收集器与CMS收集器的比较：

1. G1收集器较于CMS收集器的优点：
   - 可以指定最大停顿时间
   - 分Region的内存布局
   - 按收益动态确定回收集
   - G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“标记-复制”算法实现，这两种算法都意味着G1运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。而CMS是基于“标记-清除”算法实现的，会产生内存空间碎片。
2. G1收集器较于CMS收集器的缺点：
   - 在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（Overload）都要比CMS要高。

低延迟垃圾收集器

• 1.Shenandoah收集器
• 2.ZGC收集器

参考：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） 周志明