JVM系列之七种垃圾收集器

最新推荐文章于 2023-02-20 14:29:53 发布

Wonder丶丶丶

最新推荐文章于 2023-02-20 14:29:53 发布

阅读量274

点赞数

分类专栏： Java虚拟机文章标签： jvm

本文链接：https://blog.csdn.net/WZH577/article/details/109584193

版权

Java虚拟机专栏收录该内容

22 篇文章 0 订阅

订阅专栏

目前HotSpot虚拟机中的垃圾收集器有如下7种，需要明确的是：到目前为止还没有适应所有场景的最好的垃圾收集器，所以在不同的适用场景中需要选择不同的垃圾收集器。

收集器	串行/并行/并发	算法	分代区域	目标	适用场景	简述
Serial收集器	串行	复制	年轻代	响应速度优先	单核CPU的Client模式	最基本、发展历史最悠久的收集器，曾是（JDK1.3.1之前）虚拟机新生代收集的唯一选择。
ParNew收集器	并行	复制	年轻代	响应速度优先	多核CPU的Server模式与CMS配合	Serial收集器的多线程版本
Parallel Scavenge收集器	并行	复制	年轻代	吞吐量优先	在后台运算而不需要太多交互的任务	关注点是达到一个可控制的吞吐量，“吞吐量优先”收集器
Serial Old收集器	串行	标记-整理	老年代	响应速度优先	单核CPU的Client模式、CMS并发收集失败时的后备方案	Seria收集器的老年代版本
Parallel Old收集器	并行	标记-整理	老年代	吞吐量优先	在后台运算而不需要太多交互的任务	Parallel Scavenge收集器的老年代版本，在JDK1.6中才出现
CMS收集器	并发	标记-清除	老年代	响应速度优先	互联网站或者B/S系统的服务端上大量用户交互的Java应用	以获取最短回收停顿时间为目标的收集器
G1收集器	并发	复制+标记-整理	年轻代和老年代	响应速度优先	面向服务端应用	CMS的更优方案，JDK1.9的默认收集器，引入分区收集，弱化了分代的概念

Serial收集器

Serial收集器是单线程的收集器。最基本、发展历史最悠久的收集器，曾是（JDK1.3.1之前）虚拟机新生代收集的唯一选择。

缺点：只会使用一个CPU或一条收集器线程去完成垃圾收集工作，更重要的是它在垃圾收集的时候，必须暂停其他所有工作的线程，直到它收集结束（STW）。

优点：简单而高效（与其他收集器的单线程相比），由于没有线程交互的开销，可以获得最高的单线程收集效率（在单个CPU环境中）。

应用：HotSpot虚拟机运行在Client模式下的默认新生代收集器。

相关参数：

-XX:+UseSerialGC：指定使用Serial+SerialOld垃圾收集器组合。

Serial收集器和SerialOld收集器配合使用的执行过程如下：

ParNew收集器

ParNew收集器是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Word、对象分配规则、回收策略等都与Serial收集器一样。

相对于Serial收集器：ParNew 收集器在单CPU的环境中绝对不会有比Serial收集器有更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越。在多CPU环境下，随着CPU的数量增加，它对于GC时系统资源的有效利用是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多的情况下可使用-XX:ParallerGCThreads参数设置。

并行和并发

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行。而垃圾收集程序运行在另一个CPU上。

应用：许多运行在Server模式下的虚拟机首选的新生代收集器，因为除了Serial收集器之外，目前只有ParNew收集器能与CMS收集器配合工作（Parallel Scavenge收集器无法与CMS收集器配合使用）。

相关参数：

-XX:+UseParNewGC：指定使用ParNew+SerialOld收集器组合。
-XX:+UseConcMarkSweepGC：指定使用ParNew+CMS+SerialOld收集器组合。
-XX:ParallelGCThreads：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同。

ParNew收集器和SerialOld收集器配合使用的执行过程如下：

Parallel Scavenge收集器

Parallel Scavenge收集器和ParNew收集器一样是一个新生代收集器，使用复制算法，且是并行的多线程收集器。

相对于ParNew收集器：Parallel Scavenge收集器关注点是达到一个可控制的吞吐量，而其他收集器关注点在尽可能的缩短垃圾收集时用户线程的停顿时间，所以Parallel Scavenge收集器又叫“吞吐量优先”收集器。

停顿时间和吞吐量

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即：吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），假设虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
停顿时间就是GC在STW线程暂停的时间，停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。

为了精确控制吞吐量，Parallel Scavenge收集器提供了两个参数，-XX：MaxGCPauseMillis参数控制最大垃圾收集停顿时间， -XX：GCTimeRatio参数控制吞吐量大小；

相关参数：

-XX:+UseParallelGC或者-XX:+UseParallelOldGC：指定使用Parallel Scavenge+Parallel Old收集器组合
-XX:MaxGCPauseMillis：设定GC停顿时间（大于0的毫秒数），收集器将尽可能保证垃圾回收的时间不超过该设定值（该值不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然保证了较短的GC停顿时间，但是吞吐量却变低了）。
-XX:GCTimeRatio：设定吞吐量（大于0小于100的整数），例如：x为该参数的设定值，那么吞吐量为(x/(1+x))。默认值是99，也就是吞吐量为99%（99/(1+99)），允许最大1%的垃圾收集时间。
-XX:UseAdaptiveSizePolicy：打开GC自适应的调节策略，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的大小（-Xmn）、老年代和新生代的比值（-XX:NewRatio）、Eden区和Survivor区的比值（-XX:SurvivorRatio）等细节参数，以提供最合适的停顿时间或最大的吞吐量。

Serial Old收集器

Serial Old收集器是Seria收集器的老年代版本，同样是一个单线程收集器，使用" 标记-整理" 算法。

应用：

主要用于Client模式下的虚拟机使用。
在Server模式下的两大用途：在JDK1.5及之前的版本与Parallel Scavenge收集器搭配使用；作为CMS收集器的后备方案，在并发收集发生Conturrent Mode Failure时使用。

Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。在JDK1.6中才出现，只能和Parallel Scavenge收集器配合使用。

应用：主要用于配合Parallel Scavenge收集器作为老年代收集器，“吞吐量优先”收集器的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old收集器组合。

Parallel Scavenge收集器和Parallel Old收集器配合使用的执行过程如下：

CMS(Conturrent Mark Sweep)收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，主要为互联网站或者B/S系统的服务端上需要大量用户交互的Java应用提供较好的用户体验。该收集器采用的是“标记-清除”算法。

运行过程分为以下4个步骤：

初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要STW。
并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
重新标记（CMS remark）：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要STW。
并发清除（CMS concurrent sweep）

优点：可与用户线程并发收集、停顿时间短

浮动垃圾（Floating Garbage）

由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。当预留的空间不足以并发收集时使用就会出现“Concurrent Mode Failure”，这时JVM临时启用Serial Old收集器来重新进行老年代垃圾收集，这就会导致停顿时间更长了。

缺点：

对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，如果本来CPU负载就比较大，还要分出相当一部分去执行收集器线程，就可能导致用户程序的执行效率会忽然降低。
无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
标记-清除算法导致的空间碎片。

相关参数

-XX:+UseConcMarkSweepGC：指定使用ParNew+CMS+SerialOld收集器组合。
-XX:CMSInitiatingOccupancyFraction=92：设置老年代内存使用达到多少百分比时启动收集。默认是92%，也就是当内存达到92%时就会触发GC，预留了8%内存用于并发收集。该值设置的过低则老年代空间没办法充分使用导致GC频繁，设置过高则容易出现“Concurrent Mode Failure”导致停顿时间加长。
-XX:UseCMSCompactAtFullCollection：用于在CMS收集器顶不住要FullGC时开启内存碎片整理（内存碎片整理意味着无法并发执行不得不停顿用户线程）。
-XX:CMSFullGCsBeforeCompaction=0：设置执行多少次不压缩的Full GC后，紧接着来一次带压缩的（默认值是0，意味着每次进入Full GC时都进行碎片整理）。

G1(Garbage-First)收集器

G1（Garbage-First）是一款面向服务端应用的垃圾收集器，目标是替换掉JDK1.5中发布的CMS收集器，目前是JDK1.9的默认垃圾收集器。

特点：

和CMS一样在多CPU、多核环境下的并行与并发
引入分区收集，弱化了分代的概念，可以横跨整个堆内存进行分代收集，不需要其他收集器配合就能独立管理整个GC堆
不会产生内存空间碎片，从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的
可预测的停顿时间模型，能让使用者明确指定在GC上消耗的时间不得超过某个数值

分区（Region）

G1收集器将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（不需要连续）的集合。所以G1收集器可以不需要其他收集器配合就能独立管理整个GC堆，能够采用不同方式去处理新创建的对象和已存活一段时间、熬过多次GC的旧对象来获取更好的收集效果。

G1收集器可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

已记忆集合（Remembered Set）

G1把Java堆分为多个Region，就是“化整为零”。但是Region不可能是孤立的，一个对象分配在某个Region中，可以与整个Java堆任意的对象发生引用关系。在做可达性分析确定对象是否存活的时候，需要扫描整个Java堆才能保证准确性，这显然是对GC效率的极大伤害。

为了避免全堆扫描的发生，虚拟机为G1中每个Region维护了一个与之对应的Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作。

检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

巨型对象（Humongous Region）

一个大小达到甚至超过分区大小一半的对象称为巨型对象(Humongous Object)。当线程为巨型分配空间时，不能简单在TLAB进行分配，因为巨型对象的移动成本很高，而且有可能一个分区不能容纳巨型对象。因此，巨型对象会直接在老年代分配，所占用的连续空间称为巨型分区(Humongous Region)。G1内部做了一个优化，一旦发现没有引用指向巨型对象，则可直接在年轻代收集周期中被回收。

巨型对象会独占一个、或多个连续分区，其中第一个分区被标记为开始巨型(StartsHumongous)，相邻连续分区被标记为连续巨型(ContinuesHumongous)。由于无法享受Lab带来的优化，并且确定一片连续的内存空间需要扫描整堆，因此确定巨型对象开始位置的成本非常高，如果可以，应用程序应避免生成巨型对象。

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

初始标记（Initial Marking）：仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的Region中创建对象，此阶段需要停顿线程，但耗时很短。
并发标记（Concurrent Marking）：从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
最终标记（Final Marking）：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
筛选回收（Live Data Counting and Evacuation）：首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

相关参数：

-XX:+UseG1GC：指定使用G1收集器。
-XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认值是 200 毫秒。
-XX:G1HeapRegionSize=n：可指定分区Region大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区。
-XX:ConcGCThreads=n：设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=n：设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。