Java虚拟机之‘垃圾收集器’

分手后的思念是犯贱 2022-05-29 08:43 247阅读 0赞

![Image 1][]

在HotSpot虚拟机中，提供了七种垃圾收集器：Serial、ParNew、Parallel Scavenge、CMS、Serial Old、Paralle、G1。它们分别分布在“新生代”和“老年代”，为不同的区域提供垃圾收集。用直线连接的收集器可以搭配使用。

**一 . 新生代（Serial、ParNew、Parallel Scavenge）**

**1. Serial：**Serial是发展历史最悠久的收集器（在JDK 1.3.1之前新生代收集的唯一选择）。而且这个收集器是**单线程收集器。**收集器在工作时，会“Stop The World”，可以说**几乎所有的收集器在工作时，都会暂停用户的线程。**虽然看着很糟糕，但它依然是虚拟机运行在Client模式下的默认新生代收集器。他也有优于其他收集器的地方：**简单而高效（与其他收集器的单线程相比），对于限定的单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程效率。**

**![Image 1][]**

**2. ParNew：ParNew收集器其实就是Serial收集器的多线程版本，**除了使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数（-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，实际上，这两种收集器也公用了许多代码。

ParNew收集器除了多线程收集之外，其他的与Serial收集相比并没多多大的创新之处，但它却是运行在Server模式下的虚拟机中首选的新生代收集器，其中一个与性能无关的重要原因就是，**除了Serial收集器之外，ParNew收集器是唯一一个能与CMS收集器配合工作的**（CMS在后文详细介绍）。ParNew收集器也是使用-XX:+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX:+UseParnewGC选项来强制指定。

![Image 1][]

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

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

\-XX:MaxGCPauseMillis参数是一个大于0的毫秒值，收集器将尽可能的保证内存回收花掉的时间不超过设定值。不过不要以为把参数设置的越小，回收的速度就越快。如果设置的参数值过小，但是要回收的内存却很大，那么一次回收就无法回收完要回收的内存，这样的话Parallel Scavenge收集器就会频繁的回收内存，虽然用户线程停顿的时间变短了，但是停顿的频率却增加了。

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

由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除了以上两个参数外，Parallel Scavenge收集器还有一个参数：-XX:UseAdaotiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态的调整参数，这种调节方式称为GC自适应调节策略（GC Ergonomics）。

**二 . 老年代（CMS、Serial Old、Parallel Ole）**

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

**![20180320211129268][]**

**5. Parallel Old：**Parallel Old是Parallel Scavenge收集器的老年代版本，**使用多线程和“标记-整理”算法。**这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器之外别无选择。

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

![Image 1][]

**6. CMS：CMS（Concurrent Mark Sweeo）收集器是一种以获取最短回收停顿时间为目标的收集器。**在注重服务的响应速度，希望系统停顿的时间短，已给用户带来较好的体验，CMS就非常复合这类应用的需求。

CMS收集器作为老年代收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配和工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。

CMS收集器是基于“标记-清除”算法实现的，运作过程比前面几个收集器来说要更为复杂，整个过程分为四个步骤：

(1). **初始标记**（CMS Initial Mark）

(2). **并发标记**（CMS Concurrent Mark）

(3). **重新标记**（CMS Remark）

(4). **并发清除**（CMS Concurrent Sweep）

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

**整个过程耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所有，从总体来上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。**

**![Image 1][]**

CMS是一款优秀的收集器：并发收集，低停顿，Sun公司的一些官方文档中也称之为并发低停顿收集器（Concurrent Low Pause Collector）。但还CMS还远远达不到那么优秀，它有以下三个缺点：

(1). CMS收集器对CPU资源比较敏感。在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会变低。尤其对于核心数较少的CPU（譬如2核），CMS对用户程序的影响就可能变得很大，如果本来CPU的负荷就很大，还分出一部分运算能力去执行收集器的线程，就可能导致用户程序的执行速度忽然降低50%，是让人无法接受的。为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器变种，就是在并发标记、清理的时候让GC线程与用户线程交替运行，尽量减少GC线程占用资源的时间，这样这个垃圾收集的过程会更长，但对用户程序的影响就会显得少一些。时间证明，增量时的CMS收集器效果很一般，已经不提倡使用。

(2). CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随这程序运行自然会产生新的垃圾，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留在下一次GC时在清理。这一部分垃圾就称为“**浮动垃圾**”。所以说CMS收集器不能像其他收集器那样，等到老年代几乎被填满时再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK 1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活。可通过 -XX:CMSInitiatingOccupancyFraction的值来提高触发百分百。在JDK 1.6中，CMS收集器的启动阈值已经提升到92%，要是CMS运行期间预留的内存无法满足程序的需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，这样停顿的时间就很长了。所以说-XX:CMSInitiatingOccupancyFraction参数设置的太高很容易导致大量的“Concurrent Mode Failure”失败，性能反而降低。

(3). CMS是一款基于“标记-清除”算法实现的收集器，这就意味着收集结束的时候会有大量的空间碎片产生。空间碎片过多，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提亲触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullConllection开关参数，默认是开启的，用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿的时间变长了虚拟机设计者还提供一个参数-XX:CMSFullGCsBeforeCompaction，这个参数用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的，默认值为0。

三 . 整堆（G1）

**7. G1：**G1收集器是当今收集器技术发展的最前沿成果之一。G1是一款面向服务器端应用的垃圾收集器，G1具备如下特点：

(1). **并行与并发：**G1能充分利用多CPU、多核环境的优势，使用多个CPU来缩短“Stop The World”停顿的时间，其他收集器原本需要停顿Java线程执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

(2). **分代收集：**与其他收集器一样，分代概念在G1中仍然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能采用不同的方式去处理新创建的对象的对象和已经存活了一段时间、熬过多次GC的旧对象以获得更好的收集效果。

(3). **空间整合：**与CMS的“标记-清除”算法不同，G1整体看是基于“标记-整理”算法实现的收集器，从局部看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生空间碎片，收集过后能提供规整的内存。

(4). **可预测的停顿：**这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了准求低停顿之外，还能建立可预测的停顿时间模型，能让使用者指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这已经是实时Java（RTSJ）的垃圾收集器的特征。

G1收集器的运作可大致分为一下几个步骤：

(1). 初始标记

(2). 并发标记

(3). 最终标记

(4). 筛选回收

G1收集器的运作过程与CMS收集器很相似。初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用Region中创建新对象，这阶段需要停顿线程，但是时间很短。