JVM垃圾收集器

港控/mmm° 2021-11-10 12:36 307阅读 0赞

### JVM垃圾收集器 ###

*  Serial收集器
 *  ParNew收集器
 *  Parallel Scavenge收集器
 *  Serial Old收集器
 *  Parallel Old收集器
 *  CMS收集器
 *  G1 收集器

如果说收集算法是垃圾回收的方法论，那么收集器就是垃圾回收的具体实现，没有哪一个垃圾收集器是绝对完美的，我们能做的只是根据应用场景去选择合适的垃圾收集器。

# Serial收集器 #

Serial(串行)收集器是最基本、历史最悠久的收集器，大家看名字就知道这是一个单线程收集齐了。它的单线程不仅仅意味着它只会用一条线程进行垃圾收集工作，更重要的是它在进行垃圾收集工作是需要暂停其他的工作线程，直到它收集结束。  
**新生代采用复制算法，老年代采用标记-整理算法**  
虽然暂停其他工作线程的时间在不断地缩短优化，但仍然会造成不好的体验，这是这个收集器的缺陷，  
这个收集器对比其他收集器好的地方在于没有线程交互的开销，具有很高的单线程执行效率。Serial收集器对于运行在Client模式的虚拟机是个不错的选择。

# ParNew收集器 #

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余的行为和Serial收集器完全一样。  
**新生代采用复制算法，老年代采用标记-整理算法**  
它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能和CMS收集器(真正意义上的并发收集器)配合工作。

# Parallel Scavenge收集器 #

Parallel Scavenge 收集器也是使用复制算法的多线程收集器，那它跟ParNew收集器有什么区别的？

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

**新生代采用复制算法，老年代采用标记-整理算法**  
Parallel Scavenge收集器的关注点在吞吐量(高效的利用CPU)。CMS等收集器的关注点更多的是用户线程的停帧时间(用户体验)。所谓吞吐量就是CPU中运行用户代码的时间和运行总时间的比值。Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

# Serial Old收集器 #

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

# Parallel Old收集器 #

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

# CMS收集器 #

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的垃圾收集器(非常注重用户体验)。它是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种来说更加复杂一些。整个过程分为四个步骤：

*  初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快
 *  并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方
 *  重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
 *  并发清除： 开启用户线程，同时 GC 线程开始对为标记的区域做清扫  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_SnVzdGluTmVpbA_size_16_color_FFFFFF_t_70]  
    从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：
 *  对 CPU 资源敏感
 *  无法处理浮动垃圾
 *  它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生

# G1 收集器 #

G1(Garbage First)是一款面向服务器的垃圾收集器主要针对配置多核处理器以及大容量内存的机器，在满足极短的GC停顿时间的同时还具有极高的吞吐量。  
被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备一下特点：

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

G1 收集器的运作大致分为以下几个步骤：  
初始标记  
并发标记  
最终标记  
筛选回收  
G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_SnVzdGluTmVpbA_size_16_color_FFFFFF_t_70]: /images/20211109/4f467b6a746149c6ba54f8e26eaea465.png