Java虚拟机|JVM知识点汇总及简述-＞垃圾回收（二）：垃圾回收器

光看不点赞

已于 2022-09-24 21:01:50 修改

阅读量142

点赞数

分类专栏： JVM 文章标签： java 开发语言

于 2022-06-12 19:22:30 首次发布

本文链接：https://blog.csdn.net/weixin_49258262/article/details/125248781

版权

JVM 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

文章目录

四、再谈对象引用

在这里插入图片描述
注意：相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及的（都是可达的对象，也就是说回收都发生在第二次回收）。在一定条件下，都是可以被回收的。所以，强引用是造成Java内存泄漏的主要原因之一。

1.强引用（StrongReference）

1.1 概述

最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“object obj=new object()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。即只要有强引用还在就死也不回收

2.软引用（SoftReference）

2.1 概述

在系统将要发生内存溢出之前（也就是内存足够时，不会去管软引用的对象），将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。内存不足即回收

一次回收：回收那些已经不可达的对象（不可触及的对象）
二次回收：是对这些可达对象（可触及的对象）而言进行的回收行为

3.弱引用（WeakReference）

3.1 概述

只被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。发现即回收

3.2 应用

软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

4.虚引用（PhantomReference）

4.1 概述

一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。即对象回收跟踪

5.终结器引用（了解即可）

在这里插入图片描述

5.1 概述

它用以实现对象的finalize ()方法，也可以称为终结器引用。
无需手动编码，其内部配合引用队列使用。
在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize ()方法，第二次Gc时才能回收被引用对象。

五、垃圾回收器

0.题外话

因为自JDK8以后的每个小大版本都有对GC或语法的更新与新特性，所以需要我们时常关注官网JDK更新的文档说明，观看此类文档是需要有不同的侧重点，以以下三个点为切入做到心里有数

语法层面:Lambda表达式、switch、自动装箱、自动拆箱、enum、<>…
API层面:Stream API、新的日期时间、Optional、String、集合框架等
底层优化:JVM的优化，GC的变化、元空间、静态域、字符串常量池等

GC：Carbage collection（垃圾回收）； Garbage collector （垃圾回收器）

1.垃圾回收器的分类

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

串行垃圾回收器一般应用在配置比较差的电脑中，而且被默认被应用在Java的Client模式下的JVM中

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

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

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

压缩式：压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片。即再分配对象使用指针碰撞，内存地址规整
非压缩式：非压缩式的垃圾回收器不进行这步操作。即再分配对象使用空闲列表，内存地址不规整

按工作的内存区间分：又可分为年轻代垃圾回收器和老年代垃圾回收器。

2.评估GC的性能指标

吞吐量：运行用户代码的时间占总运行时间的比例

（总运行时间：程序的运行时间＋内存回收的时间）

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

注意：

吞吐量、暂停时间和内存占用这三者对于性能的影响比较重要，但在追求极限性能下这三者指标不能同时满足，最多同时满足两个，这里推荐看“吞吐量+暂停时间”

2.1 吞吐量

概述

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值
即吞吐量=运行用户代码时间 /（运行用户代码时间＋垃圾收集时间）

侧重吞吐量

在这里插入图片描述

2.2 暂停时间

概述

“暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态
例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间呐没有应用程序线程是活动的。

侧重暂停时间

2.3 吞吐量和暂停时间的优化思路

高吞吐量

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

低暂停时间

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

矛盾性

鱼和熊掌不可兼得，吞吐量与暂停时间也亦然。以高吞吐量为优先必然会牺增加GC的执行时间；而低延迟为优先又会引起内存的缩减影响吞吐量。所以在设计时要平衡两者优劣性，现在的标准时：在最大吞吐量优先的情况下，降低停顿时间。

3.不同垃圾回收器的概述

3.1 七款经典的垃圾收集器

串行回收器：Serial、Serial Old
并行回收器：ParNew、Parallel Scavenge、Parallel old
并发回收器：CMS、G1

3.2 七款垃圾收集器与垃圾分代的关系

图示

3.3 垃圾回收器与垃圾分代如何组合使用

图示
图解

两个收集器间有实线连线，表明它们可以搭配使用:
其中serial old作为CMS出现"Concurrent Mode Failure"失败的后备预案。
(红色虚线)由于维护和兼容性测试的成本，在JDK 8时将serial+CMS、ParNew+Serial old这两个组合声明为废弃（JEP 173），并在JDK 9中完全取消了这些组合的支持（JEP214），即:移除。
(绿色虚线)JDK 14中：弃用Parallel Scavenge和Serial0ld Gc组合(JEP366)
(青色虚线).JDK 14中：删除CMS垃圾回收器（JEP 363)

3.4 不同垃圾回收器组合使用的作用

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

3.5 如何查看默认的GC

-XX:+PrintCommandLineFlags:查看命令行相关参数（包含使用的垃圾收集器），JDK8的前提下
使用命令行指令: jinfo -flag+相关垃圾回收器参数（USGXXXXXGC）+进程ID

3.6 Serial GC、Parallel GC、Concurrent Mark Sweep GC各自优劣

如果你想要最小化地使用内存和并行开销，请选Serial GC;
如果你想要最大化应用程序的吞吐量，请选Parallel GC;
如果你想要最小化GC的中断或停顿时间，请选CMS GC。

4.Serial回收器（串行回收）

4.1 概述

serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
serial收集器作为HotSpot中client模式下的默认新生代垃圾收集器。
serial 收集器采用复制算法、串行回收和"stop-the-world"机制的方式执行内存回收。
在HotSpot虚拟机中，使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。
除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的serial old收集器。Serial old收集器同样也采用了串行回收
和"stop the World"机制，只不过内存回收算法使用的是标记-压缩算法。

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

4.2 图解

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

在这里插入图片描述

4.3 优点

简单高效，在需求简单的情况下大部分单线程工作都能胜任

5.ParNew回收器（并行回收）

5.1 概述

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

Par是Parallel的缩写，New:只能处理的是新生代
ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在东轻代中同样也是采用复制算法、"stop-the-world"机制。
ParNew是很多JVM运行在server模式下新生代的默认垃圾收集器。

5.2 图解

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

在这里插入图片描述

6.Parallel Scavenge回收器（吞吐量优先）

6.1 概述

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和"stop the world"机制。
Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel old收集器，用来代替老年代的serial old收集器。
Parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和"stop-the-world"机制。
在程序吞吐量优先的应用场景中，Parallel收集器和Parallel old收集器的组合，在server模式下的内存回收性能很不错。
在Java8中，默认是此垃圾收集器。

6.2 Parallel与ParNew对比

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

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

6.3 Parallel的应用

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

6.4 图示

在这里插入图片描述

6.5 开启参数

-xx:+UseParallelGC；-xx:+UseParallelOldGC。这两个参数中挑选一个开启，另一个也会随之开启

还有很多相关的参数，附查找地址：Java参数

7.CMS回收器（低延迟）

7.1 概述

在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器: CMS (Concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。

目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求。
CMS的垃圾收集算法采用标记-清除算法，并且也会"Stop-the-world"，同样也有碎片的问题
不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC。

7.2 图示

图中总计有四个阶段：即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。

在这里插入图片描述

7.3 图解

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

7.4 缺点

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

7.5 总结

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。
由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。

要是没有足够内存可用，会临时启用serial old收集器来重新进行老年代的垃圾回收，但这样时间就会变长

7.6 参数设置

同理参考Java参数

7.7 后续JDK版本中CMS的变化

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

8.G1垃圾回收器 (Garbage-First）

8.1 发布G1的意义

原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，仅就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，而CPU和内存的快速发展又进一步降低暂定时间，兼顾吞吐量。
官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。

8.2 概述

G1在JDK7加入
因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的）。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。
对于老年代JDK10之前是串行回收，效率比较慢。
G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region.
Gl是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足cc停顿时间的同时，还兼具高吞吐量的性能特征。
在JDK1.7版本正式启用，移除了Experimental的标识，是JDK9以后的默认垃圾回收器，取代了CMS回收器以及Parallel + Parallel old组合。被oracle官方称为“全功能的垃圾收集器”。

8.3 优点（优势，特点）

并行与并发

GC期间，让多个垃圾回收线程同时工作；GC线程与用户线程交替执行，部分工作甚至可以同时执行

分代收集

由于是分区的，每个区域在逻辑上都在表示堆内存中不同的部位，所以可以在内存的物理上空间不连续

和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代;

空间整合

对于碎片化问题，G1有良好的优势，由于是划分为一个个region为基本单位，单独回收一个region中的数据时，对于有用的采用的是复制算法，而从整体上看采用的是“标记-压缩”算法，所以不存在碎片问题

可预测的停顿时间模型

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

8.4 缺点

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

8.5 Region详解

使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB，8MB，16MB，32MB。可以通过

-XX:G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。
一个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区，有时候不得不启动Full Gc。G1的大多数行为都把H区作为老年代的一部分来看待。

指针碰撞以及TLAB

指针碰撞看图就很好理解了因为是通一个region中，空间肯定是连续的
由于堆是多线程共享的。TLAB是在多线程的情况下，不同线程在region中就会有很小的区域去存放TLAB，保证一定的同步性相互独立

8.6 使用场景

面向服务端应用，针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)
最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案;

如:在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒;(G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长）。

8.7 Remembered Set

为了解决不同Region（每个Region都对应一个Remembered Set）相互引用的问题（比如老年代中的对象引用了新生代）这是一个简单的miner GC都要将全部堆遍历一遍，十分消耗资源和时间，而在GC Roots的根结点加一个Set来记录相互的引用情况，就不用全部遍历区域，直接查询Set就好

8.8 G1回收器垃圾回收过程

年轻代GC(Young GC）

首先回顾以前的知识点，只有在Eden区满了以后才会触发Young GC，而Young GC只会回收Eden和Survivor区即年轻代。
YGC时，首先G1停止应用程序的执行（Stop-The-world），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。

老年代并发标记过程(Concurrent Marking)

对于老年代的回收不是一次性全部回收完的，是通过评估每个region区域的存活对象比例，挑出最低的那几个进行回收

混合回收（Mixed GC)
Full GC

（如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。所以我们要尽量避免Full GC)
导致G1 Full GC的原因可能有三个:

回收的时候没有足够的to-space（内存太小）来存放晋升的对象;
并发处理过程完成之前空间耗尽。
暂停时间过短，导致垃圾增加的比GC还要快

8.9 参数设置

同理参考Java参数

9.七种垃圾回收器总结

9.1 图示

在这里插入图片描述

9.2 选择推荐

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

10.GC日志分析

10.1 相关参数

-XX:+PrintGC：输出GC日志。类似:-verbose:gc
-XX:+PrintGCDetails：输出GC的详细日志
-XX:+PrintGCTimeStamps：输出GC的时间戳（以基准时间的形式)
-XX:+PrintGCDateStamps：输出GC的时间戳（以日期的形式，如2013-05-04T21:53:59.234+0800)
-XX:+PrintHeapAtGC：在进行GC的前后打印出堆的信息
-Xloggc: …/logs/gc.log：日志文件的输出路径

GC日志分析工具：GCeasy（是个网页版分析工具）、GCViewer

10.2 Young GC图示

在这里插入图片描述

10.3 Full GC图示

在这里插入图片描述

10.4 堆空间日志（在JDK8的环境下）

参数设置
代码

package test02GC;

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

    public static void test(){
        byte[] a1,a2,a3,a4;
        a1=new byte[2*_1MB];
        a2=new byte[2*_1MB];
        a3=new byte[2*_1MB];
        a4=new byte[4*_1MB];
    }
    public static void main(String[] args) {
        test();
    }
}