JVM垃圾回收器汇总

最新推荐文章于 2023-07-20 12:06:29 发布

tIAsHaN_

最新推荐文章于 2023-07-20 12:06:29 发布

阅读量192

点赞数 1

分类专栏：复习文章标签： jvm java

本文链接：https://blog.csdn.net/weixin_45605368/article/details/107975681

版权

复习专栏收录该内容

15 篇文章 0 订阅

订阅专栏

垃圾收集器

Serial（串行）收集器
ParNew（并行）收集器
Parallel Scavenge收集器
Serial Old收集器
Parallel Old收集器
CMS收集器
G1收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

虽然我们对各个收集器进行比较，但并非更挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。
试想一下：如果有一种四海之内、任何场量下都适用的完美收集器存在，那么我们的HotSpot虚拟机就不会实现那么多不同的垃圾收集器了。
在这里插入图片描述

Serial（串行）收集器

Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味著它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行地圾收集工作的时候必须暂停其他所有的工作线程( “Stop The World”)，直到它收集结束。

新生代采用复制算法，老年代采用标记-整理算法。
在这里插入图片描述
虚拟机的设计者们当然知道Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短(仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续)。

但是Serial收集器有没有优于其他垃圾收集器的地方呢?当然有，它简单而高效(与其他收集器的单线程相比)。Serial 收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial 收集器对于运行在Client 模式下的虚拟机来说是个不错的选择。

ParNew（并行）收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为(控制参数、收集算法、回收策略等等)和 Serial 收集器完全一样。

新生代采用复制算法，老年代采用标记-整理算法。

在这里插入图片描述它是许多运行在 Sever 模式下的虚拟机的首要选择，除了Serial 收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到)配合工作。

行和并发概念补充:

并行( Parallel) ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发(Concurrent) : 指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个CPU上。

Parallel Scavenge收集器

Parallel Scavenge收集器也是使用复制算法的多线程收集器，它看上去几乎和ParNew都一样。那么它有什么特别之处呢?

-XX:+UseParallelGC 使用Parallel 收集器+老年代串行-XX:+UseParallelOldGC 使用Parallel 收集器+老年代并行

Parallel Scavenge收集器关注点是吞吐量(高效率的利用CPU)。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间(提高用户体验)。所谓吞吐量就是CPU中于运行用户代码的时间CPU 总消耗时间的比值。

Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，手工优化存在困难的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

新生代采用复制算法，老年代采用标记-整理算法。

在这里插入图片描述

Serial Old收集器

Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5以及以前的版本中与Parall Scavenge收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

Parallel Old收集器

Parallel Scavenge 收集器的老年代版本。 使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parlel Scavenge 收集器和 Parallel Old 收集器。

CMS收集器

CMS ( Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重户体验的应用上使用。

CMS ( Concurrent Mark Sweep)收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记清除” 算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记：暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快;
并发标记：同时开启 GC 和用户线程，从已经标记的直接与 root 相连的对象开始，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。
并发清除：开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

在这里插入图片描述主要优点：

并发收集
低停顿

明显的缺点：

对 CPU 资源敏感
在并发阶段虽然不会停止用户线程，但是会占用一部分线程来进行垃圾回收，总吞吐量会降低。
无法处理浮动垃圾
CMS 在并发清理阶段还可以运行用户线程，这时候还会产生新的垃圾，而这部分垃圾 CMS 无法在本次回收掉，这部分就是浮动垃圾。因此 CMS 不能像其他的收集器等到年老代几乎全部满了再进行回收，需要预留一部分空间提供并发收集时候的用户线程使用。默认设置下，CMS 收集器在年老代使用了 68% 的空间后就会被激活，可以通过 -XX:CMSInitiatingOccupancyFraction 参数来设置这个属性。如果 CMS 在运行时候预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败,这时候虚拟机临时启用 Serial Old 收集器重新来进行老年代的垃圾收集。
它使用的回收算法 “标记-清除算法” 会导致收集结束时会有大量空间碎产生
空间碎片过多后给打对象分配空间会有很多麻烦。CMS 提供了一个参数 -XX:+UseCMSCompactAtFullCollection 用来在 Full GC 完成后附加一个碎片整理过程，碎片整理无法并发会导致停顿时间变长。当然还提供了一个参数 -XX:CMSFullGCsBeforeCompaction，这个参数设置在执行多少次不压缩的 Full GC 后，跟着来一次带压缩的。

G1收集器

G1（Garbage-First）是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器。以极高概率满足 GC 停顿时间要求的同时，还具备高吞吐量性能特征。

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

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

在这里插入图片描述

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

G1收集器被视为JDK1.7中HotSpot 虚拟机的一个重要进化特征。它具备以下特点：

并行与并发： G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU (CPU或者CPU核心) 来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1收集器仍然可以通过并发的方式让 java 程序继续执行。
分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
空间整合：与 CMS 的 “标记-清理” 算法不同，G1从整体来看是基于“标记整理 ” 算法实现的收集器，从局部上来看是基于 “复制” 算法实现的（内存的回收是以Region作为基本单位的，Region之间是复制算法）。
可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内。

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