15_垃圾回收器

[TOC]

GC分类

垃圾收集器没有在规范中进行过多的规定,可以由不同的厂商、不同版本的JVM来实现。由于JDK的版本处于高速迭代过程中,因此Java发展至今已经衍生了众多的GC版本。

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

¶垃圾回收器分类

¶按垃圾回收器的线程数分

可以分为串行垃圾回收器(单线程处理)和并行垃圾回收器(多线程处理)

• 串行回收指的是在同一时间段内只有一个CPU用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束。

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

• 和串行回收相反,并行收集可以运用多个CPU同时执行垃圾回收,因此提升了应用的吞吐量。

不过这里仅仅是根据回收器的工作线程是并行还是串行的维度来进行分类, 并没有针对是否采用独占式,使用了“stop-the-world”机制维度进行分类。

¶按照工作模式分

可以分为并发式(与应用线程)垃圾回收器和独占式垃圾回收器。并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间。独占式垃圾回收器(Stop The World)一旦运行,就停止应用程序中的所有用户线程,直到垃圾回收过程完全结束。

¶按碎片处理方式分

可分为压缩式垃圾回收器和非压缩式垃圾回收器。

• 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片。
• 非压缩式的垃圾回收器不进行这步操作。

¶按工作的内存区间分

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

GC性能指标

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

暂停时间、吞吐量和内存占用这三者共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。这三项里,暂停时间的重要性日益凸显。因为随着硬件发展,内存占用多些越来越能容忍,硬件性能的提升也有助于降低收集器运行时对应用程序的影响,即提高了吞吐量。而内的扩大,对延迟反而带来负面效果。
简单来说,主要抓住两点:

• 吞吐量
• 暂停时间

¶吞吐量(throughPUT)

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即：

吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。(例如：虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%)

高吞吐量的应用程序有更长的时间基准(即不以单次的响应时长为基准，而是以某单位内总响应时长为基准)，快速响应是不必考虑的，应用程序能容忍较高的暂停时间。

吞吐量优先,意味着在单位(基准)时间内,STW的时间之和最短:0.2+0.2=0.4

¶暂停时间(pause time)

“暂停时间”是指用户线程被全部暂停以让垃圾回收工作线程执行的期间。例如,GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。

暂停时间优先,意味着尽可能让单次STW的时间最短:0.1+0.1+0.1+0.1+0.1=0.5

¶对比

• 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上,吞吐量越高程序运行越快。

• 低暂停时间(低延迟)较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型,有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此,具有低的较大暂停时间是非常重要的,特别是对于一个交互式应用程序。

不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标(矛盾)。

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

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

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

不同的垃圾回收器概述

有了虚拟机,就一定需要收集垃圾的机制这就是Garbage Collection,对应的产品我们称为 Garbage Collector。

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

¶7款经典的垃圾回收器的工作线程数

• 串行回收器：Serial、Serial Old
  • STW+只有一个垃圾回收线程工作
• 并行回收器：ParNew、Parallel Scavenge、Parallel Old
  • STW+垃圾回收工作线程并行工作
• 并发回收器：CMS、G1
  • 与用户线程并行执行

HotSpot虚拟机内存管理白皮书

¶图示并行、并发、分区

¶7款经典收集器与垃圾分代

• 新生代收集器：Serial、ParNew、Parallel Scavenge
• 老年代收集器：Serial Old、Parallel Old、CMS
• 整堆收集器：G1

¶垃圾回收器组合

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

   Serial/Serial Old、 Serial/CMS、 ParNew/Serial Old、 ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1；

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

3. (红色虚线)由于维护和兼容性测试的成本,在JDK8时将 Serial+CMS、ParNew+Serial Old这两个组合声明为废弃(JEP173),并在JDK9中完全取消了这些组合的支持(JEP214),即: 移除。

4. (绿色虚线)JDK14中:弃用 Parallel Scavenge和Serial Old组合(JEP366)

5. (青色虚线)JDK14中:删除CMS垃圾回收器(JEP363)

¶概述

为什么要有很多收集器,一个不够吗?因为ava的使用场景很多,移动端,服务器等。所以就需要针对不同的场景,提供不同的垃圾收集器,提高垃圾收集的性能。

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

¶如何查看默认的垃圾回收器

• -XX:+/-PrintCommandLineFlags：程序运行打印命令行相关参数（包含使用的垃圾收集器）

• 使用命令行指令：jinfo -flag 相关垃圾回收参数 进程ID

  

Serial回收器：串行回收

Seria收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。Serial收集器作为HotSpot中 client模式 下的默认新生代垃圾收集器。

Serial收集器采用复制算法、串行回收和"Stop-The-World"机制的方式执行内存回收。

除了年轻代之外, Serial收集器还提供用于执行老年代垃圾收集的 Serial Old收集器。 Serial Old收集器同样也采用了串行回收和"Stop the World"机制,只不过内存回收算法使用的是标记-压缩算法。

• Serial Old是运行在client模式下默认的老年代的垃圾回收器
• Serial Old在Server模式下主要有两个用途:
  1. 与新生代的 Parallel Scavenge配合使用
  2. 作为老年代CMS收集器的后备垃圾收集方案

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

¶优势

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

在用户的桌面应用场景中,可用内存一般不大(几十MB至一两百MB),可以在较短时间内完成垃圾收集(几十ms至一百多ms),只要不频繁发生,使用串行回收器是可以接受的。

¶使用参数

在 HotSpot虚拟机中,使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。表示新生代用Serial GC,且老年代用 Serial Old GC（没有专门指定使用Serial Old GC的选项）。

¶总结

现在已经不用串行了，而且在限定单核cpu才可以用，现在都不是单核的了。对于交互较强的应用而言，这种垃圾收集器是不能接收的。一般在Java Web应用程序中是不会采用串行垃圾收集器的。

ParNew回收器：并行回收

如果说 SerialGC是年轻代中的单线程垃圾收集器,那么 ParNew收集器则是 Serial 收集器的多线程版本。

• Par是Parallel的缩写
• New:只能处理的是新生代

ParNew收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别。 ParNew收集器在年轻代中同样也是采用复制算法、"Stop-The-World"机制。

ParNew是很多JVM运行 Server在模式下新生代的默认垃圾收集器。

• 对于新生代，回收次数频繁，使用并行方式高效。
• 对于老年代，回收次数少，使用串行方式（默认情况使用Serial Old，可以指定使用CMS）节省资源(Switch Context)。

¶优势对比

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

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

除Serial外,目前只有 ParNew GC能与CMS收集器配合工作

¶使用参数

• 在程序中，开发人员可以通过选项-XX:+UseParNewGC手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代

  • 即如果已经指定了老年代收集器如CMS，则使用CMS，如果没有就默认使用Serial Old。

    因为在一开始只有Seiral收集器，它分为Serial新生代和Serial Old老年代两部分，后面发展出现了ParNew可以替代Serial的部分，但是老年代还是只能用Serial Old，再到后面出现了CMS，此时可以指定老年代为CMS。

• -XX:ParallelGCThreads限制线程数量，默认开启和CPU数量相同的线程数。

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收集器的组合，在Server模式下的内存回收性能很不错。在Java8中，默认是此垃圾收集器。

设置参数

• -XX:+UseParallelGC手动指定年轻代使用 Parallel 并行收集器执行内存回收任务。
• -XX:+UseParallelOldGC手动指定老年代都是使用并行回收收集器。
  • 分别适用于新生代和老年代。默认jdk8是开启的。
  • 上面两个参数,默认开启一个,另一个也会被开启。(互相激活)
  • 如果在设置其中一个参数的时候同时设置一个其他的收集器会报错。
• -XX: ParallelGCThreads=<N>设置年轻代并行收集器的线程数。一般地,最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能。
  • 在默认情况下,当CPU数量小于8个,ParallelGCThreads的值等于CPU数量。
  • 当CPU数量大于8个, ParallelGCThreads的值等于 3+[5*CPU_COUNT]/8]。
• -XX:MaxGCPauseMillis=<N>设置垃圾收集器最大停顿时间(即STW的时间)。单位是毫秒。
  • 为了尽可能地把停顿时间控制在MaxGCPauseMillis以内,收集器在工作时会调整Java堆大小或者其他一些参数。
  • 对于用户来讲,停顿时间越短体验越好；但是在服务器端,我们注重高并发,整体的吞吐量。所以服务器端适合 Parallel,进行控制。
  • 该参数使用需谨慎。
• -XX:GCTimeRatio=<N>垃圾收集时间占总时间的比例(=1/(N+1))。用于衡量吞吐量的大小。
  • 取值范围(0,100)。默认值99,也就是垃圾回收时间不超过1%。
  • 与前一个-XX: MaxGCPauseMillis参数有一定矛盾性。暂停时间越长, Radio参数就容易超过设定的比例。
• -XX:+UseAdaptiveSizePolicy设置 Parallel Scavenge收集器具有自适应调节策略
  • 在这种模式下,年轻代的大小、Eden和 Survivor的比例、晋升老年代的对象年龄等参数会被自动调整,以达到在堆大小、吞吐量和停顿时间之间的平衡点。
  • 在手动调优比较困难的场合,可以直接使用这种自适应的方式, 仅指定虚拟机的最大堆-Xmx、目标的吞吐量(GCTimeRatio)和停顿时间(MaxGCPauseMillis),让虚拟机自己完成调优工作。

CMS回收器：低延迟

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

CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。

• 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
• CMS的垃圾收集算法采用标记-清除算法,并且也会"Stop-The-World"。

不幸的是,CMS作为老年代的收集器,却无法与JDK1.4.0中已经存在的新生代收集器 Parallel Scavenge配合工作,所以在JDK1.5中使用CMS来收集老年代的时候,新生代只能选择 ParNew或者Serial收集器中的一个。

在G1出现之前,CMS使用还是非常广泛的。一直到今天,仍然有很多系统使用 CMS GC。

¶CMS工作阶段

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

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

尽管CMS收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行“Stop-The-World”机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要“Stop-The-World”,只是尽可能地缩短暂停时间。

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作,所以整体的回收是低停顿的。

另外,由于在垃圾收集阶段用户线程没有中断,所以在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用。因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要,就会出现一次**“Concurrent Mode Failure”**失败,这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。

¶CMS的标记清除算法

CMS收集器的垃圾收集算法采用的是标记清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片。那么CMS在为新对象分配内存空间时,将无法使用指针碰撞(Bump the Pointer)技术,而只能够选择空闲列表(Free List)执行内存分配。

¶为什么不用标记整理算法

因为CMS追求短延迟(STW时间)，而在内存整理期间，是要移动对象的内存位置的，此时引用了这些对象的其它对象就要对引用进行修改，这个阶段必须要STW，不然会数据错乱。

¶CMS的优点:

• 并发收集
• 低延迟

¶CMS的弊端:

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

¶使用参数

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

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

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

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

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

• -XX:CMSFullGCsBeforeCompaction=<N>设置在执行多少次Fu1lGC后对内存空间进行压缩整理。

• -XX: ParallelCMSThreads=<N>设置CMS的线程数量。

  • CMS默认启动的线程数是(ParallelGCThreads+3)/4, 是年轻代并行收集器的线程数。当CPU资源比较紧张时,受到CMS收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕。

G1回收器：区域化分代式

既然我们已经有了前面几个强大的GC,为什么还要发布 Garbage First(G1) GC?

原因就在于应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC就不能保证应用程序正常进行,而经常造成STW的GC又跟不上实际的需求,所以才会不断地尝试对GC进行优化。G1(Garbage-First)垃圾回收器是在Java7 update4之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一。

与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。

¶概述

¶命名

为什么名字叫做 Garbage First(G1)呢?

因为G1是一个并行回收器,它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)。使用不同的 Region来表示Eden、幸存者0区,幸存者1区,老年代等。

G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个 Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。

由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给G1一个名字:垃圾优先(Garbage First)。

¶历程

G1(Garbage-First)是一款面向服务端应用的垃圾收集器,主要针对配备多核CPU及大容量内存的机器,以极高概率满足GC停顿时间的同时,还兼具高吞吐量的性能特征。

在JDK1.7版本正式启用,移除了 Experimental 的标识,是JDK9以后的默认垃圾回收器,取代了CMS回收器以及 Parallel+ Parallel old组合。被 Oracle官方称为“全功能的垃圾收集器”。与此同时,CMS已经在JDK9中被标记为废弃(deprecated)。

在JDK8中G1还不是默认的垃圾回收器,需要使用-XX:+UseG1GC来启用。

¶G1回收器的特点(优势)

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

¶并行与并发

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

¶分代收集

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

¶空间整合

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

¶可预测的停顿时间模型(即:软实时soft real-time)

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

• 由于分区的原因,G1可以只选取部分区域进行内存回收,这样缩小了回收的范围,因此对于全局停顿情况的发生也能得到较好的控制。

• G1跟踪各个 Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

• 相比于CMS GC,G1未必能做到CMS在最好情况下的延时停顿,但是最差情况要好很多。

¶对比CMS

相较于CMS,G1还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比CMS要高。

从经验上来说,在小内存应用上CMS的表现大概率会优于G1,而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

¶使用参数

• -XX:+UseG1GC手动指定使用G1收集器执行内存回收任务。
• -XX:G1HeapRegionSize=<N>设置每个 Region的大小。值是2的幂,范围是1MB到32MB之间,目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
• -XX:MaxGCPauseMillis=<N>设置期望达到的最大GC停顿时间指标(JVM会尽力实现,但不保证达到)。默认值是200ms
• -XX:ParallelGCThread=<N>设置STW工作线程数的值。最多设置为8
• -XX:ConcGCThreads=<n>设置并发标记的线程数。将N设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右。
• -XX:InitiatingHeapOccupancyPercent=<N>设置触发并发GC周期的Java堆占用率阈值。超过此值,就触发GC。默认值是45

¶常见操作

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

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

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

¶适用场景

• 面向服务端应用,针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)
• 最主要的应用是需要低GC延迟,并具有大堆的应用程序提供解决方案
  • 如:在堆大小约6GB或更大时,可预测的暂停时间可以低于0.5秒;(G1通过每次只清理一部分而不是全部的 Region的增量式清理来保证每次GC停顿时间不会过长)。
• 用来替换掉JDK1.5中的CMS收集器;在下面的情况时,使用G1可能比CMS好:
  1. 超过50%的Java堆被活动数据占用;
  2. 对象分配频率或年代提升频率变化很大;
  3. GC停顿时间过长(长于0.5至1秒)。
• HotSpot垃圾收集器里,除了G1以外,其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作,而G1 GC可以采用应用线程承担后台运行的GC工作,即当JVM的GC线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程。

¶分区 Region:化整为零

使用G1收集器时,它将整个Java堆划分成约2048个大小相同的独立 Region块,每个Region块大小根据堆空间的实际大小而定,整体被控制在1MB到32MB之间,且为2的N次幂,即1MB,2MB,4MB,8MB,16MB,32MB可以通过-XX:G1HeapRegionSize=<N>设定。所有的 Region大小相同,且在JVM生命周期内不会被改变。

虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分 Region(不需要连续)的集合。通过Region的动态分配方式实现逻辑上的连续。

一个region有可能属于Eden, Survivor或者old/Tenured内存区域。但是一个 region只可能属于一个角色。图中的E表示该 region属于Eden内存区域,S表示属于 Survivor内存区域,O表示属于Old内存区域。图中空白的表示未使用的内存空间。

G1垃圾收集器还增加了一种新的内存区域,叫做 Humongous内存区域,如图中的H块。主要用于存储大对象,如果超过1.5个region,就放到H。

¶设置H的原因？？？？？？

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

¶指针碰撞与TLAB

• 每个region中使用指针碰撞进行内存分配。
• 可能存在TLAB区域

¶G1垃圾回收过程

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

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

¶大体步骤

1. 应用程序分配内存,当年轻代的Eden区用尽时开始年轻代回收过程;G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期,G1 GC暂停所有应用程序线程,启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到 Survivor区间或者老年区间,也有可能是两个区间都会涉及。

2. 当堆内存使用达到一定值(默认45%)时,开始老年代并发标记过程。

3. 标记完成马上开始混合回收过程。对于一个混合回收期,G1 GC从老年区间移动存活对象到空闲区间,这些空闲区间也就成为了老年代的一部分。和年轻代不同,老年代的G1回收器和其他GC不同,G1的老年代回收器不需要整个老年代被回收,一次只需要扫描/回收一小部分老年代的 Region就可以了。同时,这个老年代 Region是和年轻代一起被回收的。

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

¶Remembered Set

• 一个对象被不同区域引用的问题：

  一个Region不可能是孤立的,一个Region中的对象可能被其他任意中对象引用,判断对象存活时,是否需要扫描整个Java堆才能保证准确？在其他的分代收集器,也存在这样的问题(而G1更突出)回收新生代也不得不同时扫描老年代?这样的话会降低Minor GC的效率。

• 解决方法:

  1. 无论G1还是其他分代收集器,JVM都是使用Remembered Set来避免全局扫描:每个Region都有一个对应的Remembered Set。

  2. 每次Reference类型数据写操作时,都会产生一个 Write Barrier(写屏障)暂时中断操作

  3. 然后检查将要写入的引用指向的对象是否和该 Reference类型数据在不同的Region(其他收集器:检查老年代对象是否引用了新生代对象);

  4. 如果不同,通过CardTable把相关引用信息记录到引用指向对象的所在 Region对应的 Remembered Set中（即记录引用了本Region的数据的引用地址）;

  5. 当进行垃圾收集时,在GC根节点的枚举范围加入 Remembered Set，就可以保证不进行全局扫描,也不会有遗漏。

• R Set示意图：

  

¶具体过程

¶1>YoungGC

¶概述

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

¶回收前

¶回收后

1. 坐标为(0,2)、(3,1)、(3,2)、(3,6)的1个Survior from区和3个Eden区region被分析到回收价值大，并经过计算可以将三个区域的数据压缩到(0,1)region（它们的数据没满）。

2. 坐标为(0,6)、(1,5)、(1,6)的1个Survior from区和2个Eden区region被分析到回收价值大，并经过计算可以将三个区域的数据压缩到(2,3)region（它们的数据没满）。

3. 而(1,5)的Survior from区数据被判定需要晋升为老年代，然后被复制到了(3,5)

¶详细描述

¶第一阶段,扫描根

GC Roots连同 Rset 记录的外部引用作为扫描存活对象的入口。

¶第二阶段,更新RSet

处理dirty card queue^[1]中的card,更新 Rset.此阶段完成后,Rset可以准确的反映老年代对所在的内存分段中对象的引用。

那为什么不在引用赋值语句处直接更新RSet呢?是为了性能的需要,RSet的处理需要线程同步开销会很大,使用队列性能会好很多

¶第三阶段,处理RSet

识别被老年代对象指向的Eden中的对象,这些被指向的Eden中的对象被认为是存活的对象。

¶第四阶段,复制对象

此阶段,对象树被遍历,Eden区内存段中存活的对象会被复制到 Survivor区中空的内存分段, Survivor区内存段中存活的对象如果年龄未达阈值,年龄会加1,达到阀值会被会被复制到Old区中空的内存分段。如果 Survivor空间不够,Eden空间的部分数据会直接晋升到老年代空间。

¶第五阶段,处理引用

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

¶2>并发标记过程

¶1)初始标记阶段:

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

¶2)根区域扫描(Root Region Scanning)

G1 GC扫描Survivor区直接可达的老年代区域对象,并标记被引用的对象。这一过程必须在 Young GC之前完成。

¶3)并发标记(Concurrent Marking)

在整个堆中进行并发标记(和应用程序并发执行),此过程可能被 Young GC中断。**在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那这个区域会被立即回收。**同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)。

¶4)再次标记(Remark)

由于应用程序持续进行,需要修正上一次的标记结果，STW。G1中采用了比CMS更快的初始快照算法: snapshot-at-the-beginning(SATB)。

¶5)独占清理(cleanup,STW)

计算各个区域的存活对象和GC回收比例,并进行排序, 识别可以混合回收的区域。为下阶段做铺垫。STW。这个阶段并不会实际上去做垃圾的收集。

¶6)并发清理阶段

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

¶3>混合回收

当越来越多的对象晋升到老年代Old Region时,为了避免堆内存被耗尽,虚拟机会触发一个混合的垃圾收集器,即 Mixed GC,该算法并不是一个Old GC,除了回收整个Young Region,还会回收一部分的Old Region。这里需要注意:是一部分老年代,而不是全部老年代。可以选择哪些Old Region进行收集,从而可以对垃圾回收的耗时时间进行控制。也要注意的是 Mixed GC并不是Full GC。

• 并发标记结束以后,老年代中百分百为垃圾的内存分段被回收了,部分为垃圾的内存分段被计算了出来。默认情况下,这些老年代的内存分段会分8次(可以通过-XX:G1MixedGCCountTarget=<N>设置)被回收。

• 混合回收的回收集(collection Set)包括八分之一的老年代内存分段,Eden区内存分段, Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样,只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。

• 由于老年代中的内存分段默认分8次回收,G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的,越会被先回收。并且有一个阈值会决定内存分段是否被回收, -XX:G1MixedGCLiveThresholdPercent=<N>, 默认为65%,意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间。

• 混合回收并不一定要进行8次。有一个阈值-XX:G1HeapWastePercent ,默认值为10%, 意思是允许整个堆内存中有10%的空间被浪费,意味着如果发现可以回收的垃圾占堆内存的比例低于10%,则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。

¶4>Full GC

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

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

1. Evacuation的时候没有足够的to-space来存放晋升的对象。
2. 并发处理过程完成之前空间耗尽。

¶关于G1回收阶段的STW

从 oracle官方透露出来的信息可获知,回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行,但这件事情做起来比较复
杂,考虑到G1只是回Region收一部分,停顿时间是用户可控制的,所以并不迫切去实现,而选择把这个特性放到了G1之后出现的低延迟垃圾
收集器(即ZGC)中。另外,还考虑到G1不是仅仅面向低延迟,停顿用户线程能够最大幅度提高垃圾收集效率,为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。

¶G1优化建议

• 年轻代大小

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

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

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

垃圾回收器总结

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

¶GC发展阶段

Serial->Parallel->CMS->G1->ZGC。

除了一个面向高吞吐量一个面向低延迟的目标不一致外,技术上的原因是Parallel Scavenge收集器及后面提到的G1收集器等都没有使用HotSpot中原本设计的垃圾收集器的分代框架,而选择另外独立实现。Serial、ParNew收集器则共用了这部分的框架代码,详细可参考: https://blogs.oracle.com/jonthecollector/our_collectors。

¶废弃的回收器

• JDK9新特性:CMS被标记为 Deprecate(JEP291)
  • 如果对JDK9及以上版本的 HotSpot虚拟机使用参数-XX:+UseConcMarkSweepGC来开启CMS收集器的话,用户会收到一个警告信息,提示CMS未来将会被废弃。
• JDK14新特性:删除CMS圾回收器(JEP363)
  • 移除了CMS垃圾收集器,如果在JDK14中使用-XX:+UseConcMarkSweepGC的话,JVM不会报错,只是给出一个warning信息,但是不会exit。VM会自动回退以默认GC方式启动JVM
    

¶怎么选择垃圾回收器?

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

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

¶垃圾收集器搭配总结

1. 设置UseSerialGC的语义就是指定串行垃圾回收器，会指定新生代收集为Serial，老年代收集为Serial Old。

2. 设置UseParNewGC的语义就是设置新生代收集为ParNew，如果老年代没有被指定就使用Serial Old（ParNew只能搭配CMS和Serial Old使用，设置其他的会报错）。

3. 只启用UseParrelGC或者只启用UseParrelOldGC或者两者都启用的时候，其语义都是设置新生代老年代GC为Parallel(Scavenge)的。

   启用UseParrelGC以及关闭UseParrelOldGC(-XX:-UseParralOldGC)的语义是新生代GC为Parallel的，老年代GC为Serial Old。

   剩下的其它搭配都会报错。

4. 上面描述到Serial和ParNew的默认老年代回收器是Serial Old，另外可以显示配置使用CMS(-XX:+UseConcMarkSweepGC)。

5. 使用-XX:+UseConcMarkSweepGC选项激活CMS后的默认新生代收集器是ParNew收集器(不是Serial)，可以使用-XX:+/-UseParNewGC选项来强制指定或者禁用它。

6. 另外Serial Old是CMS的一个backup。

7. G1是整堆收集器，只能显示启用它自己。

8. JDK6开始到JDK8默认的垃圾收集器是Parallel组合；JDK9为G1。

GC日志分析

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

¶JDK9之前

1. -XX:+PrintGC # 输出GC日志。类似 -verbose:gc

   输出信息

   解析

   

2. -XX:+PrintGCDetails # 输出GC的详细日志

   输出信息

   

   解析

   

3. -XX:+PrintGCTimeStamps # 在输出GC日志的时候，增加输出时间戳(从JVM启动依赖经历了多长时间)

   输出信息

   

4. -XX:+PrintGCDateStamps # 在输出GC日志的时候，增加输出GC的时间戳(以日期的形式,如2013-05-04T21:53:59.234+0800)

   输出信息

   

5. -XX:+PrintHeapAtGC # 在进行GC的前后打印出堆的信息

6. -X1oggc:../1ogs/gc.1og # 日志文件的输出路径

¶JDK9及之后

HotSpot所有功能的日志都收归到了“-Xlog”参数上,这个参数的能力也相应被极大拓展了:

-Xlog[:[selector][:[output][:[decorators][:output-options]]]]

命令行中最关键的参数是选择器(Selector),它由标签(Tag)和日志级别(Level)共同组成。
标签可理解为虚拟机中某个功能模块的名字,它告诉日志框架用户希望得到虚拟机哪些功能的日志输出。垃圾收集器的标签名称为“gc”,由此可见,垃圾收集器日志只是HotSpot众多功能日志的其中一项,支持的功能模块标签名如下所示:

add,age,alloc,annotation,aot,arguments,attach,barrier,biasedlocking,blocks,bot,breakpoint,bytecode......

日志级别从低到高,共有Trace,Debug,Info,Warning,Error,Off六种级别,日志级别决定了输出信息的详细程度,默认级别为Info,HotSpot的日志规则与Log4j、SLF4j这类Java日志框架大体上是一致的。另外,还可以使用修饰器(Decorator)来要求每行日志输出都附加上额外的内容,支持附加在日志行上的信息包括:

• time:当前日期和时间。
• uptime:虚拟机启动到现在经过的时间,以秒为单位。
• timemillis:当前时间的毫秒数,相当于System.currentTimeMillis()的输出。
• uptimemillis:虚拟机启动到现在经过的毫秒数。
• timenanos:当前时间的纳秒数,相当于System.nanoTime()的输出。
• uptimenanos:虚拟机启动到现在经过的纳秒数。
• pid:进程ID。
• tid:线程ID。
• level:日志级别。

tags:日志输出的标签集。
如果不指定,默认值是uptime、level、tags这三个,此时日志输出类似于以下形式:

[3.080s][info][gc,cpu] GC(5) User=0.03s Sys=0.00s Real=0.01s

¶GC日志中的时间

• user:进程执行用户态代码所耗费的处理器时间。
• sys:进程执行核心态代码所耗费的处理器时间。
• real:执行动作从开始到结束耗费的时钟时间。

请注意,前面两个是处理器时间,而最后一个是时钟时间,它们的区别是处理器时间代表的是线程占用处理器一个核心的耗时计数,而时钟时间就是现实世界中的时间计数。

如果是单核单线程的场景下,这两者可以认为是等价的,但如果是多核环境下,同一个时钟时间内有多少处理器核心正在工作,就会有多少倍的处理器时间被消耗和记录下来（即 user = coreNum * userTimePerCore、sys = coreNum * sysTimePerCore ）。

在垃圾收集调优时,我们主要依据real时间为目标来优化程序,因为最终用户只关心发出请求到得到响应所花费的时间,也就是响应速度,而不太关心程序到底使用了多少个线程或者处理器来完成任务。

¶一些JDK9前后的例子

¶例1：打印GC基本信息

在JDK 9之前使用-XX:+PrintGC,JDK 9后使用-Xlog:gc

¶例2：打印详细GC信息

在JDK 9之前使用-XX:+PrintGCDetails,在JDK 9之后使用-Xlog:gc*, 用通配符*将GC标签下所有细分过程都打印出来,如果把日志级别调整到Debug或者Trace(基于版面篇幅考虑,例子中并没有),还将获得更多细节信息

¶例3：打印GC前后的堆、方法区容量

在JDK 9之前使用-XX:+PrintHeapAtGC,JDK 9之后使用-Xlog:gc+heap=debug

¶例4：查看GC过程中用户线程并发时间以及停顿的时间

在JDK 9之前使用-XX:+PrintGCApplicationConcurrentTime以及-XX:+PrintGCApplicationStoppedTime, JDK 9之后使用-Xlog:safepoint

¶例5：查看收集器Ergonomics机制

即自动设置堆空间各分代区域大小、收集目标等内容。从Parallel收集器开始支持自动调节的相关信息。在JDK 9之前使用-XX:+PrintAdaptiveSizePolicy,JDK 9之后使用-Xlog:gc+ergo*=trace

¶例6：查看熬过收集后剩余对象的年龄分布信息

在JDK 9前使用-XX:+PrintTenuringDistribution, JDK 9之后使用-Xlog:gc+age=trace

¶JDK9中废弃的日志参数及替换列表

[参考](file:///Users/zhonghongpeng/笔记/jvm/尚硅谷/附录.md)

¶补充说明

¶GC日志打印组成

¶堆空间输出组成

¶Minor GC日志组成

¶Full GC日志组成

¶日志分析工具

可以配合-X1oggc输出日志然后用一些工具去分析这些GC日志。

常用的日志分析工具有：GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等。

垃圾回收器的新发展

GC仍然处于飞速发展之中,目前的默认选项G1 GC在不断的进行改进,很多我们原来认为的缺点,例如串行的Full GC、 Card Table扫描的低效等,都已经被大幅改进, 例如, JDK10以后, Full GC已经是并行运行,在很多场景下,其表现还略优于 Parallel GC的并行Full GC实现。

即使是 Serial GC,虽然比较古老,但是简单的设计和实现未必就是过时的,它本身的开销,不管是GC相关数据结构的开销,还是线程的开销,都是非常小的,所以随着云计算的兴起,在 Serverless等新的应用场景下, Serial GC找到了新的舞台。

比较不幸的是 CMS GC,因为其算法的理论缺陷等原因,虽然现在还有非常大的用户群体,但在JDK9中已经被标记为废弃,并在JDK14版本中移除。

¶JDK11新特性

• JEP318

  Epsilon：A No-Op Garbage Collector(Epsilon 垃圾回收器，"No-Op"无操作回收器)

• JEP333

  ZGC(JDK11)：A Scalable Low-Latency Garbage Collector(Experimental)（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）

¶Open JDK12：Shenandoah

Open JDK12的Shenandoah GC：低停顿时间的GC(实验性)。
Shenandoah,无疑是众多GC中最孤独的一个。是第一款不由 Oracle公司团队领导开发的 HotSpot垃圾收集器。不可避免的受到官方的排挤。比如号称 OpenJDK和 OracleJDK没有区别的Oracle公司仍拒绝在Oracle JDK12中支持 Shenandoah。

Shenandoah垃圾回收器最初由RedHat进行的一项垃圾收集器研究项目 PauselessGC 的实现,旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给 OpenJDK.

Red Hat研发团队对外宣称, Shenandoah垃圾回收器的暂停时间与堆大小无关,这意味着无论将堆设置为200MB还是200GB,99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。

¶Shenandoah开发团队在实际应用中的测试数据

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

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

¶总结:

• Shenandoah GC的弱项:高运行负担下的吞吐量下降。
• Shenandoah GC的强项:低延迟时间。

Shenandoah GC的工作过程大致分为九个阶段，参考JDK12新特性。

¶ZGC

https://docs.oracle.com/en/java/javase/12/gctuning/

• ZGC与 Shenandoah目标高度相似,在尽可能对吞吐量影响不大的前提下, 实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。

• 《深入理解Java虚拟机》一书中这样定义ZGC：

  ZGC收集器是一款基于 Region内存布局的,(暂时)不设分代的,使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记压缩算法的,以低延迟为首要目标的一款垃圾收集器。

• ZGC的工作过程可以分为4个阶段:并发标记-并发预备重分配并发重分配并发重映射等。

• ZGC几乎在所有地方并发执行的,除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上,这部分的实际时间是非常少的。

¶测试数据

¶吞吐量

¶延时

虽然ZGC还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用"令人震惊、革命性"来形容，不为过。未来将在服务端、大内存、低延迟应用的首选垃圾收集器。

¶ZGC的JDK14新特性

• JEP364:ZGC应用 macos在上
• JEP365:ZGC应用 Windows在上

JDK14之前,ZGC仅 Linux才支持。尽管许多使用ZGC的用户都使用类Linux的环境,但在 Windows和 macos上,人们也需要ZGC进行开发部署和测试。许多桌面应用也可以从ZGC中受益。因此,ZGC特性被移植到了 Windows和 macos上。

现在mac或Windows上也能使用ZGC了,示例如下:

• -XX:+UnlockExperimentalVMOption

• -XX:+UseZGC

¶其他垃圾回收器

¶AliGC

AliGC是阿里巴巴JVM团队基于G1算法，面向大堆（LargeHeap）应用场景。指定场景下的对比：

¶其他

当然,其他厂商也提供了各种独具一格的GC实现, 例如比较有名的低延迟GC, Zing,

参考阅读

infoq：一文看懂 JVM 内存布局及 GC 原理

掘金：老大难的GC原理及调优，这下全说清楚了

---

1. 应用程序的引用赋值语句 object field= object，JVM会在之前和之后执行特殊的错左以在dirty card queue中入队一个保存了对象引用信息的card在年轻代回收的时候,G1会对 Dirty Card Queue 中所有的card进行处理,更新RSet,保证RSet实时准确的反映引用关系 ↩︎