跳至主要內容

15. JVM 垃圾回收器详解

安图新大约 57 分钟

15. JVM 垃圾回收器详解

1. 垃圾回收器的分类 和 GC 性能指标

垃圾收集器没有在规范中进行过多的规定,可以由不同的厂商、不同版本的 JVM 来实现。

由于 JDK 的版本处于高速迭代过程中,因此 Java 发展至今已经衍生了众多的 GC 版本。

从不同角度分析垃圾收集器,可以将 GC 分为不同的类型。

1.1 分类

按线程数分(垃圾回收线程数),可以分为串行垃圾回收器和并行垃圾回收器。

1、 串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束;
2、 和串行回收相反,并行收集可以运用多个 CPU 同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然与串行回收一样,采用独占式,工作线程等待 GC 执行完;

 
 

适用场景

1、 在单 CPU 处理器或者较小的应用内存等硬件平台不是特别优越的场合,串行回收器的性能表现可以超过并行回收器和并发回收器所以,串行回收默认被应用在客户端的 Client 模式下的 JVM 中;
2、 在并发能力比较强的 CPU 上(多核),并行回收器产生的停顿时间要短于串行回收器;

按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。

1、 并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间;
2、 独占式垃圾回收器(上面两个都是)一旦运行,就停止应用程序中的所有用户线程,直到垃圾回收过程完全结束;

 
 

按碎片处理方式分,可分为压缩式垃圾回收器和非压缩式垃圾回收器。

1、 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片,分配对象空间使用指针碰撞;
2、 非压缩式的垃圾回收器不进行这步操作,分配对象空间使用空闲列表;

按工作的内存区间分

又可分为年轻代垃圾回收器和老年代垃圾回收器。

1.2 GC 的性能指标

评估一个 GC 回收器的性能,主要看下面几个点

1、 吞吐量:运行用户代码的时间占总运行时间的比例(总运行时间=程序的运行时间+内存回收的时间);
2、 垃圾收集开销:吞吐量的补数,垃圾收集所用时间与总运行时间的比例;
3、 暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间;
4、 收集频率:相对于应用程序的执行,收集操作发生的频率;
5、 内存占用:Java 堆区所占的内存大小;
6、 快速:一个对象从诞生到被回收所经历的时间;

其中,吞吐量、暂停时间、内存占用这三者共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。

这三项里,暂停时间的重要性日益凸显。因为随着硬件发展,内存占用多些越来越能容忍,硬件性能的提升也有助于降低收集器运行时对应用程序的影响,即提高了吞吐量。但是内存的扩大,对延迟反而带来负面效果。

简单来说,主要抓住两点:

  • 吞吐量
  • 暂停时间

吞吐量(throughput)VS 暂停时间(pause time)

吞吐量:

1、 吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间);
2、 比如:虚拟机总共运行了 100 分钟,其中垃圾收集花掉 1 分钟,那吞吐量就是 99%;
3、 这种情况下,应用程序能容忍较高的暂停时间,因此,高吞吐量的应用程序有更长的时间基准,快速响应是不必考虑的;
4、 吞吐量优先,意味着在 GC 的总体时间较短;

暂停时间:

1、 “暂停时间”是指一个时间段内应用程序线程暂停,让 GC 线程执行的状态,例如,GC 期间 100 毫秒的暂停时间意味着在这 100 毫秒期间内没有应用程序线程是活动的;
2、 暂停时间优先,意味着 GC 停顿时间比价分散,单次延迟低;

对比示意图:

 
 

1、 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作宏观上,吞吐量越高程序运行越快;
2、 低暂停时间(低延迟)较好,因为从最终用户的角度来看,不管是 GC 还是其他原因导致一个应用被挂起始终是不好的这取决于应用程序的类型,有时候甚至短暂的 200 毫秒暂停都可能打断终端用户体验因此,具有较低的暂停时间是非常重要的,特别是对于一个交互式应用程序;
3、 不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标(矛盾);

  • 因为如果选择以吞吐量优先,那么必然需要降低内存回收的执行频率,但是这样会导致 GC 需要更长的暂停时间来执行内存回收(单次)。
  • 相反的,如果选择以低延迟优先为原则,那么为了降低每次执行内存回收时的暂停时间,也只能频繁地执行内存回收,但这又引起了频繁切换引起的性能开销, 导致程序吞吐量的下降。

在设计(或使用)GC 算法时,我们必须确定我们的目标:一个 GC 算法只可能针对两个目标之一(即只专注于较大吞吐量或最小暂停时间),或尝试找到一个二者的折中。

现在的标准:在最大吞吐量优先的情况下,降低停顿时间

2. 经典垃圾回收器

2.1 垃圾回收器发展史

有了虚拟机,就一定需要收集垃圾的机制,这就是 Garbage Collection(垃圾回收),对应的产品我们称为 Garbage Collector(垃圾回收器)。 先看一下随着 java 的发展,GC 的进阶历程:

1、 1999 年随 JDK1.3.1 一起来的是串行方式的 SerialGC,它是第一款 GCParNew 垃圾收集器是 Serial 收集器的多线程版本;
2、 2002 年 2 月 26 日,ParallelGC 和 ConcurrentMarkSweepGC 跟随 JDK1.4.2 一起发布·;
3、 ParallelGC 在 JDK6 之后成为 HotSpot 默认 GC;
4、 2012 年,在 JDK1.7u4 版本中,G1 可用;
5、 2017 年,JDK9 中 G1 变成默认的垃圾收集器,以替代 CMS;
6、 2018 年 3 月,JDK10 中 G1 垃圾回收器的并行完整垃圾回收,实现并行性来改善最坏情况下的延迟;
7、 2018 年 9 月,JDK11 发布引入 Epsilon 垃圾回收器,又被称为"No-Op(无操作)“回收器同时,引入 ZGC:可伸缩的低延迟垃圾回收器(Experimental);
8、 2019 年 3 月,JDK12 发布增强 G1,自动返回未用堆内存给操作系统同时,引入 ShenandoahGC:低停顿时间的 GC(Experimental);
9、 2019 年 9 月,JDK13 发布增强 ZGC,自动返回未用堆内存给操作系统;
10、 2020 年 3 月,JDK14 发布删除 CMS 垃圾回收器扩展 ZGC 在 macOS 和 Windows 上的应用;

其中最经典最常用的垃圾回收器:

1、 串行回收器:Serial、Serialold;
2、 并行回收器:ParNew、ParallelScavenge、Parallelold;
3、 并发回收器:CMS、G1;

2.2 垃圾回收器之间的关系

上面的七种垃圾回收器, 有各自自己负责收集的区域:

1、 新生代收集器:Serial、ParNew、ParallelScavenge;
2、 老年代收集器:Serialold、Parallelold、CMS;
3、 整堆收集器:G1;

下面示意图中,上半部分代表年轻代, 下半部分代表老年代,, 并用线条表示他们的配合关系

 
 

两个收集器间有连线,表明它们可以搭配使用:

  • Serial/Serial old
  • Serial/CMS
  • ParNew/Serial Old
  • ParNew/CMS
  • Parallel Scavenge/Serial Old
  • Parallel Scavenge
  • Parallel Old、G1;

其中 Serial Old 作为 CMS 出现"Concurrent Mode Failure"失败的后备预案。

移除说明:

1、 由于维护和兼容性测试的成本,在 JDK8 时将 Serial+CMS、ParNew+SerialOld 这两个组合声明为废弃过时(JEP173),并在 JDK9 中完全取消了这些组合的支持(JEP214),即:移除(红色虚线表示);
2、 JDK14 中:弃用 ParallelScavenge 和 SerialOldGC 组合(JEP366)(绿色虚线);
3、 JDK14 中:删除 CMS 垃圾回收器(JEP363)(青色虚线);

为什么 jvm 中 实现了这么多的 GC

虽然我们会对各个收集器进行比较,但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在,更加没有万能的收集器。所以我们选择的只是对具体应用最合适的收集器。

Java 的使用场景很多,移动端,服务器等。所以就需要针对不同的场景,提供不同的垃圾收集器,提高垃圾收集的性能。

2.3 查看正在使用的垃圾回收器

方式一:

jvm 指令,-XX:+PrintCommandLineFlags 该指令 将打印 jvm 相关参数,包含使用的垃圾回收器

在 jdk8 下,查看:

-XX:InitialHeapSize=266620736 -XX:MaxHeapSize=4265931776 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC

程序打印输出如上,,最后一个指令-XX:+UseParallelGC 表示在 JDK8 下,使用 ParallelGC 回收器 ,ParallelGC 默认和 Parallel Old 绑定使用

方式二:

使用 jps+jinfo 命令, 先打印出本机运行的 java 进程.在通过进程 id 查看相关参数

 
 

3. 各个垃圾回收器具体说明

3.1 年轻代回收器: Serial 回收器(串行回收)

1、 Serial 收集器是最基本、历史最悠久的垃圾收集器了 JDK1.3 之前回收新生代唯一的选择;
2、 Serial 收集器是作为 HotSpot 中 Client 模式下的默认新生代垃圾收集器;
3、 Serial 收集器采用复制算法、串行回收和"Stop-the-World"机制的方式执行内存回收;
4、 除了年轻代之外,Serial 收集器还提供用于执行老年代垃圾收集的 SerialOld 收集器 Serialold 收集器同样也采用了串行回收和"StoptheWorld"机制,只不过内存回收算法使用的是标记-压缩算法
5、 SerialOld 是运行在 Client 模式下默认的老年代的垃圾回收器,但是 SerialOld 在 Server 模式下主要有两个用途:;

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

这个收集器是一个单线程的收集器,“单线程”的意义:

1、 它只会使用一个 CPU 或者说是一条收集线程去完成垃圾收集工作;
2、 更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束(StopTheWorld);

工作示意图:

 
 

Serial 回收器的优势 :

1、 优势:简单而高效(单 CPU 单核下),对于限定单个 CPU 的环境来说,Serial 收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率;
2、 运行在 Client 模式下的虚拟机是个不错的选择;
3、 在用户的桌面应用场景中,可用内存一般不大(几十 MB 至一两百 MB),可以在较短时间内完成垃圾收集(几十 ms 至一百多 ms),只要不频繁发生,使用串行回收器是可以接受的;

如何切换到 Serial GC

在 HotSpot 虚拟机中,使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。 及切换到

Serial GC / Serial Old GC

总结

1、 这种垃圾收集器了解即可,现在已经不用串行的了只在限定单核 CPU 才可以用现在几乎都不是单核的了;
2、 对于交互较强的应用而言,这种垃圾收集器是不能接受的一般在 JavaWeb 应用程序中是不会采用串行垃圾收集器的;

3.2 年轻代回收器: ParNew 回收器(并行回收)

1、 如果说 SerialGC 是年轻代中的单线程垃圾收集器,那么 ParNew 收集器则是 Serial 收集器的多线程版本
2、 Par 是 Parallel 的缩写,New:只能处理新生代;
3、 ParNew 收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别(其底层也共享了大量的代码)ParNew 收集器在年轻代中同样也是采用复制算法、"Stop-the-World"机制;
4、 ParNew 是很多 JVM 运行在 Server 模式下新生代的默认垃圾收集器;

在不考虑版本的情况下, ParNew 可以和 Serial Old, CMS, 这两个回收老年代的回收器配合使用(在最新的版本中,貌似和 ParNew 搭档的路线都被干掉了),

下面是 ParNew / Serial Old 搭配的示意图:

 
 

为什么使用上面这个组合:

1、 对于新生代,回收次数频繁,使用并行方式高效;
2、 对于老年代,回收次数少,使用串行方式节省资源(CPU 并行需要切换线程,串行可以省去切换线程的资源);

ParNew 回收器与 Serial 回收器效率比较

由于 ParNew 收集器基于并行回收,那么是否可以断定 ParNew 收集器的回收效率在任何场景下都会比 Serial 收集器更高效?并不能

1、 ParNew 收集器运行在多 CPU 的环境下,由于可以充分利用多 CPU、多核心等物理硬件资源优势,可以更快速地完成垃圾收集,提升程序的吞吐量;
2、 但是在单个 CPU 的环境下,ParNew 收集器不比 Serial 收集器更高效虽然 Serial 收集器是基于串行回收,但是由于 CPU 不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销;

设置 ParNew 垃圾回收器

1、 在程序中,开发人员可以通过选项-XX:+UseParNewGC手动指定使用 ParNew 收集器执行内存回收任务它表示年轻代使用并行收集器,不影响老年代;
2、 -XX:ParallelGCThreads限制 ParNew 线程数量,默认开启和 CPU 数据相同的线程数;

3.3 年轻代回收器: Parallel 回收器(并行回收,自适应调节)

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

那么 Parallel 收集器的出现是否多此一举呢?

  • 和 ParNew 收集器不同,Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器。
  • 自适应调节策略也是 Parallel Scavenge 与 ParNew 一个重要区别。

高吞吐量则可以高效率地利用 CPU 时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

对于老年代的搭配. Parallel 收集器在 JDK1.6 时提供了用于执行老年代垃圾收集的 Parallel Old 收集器,用来代替老年代的 Serial Old 收集器。

Parallel Old 收集器采用了标记-压缩算法,但同样也是基于并行回收和"Stop-the-World"机制。

Parallel / Parallel Old 工作示意图:

 
 

1、 在程序吞吐量优先的应用场景中,Parallel 收集器和 ParallelOld 收集器的组合,在 server 模式下的内存回收性能很不错;
2、 在 Java8 中,默认是此垃圾收集器

Parallel GC 的参数设置

  • -XX:+UseParallelGC 手动指定年轻代使用 Parallel 并行收集器执行内存回收任务。
  • -XX:+UseParallelOldGC:手动指定老年代都是使用并行回收收集器。

注意: 上面两个参数分别适用于新生代和老年代。默认 jdk8 是开启的。默认开启一个,另一个也会被开启。(互相激活)

  • -XX:ParallelGCThreads: 手动设置 并行收集器的线程数。一般地,最好与 CPU 数量相等,以避免过多的线程数影响垃圾收集性能。

  • 在默认情况下,当 CPU 数量小于等于 8 个,ParallelGCThreads 的值等于 CPU 数量。

  • 当 CPU 数量大于 8 个,ParallelGCThreads 的值等于 3+[5*CPU_Count]/8] ( 无需占用太多的 CPU,让给其他程序执行)

  • -XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即整个 STW 的时间)。单位是毫秒。

  • 为了尽可能地把停顿时间控制在设置的 XX:MaxGCPauseMillis 以内,收集器在工作时会调整 Java 堆大小或者其他一些参数。

  • 对于用户来讲,停顿时间越短体验越好。但是在服务器端,我们注重高并发,整体的吞吐量。所以服务器端适合 Parallel,进行控制。

注意: 该参数使用需谨慎 , jvm 会尽量的去满足设置的时间(不一定准确实现), 而动态设置堆空间的大小,比如调小这个时间,jvm 也会尽量调小堆空间内存,以满足单次 GC 时对时间的要求,但这将导致 GC 的频率变高, 吞吐量也就下去了

  • -XX:GCTimeRatio 垃圾收集时间占总时间的比例,即等于 1 / (N+1) ,用于调节吞吐量的大小。

  • 取值范围(0, 100)。默认值 99,也就是垃圾回收时间占比不超过 1。

  • 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性

  • STW 暂停时间越长,Radio 参数就容易超过设定的比例。

  • -XX:+UseAdaptiveSizePolicy 设置 Parallel Scavenge 收集器具有自适应调节策略,也是上面两个参数调节有效的核心,而上面两个参数在默认情况下是吞吐量优先的,默认开启,

  • 在这种模式下,年轻代的大小、Eden 和 Survivor 的比例、晋升老年代的对象年龄等参数会被自动调整,已达到在堆大小、吞吐量和停顿时间之间的平衡点。

  • 在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆、目标的吞吐量(GCTimeRatio)和停顿时间(MaxGCPauseMillis),让虚拟机自己完成调优工作。

这里还记得在说, 年轻代的默认比例是,说是 8:1:1 ,但是实际要差一点,就是因为这个参数默认开始调节导致的

3.4 老年代回收器: CMS 回收器(并发回收)

1、 在 JDK1.5 时期,Hotspot 推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS(Concurrent-Mark-Sweep)收集器,这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作;
2、 CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验(将单次 GC 细分,其中某些环节用户线程和 GC 可以同时执行);
3、 目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验 CMS 收集器就非常符合这类应用的需求;
4、 CMS 的垃圾收集算法采用标记-清除算法,并且也会"Stop-the-World"
5、 不幸的是,CMS 作为老年代的收集器,却无法与 JDK1.4.0 中已经存在的新生代收集器 ParallelScavenge 配合工作,所以在 JDK1.5 中使用 CMS 来收集老年代的时候,新生代只能选择 ParNew 或者 Serial 收集器中的一个(比较过时的两个);
6、 在 G1 出现之前,CMS 使用还是非常广泛的一直到今天,仍然有很多系统使用 CMSGC;

CMS 工作原理示意图

 
 

从上图可以看出,在一次 GC 中,分成多个部分, 其中有两个环节可以同时执行, 所以整体上来看, GC 的整个过程为并发执行

CMS 整个过程比之前的收集器要复杂,整个过程分为 4 个主要阶段,即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。(涉及 STW 的阶段主要是:初始标记 和 重新标记)

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

CMS 的特点

1、 尽管 CMS 收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行“Stop-the-World”机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要“Stop-the-World”,只是尽可能地缩短暂停时间;
2、 由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作,所以整体的回收是低停顿的另外,由于在垃圾收集阶段用户线程没有中断,所以在 CMS 回收过程中,还应该确保应用程序用户线程有足够的内存可用(在标记清除时,用户线程也在执行,若等满了再回收,将来不及回收);
3、 因此,CMS 收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行;
4、 要是 CMS 运行期间预留的内存无法满足程序需要,就会出现一次“ConcurrentModeFailure”;
失败,这时虚拟机将启动后备预案:临时启用 Serial old 收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。(真的在标记 清除阶段用户线程产生垃圾过快,导致还没 GC 完 就 满了,将启动备选方案) 5、 CMS 收集器的垃圾收集算法采用的是标记清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片那么 CMS 在为新对象分配内存空间时,将无法使用指针碰撞(BumpthePointer)技术,而只能够选择空闲列表(FreeList)执行内存分配;

为什么 CMS 不采用标记-压缩算法呢?

答案其实很简答,因为当并发清除的时候,用 Compact 整理内存的话,原来的用户线程使用的内存还怎么用呢?

要保证用户线程能继续执行,前提的它运行的资源不受影响,内存不能动,引用的对象地址也不能动。Mark Compact 更适合“stop the world”这种场景下使用

CMS 的优点与缺点

优点

1、 并发收集;
2、 低延迟;

缺点

1、 会产生内存碎片,导致并发清除后,用户线程可用的空间不足在无法分配大对象的情况下,不得不提前触发 FullGC;
2、 CMS 收集器对 CPU 资源非常敏感在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低(虽然不停止用户线程,但是还是会使用户线程变慢);
3、 CMS 收集器无法处理浮动垃圾可能出现“ConcurrentModeFailure"失败而导致另一次 FullGC 的产生在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的,那么在并发标记阶段如果产生新的垃圾对象,CMS 将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行 GC 时释放这些之前未被回收的内存空间(在并发标记阶段中用户线程也在执行,对于此时又产生的垃圾将无法清理,只能等到下一次);

因为使用 CMS GC 可能会埋下隐患,

在 GC 中,因为用户线程仍然执行,而导致的内存不足,从而导致 Serial Old 备选执行,Serial old 是串行执行并且有很严重的 STW,效率比较慢,所以将导致程序卡顿

还有因为 碎片过多,导致大对象放不下而使 Full GC 提前触发,也将导致程序停顿,所以 JDK 在后续的更新中 渐渐消除了 CMS GC 使用 G1 代替

CMS 参数

-XX:+UseConcMarkSweepGC:手动指定使用 CMS 收集器执行内存回收任务

开启该参数后会自动将-XX:+UseParNewGC 打开。即:ParNew(Young 区)+CMS(Old 区)+Serial Old(Old 区备选方案)的组合。

-XX:+CMSInitiatingOccupanyFraction:设置堆内存使用率的阈值,一旦达到该阈值,便开始进行回收。

1、 JDK5 及以前版本的默认值为 68,即当老年代的空间使用率达到 68%时,会执行一次 CMS 回收 JDK6 及以上版本默认值为 92%;
2、 如果内存增长缓慢,则可以设置一个稍大的值,大的阀值可以有效降低 CMS 的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能;
3、 反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器因此通过该选项便可以有效降低 FullGC 的执行次数;

-XX:+UseCMSCompactAtFullCollection:用于指定在执行完 Full GC 后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了。 (CMS GC 会因为碎片过多,无法存放大对象而执行 Full GC)

-XX:CMSFullGCsBeforeCompaction:如果上面的参数开启, 这个指令就是设置在执行多少次 Full GC 后对内存空间进行压缩整理。 如果设置为 0,则每次 Full GC 时都会进行压缩整理

-XX:ParallelCMSThreads:设置 CMS 的线程数量。

1、 CMS 默认启动的线程数是(ParallelGCThreads+3)/4,ParallelGCThreads 是年轻代并行收集器的线程数,也就是与之配合的 ParNewGC 并行收集器的线程数,绝大多数情况都是 CPU 最大支持的线程数;
2、 当 CPU 资源比较紧张时,受到 CMS 收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕;

JDK 后续版本中 CMS 的变化

JDK9 新特性:CMS 被标记为 Deprecate 了(JEP291)

  • 如果对 JDK9 及以上版本的 HotSpot 虚拟机使用参数-XX:+UseConcMarkSweepGC 来开启 CMS 收集器的话,用户会收到一个警告信息,提示 CMS 未来将会被废弃。

JDK14 新特性:删除 CMS 垃圾回收器(JEP363)移除了 CMS 垃圾收集器,

  • 如果在 JDK14 中使用 XX:+UseConcMarkSweepGC 的话,JVM 不会报错,只是给出一个 warning 信息,但是不会 exit。JVM 会自动回退以默认 GC 方式启动 JVM

3.5 小结

上面我们已经介绍了 年轻代,老年代的各个比较经典也比较古老的几个垃圾回收器, 对于不同的需要,我们应该怎么搭配呢

1、 如果你想要最小化地使用内存和并行开销,请选 SerialGC/SerialOldGC;单线程串行执行,;
2、 如果你想要最大化应用程序的吞吐量,请选 ParallelGC/ParallelOldGC;并行回收,自适应调节,吞吐量优先;
3、 如果你想要最小化 GC 的中断或停顿时间,请选 CMSGC/ParNewGC 并发回收,用户线程 GC 线程交替执行,低延迟;

4. G1 回收器:区域化分代式

4.1 G1 回收器的概述

为什么前面已经有了那么多的 GC ,并且在相应的场景下,都有比较好的配合使用, 还要发布Garbage First(G1)GC?

因为时代在变化, 应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有 GC 就不能保证应用程序正常进行,而经常造成 STW 的 GC 又跟不上实际的需求,所以才会不断地尝试对 GC 进行优化。 与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。(现在硬件条件这么好,不去使用不浪费了吗)

G1(Garbage-First)垃圾回收器是在 Java7 update4 之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一。官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。

G1 名字的含义

1、 因为 G1 是一个并行回收器,它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)使用若干个不同的 Region 就可以拼接成完整的 Eden、幸存者 0 区,幸存者 1 区,老年代等;
2、 G1GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集 G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的综合考量),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region;
3、 由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给 G1 一个名字:垃圾优先(GarbageFirst);
4、 G1(Garbage-First)是一款面向服务端应用的垃圾收集器,主要针对配备多核 CPU 及大容量内存的机器,以极高概率满足 GC 停顿时间的同时,还兼具高吞吐量的性能特征;
5、 在 JDK1.7 版本正式启用,移除了 Experimental 的标识,是 JDK9 以后的默认垃圾回收器,取代了 CMS 回收器以及 Parallel+ParallelOld 组合被 Oracle 官方称为“全功能的垃圾收集器”;
6、 与此同时,CMS 已经在 JDK9 中被标记为废弃(deprecated)G1 在 JDK8 中还不是默认的垃圾回收器,需要使用**-XX:+UseG1GC**来启用;

4.2 G1 回收器的优势和缺点

与其他 GC 收集器相比,G1 使用了全新的分区算法,其特点如下所示:

高吞吐与低延迟兼具 :

  • 高吞吐:G1 在回收期间,可以有多个 GC 线程同时工作,有效利用多核计算能力。此时用户线程 STW
  • 低延迟:G1 拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况

分代收集:

  • 从分代上看,G1 依然属于分代型垃圾回收器,它会区分年轻代和老年代,针对不同的代,仍然使用不同的回收策略. 年轻代依然有 Eden 区和 Survivor 区。但从堆的结构上看,它不要求整个 Eden 区、年轻代或者老年代都是连续的,也不再坚持固定大小和固定数量。
  • 将堆空间分为若干个区域(Region),这些区域中包含了逻辑上的年轻代和老年代
  • 和之前的各类回收器不同,因为它将堆空间分割为不同的区域, 每个区域也都可能时而为老年代,时而为新生代,所以可以说它同时兼顾年轻代和老年代。对比其他回收器,或者工作在年轻代,或者工作在老年代;

G1 的分代,已经不是下面这样的了

 
 

而是使用如下一片区域: 这是 G1 的核心

 
 

G1 的空间整合压缩

1、 CMS 使用的是“标记-清除”算法会产生内存碎片,再依靠 FullGC 后的压缩进行一次碎片整理;
2、 G1 将内存划分为一个个的 region 内存的回收是以 region 作为基本单位的Region 之间是复制算法,所以整体上实际可看作是标记-压缩(Mark-Compact)算法,两种算法都可以避免内存碎片;
3、 这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC 尤其是当 Java 堆非常大的时候,G1 的优势更加明显;

可预测的停顿时间模型:

这是 G1 相对于 CMS 的另一大优势,G1 除了追求低延迟外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内,消耗在垃圾收集上的时间不得超过 N 毫秒。

1、 由于分区的原因,G1 可以只选取部分区域进行内存回收,这样缩小了回收的范围,因此对于全局停顿情况的发生也能得到较好的控制;
2、 G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的综合考量),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region 保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率;
3、 相比于 CMSGC,G1 未必能做到 CMS 在最好情况下的延时停顿,但是最差情况要好很多;

G1 回收器的缺点:

1、 相较于 CMS,G1 还不具备全方位、压倒性优势比如在用户程序运行过程中,G1 无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(overload)都要比 CMS 要高;
2、 从总体来说,在小内存应用上 CMS 的表现大概率会优于 G1,而 G1 在大内存应用上则发挥其优势平衡点在 6-8GB 之间;

4.3 G1 回收器的常用参数

-XX:+UseG1GC:手动指定使用 G1 垃圾收集器执行内存回收任务,JDK9 之后默认就是

-XX:G1HeapRegionSize:设置每个 Region 的大小。值是 2 的幂,范围是 1MB 到 32MB 之间(也就是可以设置为 1,2,4,8,16,32),默认是根据最小的 Java 堆大小划分出约 2048 个区域。也就是堆内存的 1/2000。例如堆内存为 2G,则默认为 1, 2048/2048

-XX:MaxGCPauseMillis:设置期望达到的最大 GC 停顿时间指标 JVM 会尽力实现,但不保证达到。默认值是 200ms

-XX:+ParallelGCThread:设置 G1 回收器 STW 并行阶段时工作线程数的值。最多设置为 8

-XX:ConcGCThreads:设置并发标记的线程数。将 n 设置为并行垃圾回收线程数(ParallelGcThreads)的 1/4 左右。

-XX:InitiatingHeapOccupancyPercent:设置触发并发 GC 周期的 Java 堆占用率阈值。超过此值,就触发 GC。默认值是 45。

注意:

G1 的设计原则就是为了简化 JVM 性能调优,开发人员只需要简单的三步即可完成调优:

1、 第一步:开启 G1 垃圾收集器;
2、 第二步:设置堆的最大内存;
3、 第三步:设置最大的停顿时间;

G1 中提供了三种垃圾回收模式:YoungGC、Mixed GC 和 Full GC 在不同的条件下被触发。

4.4 G1 的适用场景

1、 面向服务端应用,针对具有大内存、多处理器的机器(在普通大小的堆里表现并不惊喜);
2、 最主要的应用是需要低 GC 延迟,并具有大堆的应用程序提供解决方案;
3、 如:在堆大小约 6GB 或更大时,可预测的暂停时间可以低于 0.5 秒;(G1 通过每次只清理一部分而不是全部的 Region 的增量式清理来保证每次 GC 停顿时间不会过长);
4、 用来替换掉 JDK1.5 中的 CMS 收集器;在下面的情况时,使用 G1 可能比 CMS 好:;

  • 超过 50%的 Java 堆被活动数据占用;
  • 对象分配频率或年代提升频率变化很大;
  • GC 停顿时间过长(长于 0.5 至 1 秒) 5、 HotSpot 垃圾收集器里,除了 G1 以外,其他的垃圾收集器均使用内置的 JVMGC 线程执行 GC 的多线程操作,而 G1GC 可以采用应用线程承担后台运行的 GC 工作,即当 JVM 的 GC 线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程;

4.5 分区 Region

1、 使用 G1 收集器时,它将整个 Java 堆划分成约 2048 个大小相同的独立 Region 块,每个 Region 块大小根据堆空间的实际大小而定,整体被控制在 1MB 到 32MB 之间,且为 2 的 N 次幂,即 1MB,2MB,4MB,8MB,16MB,32MB 可以通过 XX:G1HeapRegionSize 设定所有的 Region 大小相同,且在 JVM 生命周期内不会被改变;
2、 虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分 Region(不需要连续)的集合通过 Region 的动态分配方式实现逻辑上的连续;
3、 一个 Region 有可能属于 Eden,Survivor 或者 Old/Tenured 内存区域**(当一个 Region 被回收干净时,会放入空闲列表维护,若下次取用时,它代表的角色随意**)但是一个 Region 在同一时刻只可能属于一个角色图中的 E 表示该 Region 属于 Eden 内存区域,S 表示属于 Survivor 内存区域,O 表示属于 Old 内存区域图中空白的表示未使用的内存空间;
4、 G1 垃圾收集器还增加了一种新的内存区域,叫做 Humongous 内存区域,如图中的 H 块主要用于存储大对象,如果超过 1.5 个 Region,就放到 H若一个对象在一个 Region 放不下时,若大小没有超过 1.5 倍的 Region,则可以使用两个并列的 Eden 或 Old 区等去存储,若超过 1.5 倍,则需要使用 G1 中专有的 humongous 区存储大对象,若一个 humongous 也存不下,则可以使用多个 humongous 并列存储

 
 

设置 H 的原因

1、 对于堆中的大对象,默认直接会被分配到老年代,但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响;
2、 为了解决这个问题,G1 划分了一个 Humongous 区,它用来专门存放大对象;
3、 如果一个 H 区装不下一个大对象,那么 G1 会寻找连续的 H 区来存储为了能找到连续的 H 区,有时候不得不启动 FullGCG1 的大多数行为都把 H 区作为老年代的一部分来看待

Regio 的内部使用的内存分配算法

1、 每个 Region 都是通过指针碰撞来分配空间;
2、 每个 Region 都有 TLAB(线程独占内存),提高对象分配的效率;

 
 

4.6 G1 回收器的主要环节

G1GC 的垃圾回收过程主要包括如下三个环节:

  • 年轻代 GC(Young GC)
  • 老年代并发标记过程(Concurrent Marking)
  • 混合回收(Mixed GC)
  • 如果需要,单线程、独占式、高强度的 Full GC 还是继续存在的。它针对 GC 的评估失败提供了一种失败保护机制,即强力回收.

Young GC --> Young GC+Concurrent Marking --> Mixed GC 顺序,进行垃圾回收

 
 

大致的回收流程

1、 应用程序分配内存,当年轻代的 Eden 区用尽时开始年轻代回收过程;G1 的年轻代收集阶段是一个并行的独占式收集器(STW);
2、 在年轻代回收期,G1GC 暂停所有应用程序线程,启动多线程执行年轻代回收然后从年轻代区间移动存活对象到 Survivor 区间或者老年区间,也有可能是两个区间都会涉及;
3、 当堆内存使用达到一定值(默认 45%)时,开始老年代并发标记过程标记完成马上开始混合回收过程;
4、 对于一个混合回收期,G1GC 从老年区间移动存活对象到空闲区间,这些空闲区间也就成为了老年代的一部分;
5、 老年代的 G1 回收器和其他 GC 不同,G1 的老年代回收器不需要整个老年代被回收,一次只需要扫描/回收一小部分老年代的 Region 就可以了同时,这个老年代 Region 是和年轻代一起被回收的

举个例子:一个 Web 服务器,Java 进程最大堆内存为 4G,每分钟响应 1500 个请求,每 45 秒钟会新分配大约 2G 的内存。G1 会每 45 秒钟进行一次年轻代回收, 每 31 个小时整个堆的使用率会达到 45%(当老年代的空间也不足时),会开始老年代并发标记过程,标记完成后开始四到五次的混合回收。

4.7 Remember Set 记忆集

根据前面所说的 G1 的回收特性, 其实存在一些问题.例如

  • 一个对象被不同区域引用的问题 ,一个 Region 不可能是孤立的,一个 Region 中的对象可能被其他任意 Region 中对象引用,判断对象存活时,是否需要扫描整个 Java 堆才能保证准确? (在其他的分代收集器,也存在这样的问题, 而 G1 更突出,因为 G1 主要针对大堆)
  • 回收新生代也不得不同时扫描老年代(枚举 GC Roots,要检查新生代之外,包括老年代)?这样的话会降低 Minor GC 的效率

解决方法:

1、 无论 G1 还是其他分代收集器,JVM 都是使用 RememberedSet 来避免全局扫描;
2、 每个 Region 都有一个对应的 RememberedSet,每个 RSet 都记录着本 Region 中对象被其他区域引用的记录,若此时需要回收此 Region,则不用扫描全部其他 Region,只需查看 RSet 中的记录即可;
3、 每次 Reference 类型数据写操作时,都会产生一个 WriteBarrier(写屏障)暂时中断操作;然后检查将要写入的对象是否和该对象引用的对象(Reference 类型)数据在不同的 Region(其他收集器:检查老年代对象是否引用了新生代对象);
4、 如果不同,通过 CardTable 把相关引用信息记录到引用指向对象(被指向的对象)的所在 Region 对应的 RememberedSet 中;(如果相同则无需此操作,因为都在一个区域了,扫描本区域时,就已经扫描出来了);
5、 当进行垃圾收集时,在 GC 根节点的枚举范围加入 RememberedSet;就可以保证不进行全局扫描,也不会有遗漏;

 
 

总结

1、 在回收 Region 时,为了不进行全堆的扫描,引入了 RememberedSet;
2、 RememberedSet 记录了当前 Region 中的对象被哪个对象引用了;
3、 这样在进行 Region 复制时,就不要扫描整个堆,只需要去 RememberedSet 里面找到引用了当前 Region 的对象;
4、 Region 复制完毕后,修改 RememberedSet 中对象的引用即可;

4.8 G1 回收每个阶段的具体说明

前面说到,G1 回收共可分成三个阶段,即 年轻代回收, 并发标记阶段,混合回收,下面进行具体说明

年轻代回收

1、 JVM 启动时,G1 先准备好 Eden 区,程序在运行过程中不断创建对象到 Eden 区,当 Eden 空间耗尽时,G1 会启动一次年轻代垃圾回收过程;
2、 YGC 时,首先 G1 停止应用程序的执行(Stop-The-World),G1 创建回收集(CollectionSet),回收集是指需要被回收的内存分段的集合,年轻代回收过程的回收集包含年轻代 Eden 区和 Survivor 区所有的内存分段(年轻代是所有的 Region)

如下示意图, 和普通的 GC 类似,再回收年轻代时, 将会把 Eden 和 Survivor from 区中判断存活的对象存放拷贝到 Survivor to 区, 即图中的空白区域

 
 

整个回收年轻代,共可分成如下几个部分:

1、 第一阶段,扫描根(GCRoots);

  • 根是指 static 变量指向的对象或正在执行的方法调用链条上的局部变量等包括根引用连同 RSet 记录的外部引用作为扫描存活对象的入口。 2、 第二阶段,更新 RSet;

  • 处理 dirty card queue 中的 card,更新 RSet。前面说到, 在分配对象到一个 Region 时,会将此对象引用的对象所在的 Region 所对应的 RSet 中添加 引用相关信息, 但为了分配内存时的效率,这个操作不是同步的, 而是将记录加入到 dirty card queue 中, 只要在回收此 Region 时,需要枚举 GC Roots 时,才会将此队列中的信息同步到 对应的 RSet 中, 再进行判断

  • 此阶段完成后,RSet 可以准确的反映老年代对所在的内存分段中对象的引用。 3、 第三阶段,处理 RSet;

  • 识别被老年代对象指向的 Eden 中的对象(年轻代外的地方,回收年轻代时,堆中只有老年代配当 GC Roots),这些被指向的 Eden 中的对象被认为是存活的对象。 4、 第四阶段,复制对象;

  • 此阶段,对象树被遍历,Eden 区内存段中存活的对象会被复制到 Survivor 区中空的内存分段,Survivor 区内存段中存活的对象会根据年龄不同判断

  • 如果年龄未达阈值,年龄会加 1,达到阀值会被会被复制到 Old 区中空的内存分段。

  • 如果 Survivor 空间不够,Eden 空间的部分数据会直接晋升到老年代空间。 5、 第五阶段,处理引用;

  • 处理 Soft,Weak,Phantom,Final,JNI Weak 等引用。最终 Eden 空间的数据为空,GC 停止工作,而目标内存中的对象都是连续存储的,没有碎片,所以复制过程可以达到内存整理的效果,减少碎片。

并发标记

在回收老年代的 混合回收前,会进行并发标记阶段,共可分成如下几步

1、 初始标记阶段:;

  • 标记从根节点直接可达的对象。这个阶段是 STW 的,并且会触发一次年轻代 GC。

  • 正是由于该阶段时 STW 的,所以我们只扫描根节点可达的对象,以节省时间。 2、 根区域扫描(RootRegionScanning):;

  • G1 GC 扫描 Survivor 区直接可达的老年代区域对象,并标记被引用的对象。

  • 这一过程必须在 Young GC 之前完成,因为 Young GC 会使用复制算法对 Survivor 区进行 GC。 3、 并发标记(ConcurrentMarking):;

1、 在整个堆中进行并发标记(和应用程序并发执行),此过程可能被 YoungGC 中断;
2、 在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那这个区域会被立即回收;
3、 同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例);
4、 再次标记(Remark):;

  • 由于应用程序持续进行,需要修正上一次的标记结果。是 STW 的。

  • G1 中采用了比 CMS 更快的初始快照算法:Snapshot-At-The-Beginning(SATB)。 5、 独占清理(cleanup,STW):;

  • 计算各个区域的存活对象和 GC 回收比例,并进行排序,识别可以混合回收的区域。

  • 为下阶 铺垫。是 STW 的。这个阶段并不会实际上去做垃圾的收集 6、 并发清理阶段:;

  • 识别并清理完全空闲的区域。

混合回收

当越来越多的对象晋升到老年代 Old Region 时,为了避免堆内存被耗尽,虚拟机会触发一个混合的垃圾收集器,即 Mixed GC,该算法并不是一个 Old GC,除了回收整个 Young Region,还会回收一部分的 Old Region。

这里需要注意:是一部分老年代,而不是全部老年代。可以选择价值较高的 Old Region 进行收集,从而可以对垃圾回收的耗时时间进行控制。也要注意的是 Mixed GC 并不是 Full GC。

 
 

混合回收的细节

1、 并发标记结束以后,老年代中百分百为垃圾的内存分段被回收了,部分为垃圾的内存分段被计算了出来;
2、 默认情况下,这些老年代的内存分段会分 8 次(可以通过-XX:G1MixedGCCountTarget 设置,8 个线程)被回收;
3、 混合回收的回收集(CollectionSet)包括八分之一的老年代内存分段,Eden 区内存分段,Survivor 区内存分段混合回收的算法和年轻代回收的算法完全一样,只是回收集多了老年代的内存分段具体过程请参考上面的年轻代回收过程;
4、 由于老年代中的内存分段默认分 8 次回收,G1 会优先回收垃圾多的内存分段垃圾占内存分段比例越高的,越会被先回收并且有一个阈值会决定内存分段是否被回收;
5、 XX:G1MixedGCLiveThresholdPercent,默认为 65%,意思是垃圾占内存分段比例要达到 65%才会被回收如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间;
6、 混合回收并不一定要进行 8 次有一个阈值-XX:G1HeapWastePercent,默认值为 10%,意思是允许整个堆内存中有 10%的空间被浪费,意味着如果发现可以回收的垃圾占堆内存的比例低于 10%,则不再进行混合回收因为 GC 会花费很多的时间但是回收到的内存却很少;

G1 回收器可能的过程四 Full GC

G1 的初衷就是要避免 Full GC 的出现。但是如果上述方式不能正常工作,G1 会停止应用程序的执行(Stop-The-World),使用单线程的内存回收算法进行垃圾回收,性能会非常差,应用程序停顿时间会很长。

要避免 Full GC 的发生,一旦发生 Full GC,需要对 JVM 参数进行调整。什么时候会发生 Ful1GC 呢?比如堆内存太小,当 G1 在复制存活对象的时候没有空的内存分段可用,则会回退到 Full GC,这种情况可以通过增大内存解决。

导致 G1 Full GC 的原因可能有两个:

1、 没有足够的空间来存放晋升的对象;
2、 并发处理过程完成之前空间耗尽;

4.9 补充说明

从 Oracle 官方透露出来的信息可获知,回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行,但这件事情做起来比较复杂,考虑到 G1 只是回一部分 Region,停顿时间是用户可控制的,所以并不迫切去实现,而选择把这个特性放到了 G1 之后出现的低延迟垃圾收集器(即 ZGC)中。

另外,还考虑到 G1 不是仅仅面向低延迟,停顿用户线程能够最大幅度提高垃圾收集效率,为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。

G1 回收器的优化建议

年轻代大小

  • 避免使用-Xmn 或-XX:NewRatio 等相关选项显式设置年轻代大小,让 G1 自己调节
  • 固定年轻代的大小会覆盖暂停时间目标

暂停时间目标不要太过严苛

  • G1 GC 的吞吐量目标是 90%的应用程序时间和 10%的垃圾回收时间
  • 评估 G1 GC 的吞吐量时,暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销,而这些会直接影响到吞吐量。频繁回收

5. 垃圾回收器的总结

截止 JDK1.8,一共有 7 款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点,在具体使用的时候,需要根据具体的情况选用不同的垃圾收集器。

 
 

GC 发展阶段:Seria l=> Parallel(并行)=> CMS(并发)=> G1 => ZGC

不同厂商、不同版本的虚拟机实现差距比较大。HotSpot 虚拟机在 JDK7/8 后所有收集器及组合如下图(更新至 JDK14)

 
 

Java 垃圾收集器的配置对于 JVM 优化来说是一个很重要的选择,选择合适的垃圾收集器可以让 JVM 的性能有一个很大的提升。怎么选择垃圾收集器?

1、 优先调整堆的大小让 JVM 自适应完成;
2、 如果内存小于 100M,使用串行收集器;
3、 如果是单核、单机程序,并且没有停顿时间的要求,串行收集器;
4、 如果是多 CPU、需要高吞吐量、允许停顿时间超过 1 秒,选择并行或者 JVM 自己选择;
5、 如果是多 CPU、追求低停顿时间,需快速响应(比如延迟不能超过 1 秒,如互联网应用),使用并发收集器;
6、 官方推荐 G1,性能高现在互联网的项目,基本都是使用 G1;

最后需要明确一个观点:

1、 没有最好的收集器,更没有万能的收集算法;
2、 调优永远是针对特定场景、特定需求,不存在一劳永逸的收集器;

6. GC 日志分析

通过阅读 GC 日志,我们可以了解 Java 虚拟机内存分配与回收策略。

内存分配与垃圾回收的参数列表

1、 -XX:+PrintGC:输出 GC 日志类似:-verbose:gc;
2、 -XX:+PrintGCDetails:输出 GC 的详细日志;
3、 -XX:+PrintGCTimestamps:输出 GC 的时间戳(以基准时间的形式);
4、 -XX:+PrintGCDatestamps:输出 GC 的时间戳(以日期的形式,如 2013-05-04T21:53:59.234+0800);
5、 -XX:+PrintHeapAtGC:在进行 GC 的前后打印出堆的信息;
6、 -Xloggc:…/logs/gc.log:日志文件的输出路径;

6.1 常用参数

verbose:gc

JVM 参数:-verbose:gc

打印日志:

[GC (Allocation Failure)  15270K->14114K(58880K), 0.0698402 secs]
[GC (Allocation Failure)  29416K->29372K(58880K), 0.0081180 secs]
[Full GC (Ergonomics)  29372K->29248K(58880K), 0.0096768 secs]
[Full GC (Ergonomics)  44546K->44151K(58880K), 0.0075181 secs]

参数解析:

GC,Full GC : GC 的类型, GC 只在堆上进行,Full GC 包括方法区

Allocation Failure : GC 发生的原因

15270K->14114K : 堆在 GC 前的大小 和 GC 后的大小

58880K : 现在堆的空间大小

0、 0698402secs:GC 持续的时间.;

PrintGCDetails

JVM 参数: -XX:+PrintGCDetails

打印日志:

[GC (Allocation Failure) [PSYoungGen: 15270K->2548K(17920K)] 15270K->14146K(58880K), 0.0509164 secs] [Times: user=0.00 sys=0.00, real=0.05 secs]
[GC (Allocation Failure) [PSYoungGen: 17850K->2516K(17920K)] 29448K->29316K(58880K), 0.0077901 secs] [Times: user=0.00 sys=0.03, real=0.01 secs]
[Full GC (Ergonomics) [PSYoungGen: 2516K->0K(17920K)] [ParOldGen: 26800K->29248K(40960K)] 29316K->29248K(58880K), [Metaspace: 3440K->3440K(1056768K)], 0.0082566 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (Ergonomics) [PSYoungGen: 15298K->3400K(17920K)] [ParOldGen: 29248K->40750K(40960K)] 44546K->44151K(58880K), [Metaspace: 3440K->3440K(1056768K)], 0.0066315 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

参数解析:

GC,Full GC : GC 的类型

Allocation Failure : GC 发生的原因

PSYoungGen : 使用了 Parallel 垃圾回收器的新生代 GC 前后大小的变化

ParOldGen: 使用了 Parallel Old 垃圾回收器 回收老年代前后空间的变化

Metaspace : 元数据区 GC 前后大小的变化,

0、 0509164secs:GC 话费的时间;

Times:

  • user : 指的是垃圾回收器花费的所有 CPU 时间,
  • sys: 花费在等待系统调用或系统事件的时间
  • real: GC 从开始到结束的时间,包括其他进程占用时间片的实际时间

图例:

下图是一次 GC 打印的日志对应的信息

 
 

下图是一次 Full GC 打印的日志对应的信息

 
 

PrintGCTimestamps 和 PrintGCDatestamps

JVM 参数: -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

打印日志:

2020-11-29T21:42:44.039+0800: 7.018: [GC (Allocation Failure) [PSYoungGen: 15270K->2548K(17920K)] 15270K->14114K(58880K), 0.0407744 secs] [Times: user=0.00 sys=0.00, real=0.04 secs]
2020-11-29T21:42:51.803+0800: 14.746: [GC (Allocation Failure) [PSYoungGen: 17850K->2536K(17920K)] 29416K->29340K(58880K), 0.0048071 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
2020-11-29T21:42:51.808+0800: 14.751: [Full GC (Ergonomics) [PSYoungGen: 2536K->0K(17920K)] [ParOldGen: 26804K->29248K(40960K)] 29340K->29248K(58880K), [Metaspace: 3440K->3440K(1056768K)], 0.0080173 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
2020-11-29T21:42:59.420+0800: 22.363: [Full GC (Ergonomics) [PSYoungGen: 15298K->3400K(17920K)] [ParOldGen: 29248K->40750K(40960K)] 44546K->44151K(58880K), [Metaspace: 3440K->3440K(1056768K)], 0.0065238 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

就是在 GC 前面加上了 日期时间 和 距离虚拟机启动时的时间

保存日志文件

JVM 参数: -XLoggc:./Logs/gc.Log

./表示当前目录,在 IDEA 中程序运行的当前目录是工程的根目录,而不是模块的根目录

补充说明:

1、 “[GC"和”[FullGC"说明了这次垃圾收集的停顿类型,如果有"Full"则说明 GC 发生了"StopTheWorld";
2、 使用 Serial 收集器在新生代的名字是 DefaultNewGeneration,因此显示的是"[DefNew";
3、 使用 ParNew 收集器在新生代的名字会变成"[ParNew",意思是"ParallelNewGeneration";
4、 使用 Parallelscavenge 收集器在新生代的名字是”[PSYoungGen";
5、 老年代的收集和新生代道理一样,名字也是收集器决定的;
6、 使用 G1 收集器的话,会显示为"garbage-firstheap";
7、 AllocationFailure 表明本次引起 GC 的原因是因为在年轻代中没有足够的空间能够存储新的数据了;
8、 [PSYoungGen:5986K->696K(8704K)]5986K->704K(9216K);

  • 中括号内:GC 回收前年轻代大小,回收后大小,(年轻代总大小)
  • 括号外:GC 回收前年轻代和老年代大小,回收后大小,(年轻代和老年代总大小) 9、 user 代表用户态回收耗时,sys 内核态回收耗时,real 实际耗时由于多核线程切换的原因,时间总和可能会超过 real 时间;

6.2 堆空间的使用情况

代码:

public class GCLogTest1 {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;
        allocation1 = new byte[2 * _1MB];
        allocation2 = new byte[2 * _1MB];
        allocation3 = new byte[2 * _1MB];
        allocation4 = new byte[4 * _1MB];
    }

    public static void main(String[] agrs) {
        testAllocation();
    }
}

JVM 参数: -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC

其中-XX:+PrintGCDetails 除了打印 GC 日志信息外,还将打印 Heap 的内存占用情况,

JDK 7:

 
 

在 jdk7 中,当发现最后分配 4M 的数据放不下 Eden 区时,将触发年轻代 GC, 然后将三个 2M 的数组放到了 老年代,

所以如图所示, 年轻代占用 4867k,4M 内存,老年代占用 6144K ,6M 内存

示意图:

 
 

JKD8:

 
 

如图所示,在 JDK 8 中,很明显 最后分配的 4M 大对象直接放到了老年代

6.3 日志分析工具

在实际生产环境中,GC 日志信息可能非常庞大,可以使用命令导出到文件中, 再用一些工具去分析这些 GC 日志,常用的日志分析工具有:

GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat 等

这里主要推荐 GCViewer、GCEasy,

GCViewer: 网上下载 jar 包 双击打开即可

 
 

GCeasy: 在线分析 https://gceasy.io/open in new window

 
 

7. 垃圾回收器的新发展

回首过去

1、 GC 仍然处于飞速发展之中,目前的默认选项 G1GC 在不断的进行改进,很多我们原来认为的缺点,例如串行的 FullGC、CardTable 扫描的低效等,都已经被大幅改进,例如,JDK10 以后,Fu11GC 已经是并行运行,在很多场景下,其表现还略优于 ParallelGC 的并行 Ful1GC 实现;
2、 即使是 SerialGC,虽然比较古老,但是简单的设计和实现未必就是过时的,它本身的开销,不管是 GC 相关数据结构的开销,还是线程的开销,都是非常小的,所以随着云计算的兴起,在 serverless 等新的应用场景下,SerialGc 找到了新的舞台;
3、 比较不幸的是 CMSGC,因为其算法的理论缺陷等原因,虽然现在还有非常大的用户群体,但在 JDK9 中已经被标记为废弃,并在 JDK14 版本中移除;

展望未来

1、 Epsilon:ANo-OpGarbageCollector(Epsilon 垃圾回收器,"No-Op(无操作)"回收器),只执行分配,不执行回收,http://openidk.iava.net/ieps/318open in new window
2、 ZGC:AScalableLow-LatencyGarbageCollector(Experimental)(ZGC:可伸缩的低延迟垃圾回收器,处于实验性阶段);
3、 现在 G1 回收器已成为默认回收器好几年了我们还看到了引入了两个新的收集器:ZGC(JDK11 出现)和 Shenandoah(OpenJDK12),其特点:主打低停顿时间;

7.1 Shenandoah GC

Open JDK12 的 Shenandoash GC:低停顿时间的 GC(实验性)

1、 Shenandoah 无疑是众多 GC 中最孤独的一个是第一款不由 Oracle 公司团队领导开发的 Hotspot 垃圾收集器不可避免的受到官方的排挤比如号称 openJDK 和 OracleJDK 没有区别的 Oracle 公司仍拒绝在 OracleJDK12 中支持 Shenandoah;
2、 Shenandoah 垃圾回收器最初由 RedHat 进行的一项垃圾收集器研究项目 PauselessGC 的实现,旨在针对 JVM 上的内存回收实现低停顿的需求在 2014 年贡献给 OpenJDK;
3、 RedHat 研发 Shenandoah 团队对外宣称,Shenandoah 垃圾回收器的暂停时间与堆大小无关,这意味着无论将堆设置为 200MB 还是 200GB,99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内不过实际使用性能将取决于实际工作堆的大小和工作负载;

这是 RedHat 在 2016 年发表的论文数据,测试内容是使用 ES 对 200GB 的维基百科数据进行索引。从结果看:

1、 停顿时间比其他几款收集器确实有了质的飞跃,但也未实现最大停顿时间控制在十毫秒以内的目标;
2、 而吞吐量方面出现了明显的下降,总运行时间是所有测试收集器里最长的;

 
 

总结

1、 ShenandoahGC 的弱项:高运行负担下的吞吐量下降;
2、 ShenandoahGC 的强项:低延迟时间;

7.2 次时代 ZGC

1、 官方文档:https://docs.oracle.com/en/java/javase/12/gctuning/open in new window
2、 ZGC 与 Shenandoah 目标高度相似,在尽可能对吞吐量影响不大的前提下,实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟;
3、 《深入理解 Java 虚拟机》一书中这样定义 ZGC:ZGC 收集器是一款基于 Region 内存布局的,(暂时)不设分代的,使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的,以低延迟为首要目标的一款垃圾收集器;
4、 ZGC 的工作过程可以分为 4 个阶段:并发标记-并发预备重分配-并发重分配-并发重映射等;
5、 ZGC 几乎在所有地方并发执行的,除了初始标记的是 STW 的所以停顿时间几乎就耗费在初始标记上,这部分的实际时间是非常少的;

下面是官方对比其他 GC 的数据

吞吐量

 
 

暂停时间

 
 

未来将在服务端、大内存、低延迟应用的首选垃圾收集器。

JDK14 新特性

1、 JDK14 之前,ZGC 仅 Linux 才支持;
2、 尽管许多使用 ZGC 的用户都使用类 Linux 的环境,但在 Windows 和 macOS 上,人们也需要 ZGC 进行开发部署和测试许多桌面应用也可以从 ZGC 中受益因此,ZGC 特性被移植到了 Windows 和 macOS 上;
3、 现在 mac 或 Windows 上也能使用 ZGC 了,示例如下:;

-XX:+UnlockExperimentalVMOptions-XX+UseZGC

7.3 其他厂商的 GC

例如 AliGC:

AliGC 是阿里巴巴 JVM 团队基于 G1 算法,面向大堆(LargeHeap)应用场景。指定场景下的对比:

 
 

还有比较有名的低延迟 GC : Zing, 有兴趣的可以自己了解一下

上次编辑于:
贡献者: Andy