JVM垃圾回收系列之垃圾收集器一

序

“黑发不知勤学早,白发方悔读书迟”
在这里插入图片描述

引言

本文将介绍HotSpot中常见的几种垃圾收集器，如：Serial、ParNew、Parallel Scavenge、CMS等

参考书籍：“深入理解Java虚拟机”

垃圾收集器的分类

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器，也就是说jvm使用什么垃圾收集器可以由用户自定义配置。如果用户不去配置，JAVA1.8中默认的垃圾回收器：Parrallel Scanvenge+ParallelOld

下图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

在这里插入图片描述
看上图，大家可能会有一个问题，为什么虚拟机提供了这么多的垃圾收集器，那这里需要大家明确一个观点：虽然我们是在对各个收集器进行比较，但并非为了挑选出一个最好的收集器，因为直到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。

评价GC性能指标：

吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间:程序的运行时间+内存回收的时间）（重点）
垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。（重点）
收集频率：相对于引用程序的执行，收集操作发生的频率
内存占用：Java堆区所占的内存大小。（重点）
快速：一个对象从诞生到被回收所经历的时间

Serial回收器：串行回收

Serial收集器时最基本、历史最悠久的垃圾收集器。JDK1.3之前回收新生代唯一的选择。Serial收集器作为HotSopt中Client模式下的默认新生代垃圾收集器。Serial收集器采用复制算法、串行回收和“Stop-the-World”机制的方式执行内存回收。除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。Serial Olds收集器同样也采用了串行回和“Stop-the-World”机制，只不过内存回收算法使用的是标记-压缩算法。Serial Old试运行在Client模式下默认的老年代的垃圾回收器Serial Old在Server模式下主要有两个用途：

与新生代的Parallel Scavenge配合使用
作为老年代CMS收集器的后备垃圾收集方案。

在这里插入图片描述

这个收集器是一个单线程的收集器，但它的“单线程”的意义不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它进行垃圾收集时，必须暂停其他所有的工作线程，知道它收集结束（Stop The World）

优势：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获取最高的单线程收集效率。（运行在Client模式下的虚拟机是个不错的选择）

缺点：当处于STW时，运行在虚拟机上的程序都无法提供服务（这是无法忍受的！！！）

在HotSpot虚拟机中，使用-XX:UseSerialGC参数可以指定年轻代和老年代都是用的串行收集器。等价于新生代用Serial GC，且老年代用Serial Old GC，这种垃圾收集器只需要了解就行，如今基本这个垃圾收集器。因为这个垃圾收集器只在限定单核的中使用。现在都不是单核的了。

应用场景：单核嵌入式设备

ParNew回收器：并行回收

如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本。Par是Parallel的缩写，New：只能处理的是新生代。ParNew收集器在年轻代中同样也是采用复制算法、“Stop The World”机制，ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器

ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器 Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。ParNew收集器也是使用-XX:+UseConcMarkSweepGC 选项后的默认新生代收集器，也可以使用-XX:+UseParNewGC选项来强制指定它。

那么有一个问题油然而生：由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效？

答：ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快地完成垃圾收集，提升程序的吞吐量。但是在单个CPU的环境下，ParNew收集器不必Serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。因为除Serial外，目前只有ParNew GC能与CMS收集器配合工作。
在这里插入图片描述
特点：

对于新生代，回收次数频繁，使用并行方式高效。
对于老年代，回收次数少，使用串行方式节省次元（CPU并行需要切换线程，串行可以省去切换线程的资源）

Parallel Scavenge回收器：吞吐量优先

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和“Stop the World”机制

那么Parallel Scavenge收集器与ParNew的原理一样，那么这个回收器的作用是什么？

和ParNew收集器不同， Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput），它也被称为吞吐量优先的垃圾收集器。
自适应调节策略也是Parallel Scavenge与ParNew一个重要区别。
高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

参数配置：

-XX:+UseParallelGC 手动指定年轻代使用Parallel并行收集器执行内存回收任务。
-XX:+UseParallelOldGC手动指定老年代都是使用并行回收收集器。
- 分别使用于新生代和老年代。默认jdk8是开启的。
- 上面两个参数，默认开启一个，另一个也会被开启（互相激活）
-XX:ParallelGCThreads 设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。
- 在默认情况下，当CPU数量小8个，ParallelGCThreads的值等于CPU数量。
- 当CPU数量大于8个，ParallelGCThreads的值等于3+[5*CPU_Count]/8].
-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即STW的时间）。单位是毫秒。
- 为了尽可能地把停顿时间控制在MaxGCPauseMillis以内，收集器在工作时会调整Java堆大小或者其他一些参数。对于用户来讲，停顿时间越短体验越好。但是在服务器，我们注重高并发，整体的吞吐量。所以服务器适合Parallel，进行控制。（使用这个参数的时候需谨慎）
-XX:GCTimeRatio 垃圾收集时间占总时间的比例（1/(N+1)）.
- 取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%
- 与前一个-XX:MaxGCPauseMillis参数有一定的矛盾性。暂停时间越长，Ratio参数就容易超过设定的比例。

Serial Old收集器：作用于老年代

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途:一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge 收集器搭配使用（需要说明一下，Parallel Scavenge收集器架构中本身有PS MarkSweep收集器来进行老年代收集，并非直接使用了Serial Old收集器，但是这个PS MarkSweep收集器与Serial Old的实现非常接近），另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

在这里插入图片描述

Parallel Old收集器：作用于老年代

Parallel Old是Parallel Scavenge收集器的老年代版本，采用了标记-压缩算法，但同样也是基于并行回收和“Stop-The-World”机制。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了 Serial Old(PS MarkSweep)收集器外别无选择(还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗?)。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。
在这里插入图片描述

CMS回收器：低延迟

在JDK1.5时期，HotSpot退出一款强交互应用中几乎有划时代意义的垃圾收集器：CMS（Concurrent-Mark–Sweep）收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。

CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。（目前很大一部分的Java应用几种在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求）

CMS的垃圾收集算法采用标记-清除算法，并且也会“Stop-the-World”，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括:

初始标记（Initial Mark）阶段：在这个阶段中，程序中所有的工作线程都将会因为“Stop-the-World”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的速度非常快。
并发标记（Concurrent Mark）阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程。这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。（整个标记过程耗时最长）
重新标记（Remark）阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
并发清除（Concurrent Sweep）阶段：此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以用用户线程同时并发的（在此阶段之后还会有一个重置线程的一个操作）。

在这里插入图片描述
优点：

并发收集、低延迟

缺点：
2. 会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前出发Full GC
3. CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致引用程序变慢，总吞吐量会降低。
4. CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。