JVM常用垃圾收集器

野性酷女 2022-10-25 12:51 147阅读 0赞

## 前言 ##

在上一篇，我们谈到了JVM中的常用垃圾回收算法，并了解了JVM中针对堆区中不同的分代采用不同的垃圾回收算法

在了解了垃圾回收算法之后，很多伙伴不禁在想，既然是分代垃圾回收，自然新生代和老年代的垃圾收集器也是不同的，事实上确实是这样，分代的回收算法也产生了不同的垃圾收集器，先来看一下下面这张简图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70]  
左边表示年轻代中可选的垃圾收集器，右边表示老年代中可选的垃圾收集器，任何两个连线之间的两种垃圾收集器可以进行组合使用，在年轻代中，Parallel Scavenge 是默认的GC收集器，而在老年代中，SerialOld为默认的GC收集器

上面的看到的年轻代和老年代收集器属于分代收集器，在JDK1.8中，由于采用了分代垃圾回收，故使用分代垃圾收集器进行GC，各个垃圾收集器根据自身的特点都有着不同的使用场景，下面针对各个垃圾收集器进行简单的说明，以便深入理解各款垃圾收集器的使用原理

可以使用下面的命令查看本机或者虚拟机上的JVM的垃圾收集器（默认安装的JDK版本）

java -XX:+PrintCommandLineFlags -version

![在这里插入图片描述][20210131183219391.png]

## 新生代垃圾收集器 ##

**Serial**

Serial垃圾收集器也叫做串行收集器，串行垃圾收集器的特点：

*  使用单线程对垃圾对象进行GC
 *  用于年轻代的垃圾收集器
 *  适合单核CPU
 *  执行效率较低，STW时间较长（其间将会产生较长的GC等待时间）
 *  适用于垃圾较小的内存场景（几十MB）
 *  主流虚拟机已淘汰

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 1]  
**ParNew**

这是对单线程的Serial的一种改进，ParNew收集器是并行的，在多CPU的场景下会有比串行收集器更好的性能，除此之外，实现算法跟Serial完全一样

ParNew垃圾收集器特点：

*  JDK8之后默认的年轻代垃圾收集器
 *  STW短时优先，GC次数多（但是总体保证每次GC时间较短）
 *  使用多个线程（默认情况下与CPU核数一致）并行GC，效率提升
 *  适合多核CPU
 *  适用于较大的内存对象场景
 *  适合与用户交互的场景
 *  一般与CMS配合使用

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 2]  
**Parallel Scavenge**

也称作PS收集器，这也是一种新生代垃圾收集器，它采用的也是复制算法，与前两种收集器最大的区别是，它关注的是吞吐量而不是延迟，也被称为是吞吐量优先的收集器

其特点为：

*  以追求吞吐率最小（每一次GC消耗的时间 / 总时间）优先
 *  JDK1.8默认的垃圾收集器（年轻代）
 *  STW时间长，GC次数少（目前Java应用的部署的服务器更多的是进行后台任务的计算，直接与用户交互的过程较少，因此减少GC次数就很有必要）
 *  多线程GC，执行效率较高
 *  适合多核CPU
 *  适合后台计算任务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 3]

## 老年代垃圾收集器 ##

**SerialOld**

这个是jdk1.2以前的默认收集器，适合单线程下作为CMS的备用收集器，由于运行效率较低，目前基本上很少使用，其运行原理和年轻代的Serial相似

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 4]  
**Parallel Old**

该收集器可以理解为PS收集器的老年代版本（对比理解PS收集器），其主要特点包括：

*  关注吞吐率
 *  STW时间较长，GC次数少
 *  多线程GC，执行效率较高
 *  适合多线程CPU
 *  适合后台计算任务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 5]  
**CM**

CMS，Concurrent Mark Sweep，这是一款真正的并发收集器，属于老年代的垃圾收集器中最复杂的一款垃圾收集器，其主要特点为：

*  用户线程与GC并行执行（前面的收集器是用户线程和垃圾回收线程是不同的线程，因此STW时间相对较长），用户的感知最小
 *  超短的STW,适合较大的内存环境（几十G）
 *  会产生浮动垃圾
 *  会产生标记失败
 *  会降低用户线程的CPU使用效率（CPU需要分出部分的线程同时处理垃圾回收，以至CPU不能全部用户用户线程的任务处理）
 *  标记清除时产生大量内存碎片（CMS采用标记清除算法）
 *  JDK14被废弃

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 6]

从上图中我们发现，CMS垃圾回收器在执行一次完整的垃圾回收时要经历几个阶段：初始标记（会产生一个很短的STW） ，并发标记，重新标记，并发清理，对其中的几个关键点做简单的说明：

*  初始标记：只标记GCRoot第一层关联
 *  浮动垃圾：运行中未及时发现的垃圾对象，会在重新标记阶段进行标记（由于用户线程和GC线程是并发执行的）
 *  标记失败：被认定的垃圾对象在后面的阶段中再次被引用，在重新标记阶段修正
 *  并发清理：会针对前面产生的各种垃圾对象，并发标记和重新标记阶段中的那些垃圾对象在并发清理阶段完成一次真正意义上的回收，此时用户线程将会处于暂停的状态（实际产生的情况很少）

在实际工作中如何通过参数设置进行搭配使用呢？可以参考下面的表格

<table> 
 <thead> 
  <tr> 
   <th>新生代</th> 
   <th>老年代</th> 
   <th>JVM参数</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Serail</td> 
   <td>SerialOld</td> 
   <td>-XX:+UseSerialGC</td> 
  </tr> 
  <tr> 
   <td>Parallel Scavenge</td> 
   <td>SerialOld</td> 
   <td>-XX:+UseParallelGC</td> 
  </tr> 
  <tr> 
   <td>Parallel Scavenge</td> 
   <td>ParallelOld</td> 
   <td>-XX:+UseParallelOldGC</td> 
  </tr> 
  <tr> 
   <td>ParNew</td> 
   <td>SerialOld</td> 
   <td>-XX:+UseParNewGC</td> 
  </tr> 
  <tr> 
   <td>ParNew</td> 
   <td>CMS + SerailOld</td> 
   <td>-XX:+UseConcMarkSweepGC</td> 
  </tr> 
  <tr> 
   <td>G1</td> 
   <td>G1</td> 
   <td>-XX:+UseG1GC</td> 
  </tr> 
 </tbody> 
</table>

如果想要自定义自己的应用使用某种收集器，以springboot的jar包为例，可以使用下面的命令：

java -jar -XX:+UseParallelGC XXX.jar

以上是关于分代垃圾收集器中，新生代和老年代各款收集器的说明，但是随着JVM的持续迭代与优化，垃圾收集器也在持续完善，比如JDK9开始就出现了不分代垃圾收集器，像CMS收集器，在JDK14中被废弃，说明了在迭代中，有更好的收集器取代它，下面再介绍几种常用的不分代垃圾收集器

## 不分代垃圾收集器 ##

常用的不分代垃圾收集器包括下面几种

*  G1收集器
 *  ZGC收集器
 *  Shenandoah收集器

**G1收集器**

G1收集器，是比前面的更优秀，真正有突破的一款垃圾收集器，在G1中还是保留了分代的概念，是实际上已经在新生代和老年代中没有物理隔离了，在G1中，内存空间被分割成一个个的Region区，所谓新生代和老年代，都是由一个个region组成的，同时G1也不需要跟别的收集器一起配合使用，自己就可以搞定所有内存区域。整体上来讲不是一个分代收集器，是一个通吃收集器。这也是JVM内存管理和垃圾收集的一个发展趋势。从后面zgc中我们可以更清晰的看到这个变化

G1采用了标记-整理算法，避免了CMS中的内存碎片问题，另外它能达到可控的垃圾时间

整体来说，G1收集器的特点：

*  JDK1.9默认的垃圾收集器
 *  多线程并发标记，并发回收
 *  物理分区（Region），1/2/4/8/32mb（即在物理存储上，不再像分代那样有明确的分代概念，提供了这几种大小规格进行选择）
 *  逻辑分代，物理分区
 *  GC时间极短，单次STW的时间默认最多200MS
 *  支持上百G的内存GC  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 7]  
    G1垃圾回收过程可以和CMS垃圾回收过程进行类比，可以认为是G1收集器吸收了CMS的某些优秀的特点并进行了改良，但在其内部，仍然是以分代的思想进行垃圾回收，即采用了： 新生代 + 老年代 的混合回收算法（Mixed GC）,触发条件为：老年代超过了堆内存的45%  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 8]

**ZGC**

zgc是jdk11中要发布的最新垃圾收集器，不管是CMS收集器，还是G1收集器（尽管物理上没有分代的概念，但是逻辑上仍然采用了分代的思想进行垃圾回收），都有一个特点，就是在整个垃圾收集过程中的**初始标记**和**最终标记**阶段，会有一个STW的产生，尽管G1相比CMS有了更大的提升，但是由于分代的概念存在，始终无法绕过这个问题

ZGC特点：

*  JDK11出现的实验性的GC，OracleJDK中使用
 *  <10ms的STW时间
 *  分区容量可动态规划，小的region - 2MB，中 - 32MB（根据对象大小的不同开辟不同Region大小的内存块）
 *  支持T级别的内存GC
 *  彻底不分代，利用染色指针实现对象引用
 *  在GC的标记压缩回收对象过程中与用户线程并发执行，但是过程中并不产生STW

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 9]  
**Shenandoah收集器**

Shenandoah收集器目前在JDK12中也处于实验性阶段，其主要特点包括：

*  一款实验性的GC，OpenJDK中使用
 *  <10ms的STW时间
 *  固定大小内存块，彻底不分代
 *  支持T级别的内存GC
 *  利用读屏障与转发指针实现对象的动态引用
 *  在GC的标记压缩与回收对象过程中与用户线程并发执行，过程中不再产生STW

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 10]  
后面两种收集器可以作为学习进行了解，尽管目前还没有大规模的投入商用，但是其设计理念却为未来的垃圾收集器的持续优化和改进提供了很好的思路和方向，尤其是ZGC 和Shenandoah的超低延迟STW，可以说在分代收集器的基础上进行了相当大的提升，让我们拭目以待吧

**本篇到此结束，最后感谢观看！**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70]: /images/20221024/1a65cc25b0554d139f4f9ddebe70f67e.png
[20210131183219391.png]: /images/20221024/11e9567f126445acb78a12d9aba02ee0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 1]: /images/20221024/fb6c0859b0ea4a72a62dcb051747f068.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 2]: /images/20221024/d7e4d8141fce4b1689f2a84c8c0579a8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 3]: /images/20221024/d21b6113c7f64432835bdb22045930f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 4]: /images/20221024/8893c2a0a6fe4868944b5c1339598a61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 5]: /images/20221024/8dcf82d52b344bf192f4a398956b6c43.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 6]: /images/20221024/784c59dd3e3049d4a6cef8027843103d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 7]: /images/20221024/b8ccdae16eeb4d0481db92023177629c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 8]: /images/20221024/eea9a9ce82b24b30aa9e57f10365f581.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 9]: /images/20221024/f3780c6f8d3f47ec97d71534502e35ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 10]: /images/20221024/7dfb03f3008243448cd935fa88342f1f.png