JVM常见垃圾收集器学习指南-Java开发

这篇文章主要为大家介绍了JVM常见垃圾收集器学习指南，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪

前言

垃圾收集器是垃圾收集算法的具体实现

本文将对市面上常见的垃圾收集器类型进行讲解，希望你们会喜欢

垃圾收集器类型

垃圾收集器是垃圾收集算法的具体实现

现在主流的垃圾收集器有 7 种：

我们会根据需求场景的不同，选择不同特点的垃圾收集器

下面我会详细介绍。

1. Serial收集器

1.1 定义

最基本、发展历史最长的垃圾收集器

1.2 优点

并发收集在进行垃圾收集时，必须暂停其他所有工作线程（Stop The World），直到收集结束。

暂停工作线程是在用户不可见的情况下进行

注：并发与并行的区别 a. 并发：在某一时段内，交替执行多个任务（即先处理A再处理B，循环该过程） b. 并行：在某一时刻内，同时执行多个任务（即同时处理A、B）

单线程只使用一条线程完成垃圾收集（GC线程）
效率高对于限定单CPU环境来说，Serial收集器没有线程交互开销（专一做垃圾收集），拥有更高的单线程收集效率。

垃圾收集高效，即其他工作线程停顿时间短（可控制在100ms内），只要垃圾收集发生的频率不高，完全可以接受。

1.3 使用的垃圾收集算法

复制算法

1.4 应用场景

客户端模式下，虚拟机的新生代区域

1.5 工作流程

2. Serial Old收集器

2.1 定义

Serial收集器应用在老年代区域的版本

2.2 优点

并发、单线程、效率高

同Serial收集器，此处不作过多描述

2.3 使用的垃圾收集算法

标记-整理算法

2.4 应用场景

在客户端模式下，虚拟机的老年代区域
在服务器模式下：
与 Parallel Scavenge 收集器搭配使用

作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

2.5 工作流程

3. ParNew 收集器

3.1 定义

Serial收集器的多线程版本。

3.2 优点

并发收集在进行垃圾收集时，必须暂停其他所有工作线程（Stop The World），直到收集结束。

暂停工作线程是在用户不可见的情况下进行

多线程收集使用多条垃圾收集线程（GC线程）完成垃圾收集

由于存在线程交互的开销，所以在单CPU环境下，性能差于 Serial收集器

与CMS收集器配合工作目前，只有ParNew 收集器能与 CMS收集器配合工作

由于CMS收集器使用广泛，所以该特点非常重要。
关于CMS收集器下面会详细说明

3.3 使用的垃圾收集算法

复制算法

3.4 应用场景

服务器模式下，虚拟机的新生代区域

多线程收集

3.5 工作流程

4. Parallel Scavenge收集器

4.1 定义

ParNew 收集器的升级版

4.2 特点

具备ParNew 收集器并发、多线程收集的特点
以达到可控制吞吐量为目标其他收集器的目标是：尽可能缩短垃圾收集时间，而Parallel Scavenge收集器的目标则是：达到可控制吞吐量
吞吐量：CPU用于运行用户代码的时间与 CPU总消耗时间（运行用户代码时间+垃圾收集时间）的比值
如：虚拟机总共运行100分钟，其中垃圾收集时间=1分钟、运行用户代码时间 = 99分钟，那吞吐量 = 99 / 100 = 99%
自适应该垃圾收集器能根据当前系统运行情况，动态调整自身参数，从而达到最大吞吐量的目标。

该特性称为：GC 自适应的调节策略

这是Parallel Scavenge收集器与 ParNew 收集器最大的区别

4.3 使用的垃圾收集算法

复制算法

4.4 应用场景

服务器模式下，虚拟机的新生代区域

4.5 工作流程

5. Parallel Old收集器

5.1 定义

Parallel Scavenge收集器应用在老年代区域的版本

5.2 特点

以达到可控制吞吐量为目标、自适应调节、多线程收集

同Parallel Scavenge收集器

5.3 使用的垃圾收集算法

标记-整理算法

5.4 应用场景

服务器模式下，虚拟机的老年代区域

5.5 工作流程

6. CMS收集器

6.1 定义

即Concurrent Mark Sweep，基于标记-清除算法的收集器

6.2 特点

6.2.1 优点

并行用户线程 & 垃圾收集线程同时进行。

即在进行垃圾收集时，用户还能工作。

单线程收集只使用一条线程完成垃圾收集（GC线程）
垃圾收集停顿时间短该收集器的目标是：获取最短回收停顿时间，即希望系统停顿的时间最短，提高响应速度

6.2.2 缺点

总吞吐量会降低因为该收集器对CPU资源非常敏感，在并发阶段，虽不会导致用户线程停顿，但会因为占用部分线程（CPU资源）而导致应用程序变慢，总吞吐量会降低
无法处理浮动垃圾由于并发清理时用户线程还在运行，所以会有新的垃圾不断产生（即浮动垃圾），只能等到留待下一次GC时再清理掉。

因为这一部分垃圾出现在标记过程之后，所以CMS无法在当次GC中处理掉它们

因此，CMS无法等到老年代被填满再进行Full GC，CMS需要预留一部分空间。即所谓的：可能出现Concurrent Mode Failure失败而导致另一次Full GC产生。

垃圾收集后会产生大量内存空间碎片因为 CMS收集器是基于“标记-清除”算法的。

6.3 使用的垃圾收集算法

标记-清除算法

6.4 应用场景

重视应用的响应速度、希望系统停顿时间最短的场景

如互联网移动端应用

6.5 工作流程

CMS 收集器是基于标记-清除算法实现的收集器，工作流程较为复杂：（分为四个步骤）

初始标记

并发标记
重新标记
并发清除

下面用一张图详细说明工作流程：

由于整个过程中，耗时最长的并发标记和并发清除过程都可与用户线程一起进行
所以，CMS收集器的垃圾收集过程可看作是与用户线程并发执行的。

7. G1 收集器

7.1 定义

最新、技术最前沿的垃圾收集器

7.2 特点

并行用户线程 & 垃圾收集线程同时进行。

即在进行垃圾收集时，用户还能工作

多线程即使用多条垃圾收集线程（GC线程）进行垃圾收集

并发 & 并行充分利用多CPU、多核环境下的硬件优势来缩短垃圾收集的停顿时间

垃圾回收效率高 G1 收集器是针对性对 Java堆内存区域进行垃圾收集，而非每次都对整个 Java 堆内存区域进行垃圾收集。

即 G1收集器除了将 Java 堆内存区域分为新生代 & 老年代之外，还会细分为许多个大小相等的独立区域（ Region），然后G1收集器会跟踪每个 Region里的垃圾价值大小，并在后台维护一个列表；每次回收时，会根据允许的垃圾收集时间优先回收价值最大的Region，从而避免了对整个Java堆内存区域进行垃圾收集，从而提高效率。

因为上述机制，G1收集器还能建立可预测的停顿时间模型：即让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得从超出N毫秒。即具备实时性

分代收集同时应用在内存区域的新生代 & 老年代

不会产生内存空间碎片

从整体上看，G1 收集器是基于标记-整理算法实现的收集器

从局部上看，是基于复制算法实现上述两种算法意味着 G1 收集器不会产生内存空间碎片。