JVM常用的8种垃圾回收器:主要特点，使用场景及优化建议

朴灿烈づ我的快乐病毒、 2022-12-17 15:52 173阅读 0赞

### 文章目录 ###

*   *  垃圾回收算法
     *  垃圾回收器
     *   *  Serial
         *  ParNew
         *  Parallel Scavenge
         *  Serial Old
         *  Parallel Old
         *  CMS
         *  G1
     *  ZGC
     *  总结
     *  参考

## 垃圾回收算法 ##

垃圾回收算法是所有垃圾回收器的基础，不同的垃圾回收器所使用的垃圾回收算法也是不同的，但大致分一下几种:

1.  标记-清除算法

*  原理： 将垃圾对象直接标记然后清除
 *  缺点： 会产生内存碎片，浪费内存

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

1.  复制算法：

*  原理:将内存划分为两块，只使用一块，待这个内存满了，把里面的对象清除到另一快内存
 *  优点: 产生内存碎片
 *  缺点: 可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

1.  标记-整理算法

*  原理: 将存活对象标记，然后整理移动到一边，使存活对象内存紧凑，避免出现内存碎片
 *  优点:不会产生内存碎片
 *  缺点:仍需要进行局部对象移动，一定程度上降低了效率

1.  分代收集算法

*  原理: 据对象的存活周期将内存划分为几块。一般包括年轻代、老年代 和 永久代  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70_pic_center 1]

> 需要注意的是 >jdk1.8 永久代就被元空间代替了，而元空间也不在堆内存中，在本地内存中,  
> 可以参考我以前的[JVM模型][JVM]

然后更具不同的内存使用不用的算法，比如因为年轻代每次回收对象较多，就可以使用 复制算法，但是实际是对复制算法做了优化，每次可用内存为enden+S0，而不是只有一半，老年代因为存活的对象较多，则可使用标记清楚算法，不用挪动太多对象。具体的实现还是要看各个垃圾器是如何处理的

## 垃圾回收器 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70_pic_center 2]

目前主流的垃圾回收器有如上8中，其中有连线的代表是可以相互配合使用的。G1和ZGC在中间代表老年代和年轻代混合回收

在介绍垃圾回收器前先理解几个基本的概念：

1.  并行回收（Parallel）  
    多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态
2.  串行回收  
    单个垃圾收集线程工作
3.  Minor GC（Young GC）  
    发生在年轻代的GC
4.  Full GC  
    发生在老年代的GC， full GC回收速度一般比Minor GC慢10倍左右，JVM调优也是主要针对Full GC进行调优

### Serial ###

*  特点：

1.  新生代使用的垃圾收集器
2.  采用复制算法
3.  串行回收，进行垃圾收集时，必须暂停所有工作线程，直到完成。即会"Stop The World"

*  应用场景

1.  单个CPU的环境来说，Serial收集器没有线程交互（切换）开销，可以获得最高的单线程收集效率。但现在大多数多核CPU

*  参数设置

"-XX:+UseSerialGC"：使用串行垃圾收集器

### ParNew ###

*  特点

1.  新生代使用的垃圾收集器
2.  是 Serial收集器的多线程版本
3.  除了多线程外，其余的行为、特点和Serial收集器基本一样

*  应用场景
 *  除Serial外，目前只有它能与CMS收集器配合工作
 *  可控JVM参数非常多，适用于Server模式下，即减少系统停顿，提高系统响应速度
 *  参数设置

"-XX:+UseParNewGC"：使用ParNew收集器
    "-XX:ParallelGCThreads"：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；

### Parallel Scavenge ###

*  特点：

1.  新生代使用的垃圾收集器
2.  Parallel Scavenge垃圾收集器因为与吞吐量关系密切，也称为吞吐量收集器
3.  JDK1.8,默认垃圾收集器
4.  与ParNew收集器相似，采用复制算法,多线程收集
5.  主要目标是达一个可控制的吞吐量

*  应用场景  
    适用于应用程序运行在具有多个CPU上，对暂停时间没有特别高的要求时，即程序主要在后台进行计算，而不需要与用户进行太多交互；  
    例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序
 *  设置参数

"-XX:MaxGCPauseMillis" 控制最大垃圾收集停顿时间，大于0的毫秒数
    "-XX:GCTimeRatio" 设置垃圾收集时间占总时间的比率，0<n<100的整数,GCTimeRatio相当于设置吞吐量大小；
    "-XX:+UseAdptiveSizePolicy" 动态调整这些参数，以提供最合适的停顿时间或最大的吞吐量

> MaxGCPauseMillis设置得稍小，停顿时间可能会缩短，但也可能会使得吞吐量下降；  
> 因为可能导致垃圾收集发生得更频繁；

### Serial Old ###

*  特点：

1.  针对老年代
2.  单线程收集
3.  采用"标记-整理"算法（还有压缩，Mark-Sweep-Compact）

*  应用场景

1.  在CMS并发清除阶段系统继续运行，然后一些对象进入老年代，同时又变成垃圾对象，老年代内存不够，会自动使用Serial Old替换CMS，即强行Stop the World

### Parallel Old ###

*  特点：

1.  针对老年代；
2.  采用"标记-整理"算法；
3.  多线程收集；
4.  与 Parallel Scavenge 配合使用

*  应用场景  
    参考 Parallel Scavenge

### CMS ###

*  特点：

1.  针对老年代；
2.  基于"标记-清除"
3.  以获取最短回收停顿时间为目标，并发收集、低停顿

*  应用场景  
    与用户交互较多的场景；  
    希望系统停顿时间最短，注重服务的响应速度；  
    以给用户带来较好的体验；  
    如常见WEB、B/S系统的服务器上的应用；

> 目前在生产和实践中我们使用的最多的还是ParNew + CMS。所以我们一般需要重点关注这两个回收器的一些特点，这里简单说明一下CMS的回收过程，大致分如下几个步骤
> 
> 1.  初始标记，会Stop the World，目的是标记出所有的GC Roots直接引用的对象，耗时较短，因为仅仅标记GC Roots直接引用的对象
> 2.  并发标记，不会Stop the World，目的是对已有的对象进行GC Roots追踪，耗时最久，因为需要追踪所有对象是否从根源上被GC Roots引用，但无需担心因为这个阶段不会Stop the World
> 3.  .重新标记， 会 Stop the World，目的是标记二阶段新增存活对象和垃圾对象，耗时也不会太久，因为标记二阶段程序运行改变的少数对象
> 4.  并发清除，不会Stop the World，目的是清理标记出来的垃圾对象，耗时也较久
> 5.  碎片整理，具体可通过参数 -XX:+UseCMSCompactAtFullCollection 设置多少次Full GC整理一次碎片

这里针对CMS + ParNew 目前大多公司可能都有相应的参数模板，这里我给出一个简单的参数模板供大家参考

-Xms7500m -Xmx7500m 初始堆大小
    -Xmn3000m # 新生代大小
    -Xss512k  # 每个线程的堆栈大小
    -XX:MaxMetaspaceSize=512m # 设置类元数据区的最大大小(限制Metaspace增长的上限，防止因为某些情况导致Metaspace无限的使用本地内存，影响到其他程序。在本机上该参数的默认值为4294967295B（大约4096MB）。)
    -XX:MetaspaceSize=512m # 设置类元数据区的初始大小
    -Dfile.encoding=UTF-8 # 系统文件编码格式为utf-8
    -XX:+UseConcMarkSweepGC # 老年代使用CMS
    -XX:+UseParNewGC # 年轻代使用ParNew
    -XX:+UseCMSCompactAtFullCollection # 在FULL GC的时候， 对年老代的压缩 1.6版本后默认开启，不必显式设置，未来版本会废弃
    -XX:CMSFullGCsBeforeCompaction=0  # 每次full gc整理内存碎片
    -XX:CMSInitiatingOccupancyFraction=92 老年代占比92%触发full gc
    -XX:SurvivorRatio=8 # Eden、Survivor比 8:1:1
    -XX:+UseCMSInitiatingOccupancyOnly # 禁止hostspot自行触发CMS GC
    -XX:+CMSScavengeBeforeRemark ## 在cms gc之前进行一次 minor gc 减少 remark的开销
    -XX:+ParallelRefProcEnabled #并行处理 reference 加快final remak
    -XX:+CMSClassUnloadingEnabled
    -XX:+DisableExplicitGC ## 防止某些”大神“在代码里边执行 System.gc()
    -XX:+CMSParallelInitialMarkEnabled ## 初始标记 多线程并行 一般没必要，初始标记都很快
    -XX:+CMSClassUnloadingEnabled # cms回收对永久代回收,CMS收集器默认不会对永久代进行垃圾回收
    -XX:ParallelGCThreads=$CPU_Count 并行收集器的线程数 此值最好配置与处理器数目相等 同样适用于CMS
    -Xloggc:${PROJECT_DIR}/logs/gc.log 
    -XX:+PrintGCDateStamps
    -XX:+PrintGCDetails
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:HeapDumpPath=${PROJECT_DIR}/logs/heapdump.hprof

实际情况通过一些JVM调优工具对上面的参数进行调整以达到最优效果，更多JVM参数解释可参考我转载的上一篇博文 [JVM参数说明以及配置模板][JVM 1]

### G1 ###

*  特点

1.  能充分利用多CPU、多核环境下的硬件优势
2.  可以设置JVM停顿的时间
3.  新生代老年代混合回收
4.  将JVM堆内存划分为多个 Region

*  应用场景  
    一般用于大内存的机器比如8g 16g等，在大内存上使用CMS可能导致很久不回收，然后一次回收很久的情况，而G1则不会，他可以控制每次回收时间。
 *  参数设置

-XX:+UseG1GC 使用G1垃圾回收器
    -XX:MaxGCPauseMills  设置停顿时间

## ZGC ##

… 待更新…

## 总结 ##

这里只是简单的介绍几8中常用垃圾收集器，实际每一种要详细讲解也是特别复杂的，后续会继续单独对一些重要的垃圾收集器做一些讲解，参数也只是给了几个相对重要的

## 参考 ##

https://www.cnblogs.com/alsf/p/9484770.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70_pic_center]: /images/20221122/23bc76ec36ff43ae93bb3c4b4198eb96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221122/59ef0dfd44f84641bf81e80579e3c7c4.png
[JVM]: https://blog.csdn.net/qq_42651904/article/details/88862994
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221122/71690018cc6c470d8eb848cbb4034497.png
[JVM 1]: https://weihubeats.blog.csdn.net/article/details/109220929