JVM-垃圾回收器

MG-net

已于 2022-01-29 14:17:19 修改

阅读量525

点赞数

分类专栏： jvm 文章标签： java 开发语言后端

于 2021-12-11 11:38:01 首次发布

本文链接：https://blog.csdn.net/liming0025/article/details/121732101

版权

jvm 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

一、GC分类与性能指标

因为没有明确规定，可以由不通厂商和不同版本JVM来实现。所以衍生出来众多的GC回收器版本。

线程数：串行、并行

工作模式：并发式、独占式

碎片处理方式：压缩式、非压缩式

工作内存区间：年轻代和老年代

评估GC的性能指标

吞吐量：运行用户代码的时间占总运行时间的比例
垃圾收集开销：吞吐量的补数，垃圾收集所用时间于总运行时间的比例
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间（STW）
收集频率：相对应用程序的执行，收集彩舟发生的频率
内存占用：java堆所占内存大小
快速：一个对象从诞生到被回收精力的时间

三点中，暂停时间最重要，因为毕竟要服务用户线程，但是一款GC做多满足三点中的两点，一般关注：吞吐量、暂停时间，也是调优关心的2个指标。

用户线程运行时间长，产生的垃圾一定就多，GC的时间也一定就长。

因为高吞吐量和低延迟是两个竞争关系的指标，所以针对不同情况选择不同指标进行优化。现在GC标准是：在最大吞吐量优先的情况下，降低停顿时间。

串行回收器：Serial、Serial Old
并行回收器：ParNew、Parallel Scavenge、Parallel OId
并发回收器：CMS、G1
新回收器：ZGC、Epsilon、Shenandoah GC

这么多的垃圾回收器，主要是因为不同的应用场景，服务端、移动端等等，开发者可以针对具体的场景选择适合的垃圾回收器。查看 -XX:+PrintCommandLineFlags或者jinfo -flag 参数进程ID

二、不同的垃圾回收期概念

1、Serial回收器：串行回收

Serial回收器是历史最悠久的，最基本的回收器。采用年轻代复制算法、老年代标记压缩、串行回收和STW机制进行回收。Old区使用标记压缩算法进行回收。

Serial Old 是运行在Client模式下的默认老年代回收器
Serial Old 在Server模式下主要用作：a、与新生代Parallel Sacvenge配合使用 b、作为CMS收集器的后备垃圾回收器

优势：

简单而高效（相对在单线程\CPU），因为没有切换的开销
在桌面场景下可以使用，内存小、回收频繁
设置-XX:UseSerialGC = 新生代用 SerialGC 老年代用SerialOldGC

总结：

单核场景下优秀，所以使用场景逐渐减少
因为是STW，交互强的应用也无法使用

2、ParNew回收器：并行回收

Serial回收器的多线程版本，Par->多线程、New->新生代，所以ParNew是处理新生代的垃圾回收。也是采用复制算法、STW机制。相对单线程，STW时间少点。在很多Server模式下进行收集新生代进。老年代可以配合Serial Old或者CMS使用，JDK9移除了。应用场景已经很少了。

多CPU的时候，ParNew相比Serial优秀，但是单CPU场景下Serial更好。使用参数-XX:+UseParNewGC设置新生代使用ParNew回收器，-XX:ParallelGCThreads设置线程数量，默认和CPU数相同。

3、Parallel回收器：并行、吞吐量优先

也是一款并行回收器，性能和ParNew差不多，使用的都是年轻代复制算法、老年代标记压缩、并行回收和STW机制。甚至性能和ParNew差距不是很大。JDK8中是默认的垃圾回收器。因为在服务端发挥出很好的性能。

为什么出现：

达到一个可控制的吞吐量，也被称为吞吐量有限的垃圾回收器
自适应调节策略也是一个重要区别，就是能够根据情况调节内存、吞吐量等
高吞吐量是高效的使用CPU，适合没有太多的交互场景，交互场景需要响应有限
Parallel Old采用了标记-压缩算法，但是同样的也是基于并行和STW机制

参数设置：

-XX:UseParallelGC：年轻代的回收，跟老年代相互激活
-XX:UseParallelOldGC：老年代的回收，跟年轻代互相激活
-XX:ParaellelGCThreads：设置年轻代并行回收线程数，默认情况下同CPU相同，大于8的时候=3+[5*cpu_count]/8
-XX:MaxGCPauseMillis：最大暂停时间，默认即可，设置需要谨慎，为了能够符合这个时间，可能自动调整java堆的大小
-XX:GCTimeRatio：垃圾回收时间比例，默认99
-XX:+UseAdaptoveSizePolicy：设置是否自适应调节，默认调整Edn和S区的比例，新生代和老年代比例，导致eden和s0、s1区不是8:1:1

4、CMS回收器：并发、低延迟

第一款真正实现了并发的回收器（回收线程和用户线程同时执行），满足了强交互性场景。尽可能的减少SWT的时间。合适在B\S架构上的。使用标记-清除算法和STW机制。（分配对象的时候使用空闲列表，所以需要达到一定比例就触发GC，否则用户线程没办法执行）。

初始标记：STW，在这个过程仅仅是为了标记GC Roots直接关联到的对象，所以速度很快
并发标记：标记出GC Roots关联对象所关联的全部对象的过程，这个耗时长，但是不STW
重新标记：因为并发标记在用户线程在执行，所以再标记一次，耗时较短，需要STW
并发清除：标记完了，因为不需要碎片整理，所以用户线程可以运行，但是存在碎片问题

缺点：

因为是并发的执行的，所以再回收的过程中，内存需要能够执行用户线程，所以不会等到堆内存满了之后再执行。所以可能存在，当我们执行的时候，出现用户线程太多，CMS无法回收，这个时候启动Serial Old 启动。
因为要再回收的时候，用户线程需要执行，所以没办法使用标记-压缩算法。所以标记-压缩算法的时候一定是STW
产生内存碎片
对CPU资源敏感：虽然用户线程不同停顿，但是因为一起执行，导致应用程序变慢，吞吐量降低
CMS无法处理浮动垃圾：没办法处理再并发标记阶段，用户线程心产生的垃圾，只能在第二次进行清除

参数设置：

-XX:UseConcMarkSweepGC：手动设置，年轻代自动使用ParNewGC
-XX:CMSlnitiatingOccupanyFraction：达到什么情况使用CMS
-XX:+UseCMSCompactAtFullCollection：是否在下次GC前，整理内存
-XX:CMSFullGCsBeforeCompaction：执行几次后，对内存进行压缩
-XX:ParallelCMSThreads：设置CMS的线程数

jdk9之后，GMS已经开始废弃了，jdk14，已经删除GMS了。

小结：

最小化使用内存和并行开销-Serial GC
最大化的吞吐量-Parallel GC
最小的STW-CMS GC + ParaNew GC

5、G1回收器：区域划分代式、并发、最大吞吐量下降低延迟时间

G1诞生的原因，随着应用负载越来越高，硬件水平越来越高，GC在不断的优化，G1诞生了。在延迟可控的情况下获得尽可能高的吞吐量，所以才能才维全能收集器。

并行回收器，把内存分割成不同的区域（Region，物理上可以不连续），使用不同的Region表示Eden、s1、s0、老年代等
G1有计划的避免了在整个java堆中进行垃圾回收，维护一个Region列表，优先回收价值最高的（回收获得的空间和花费的时间）
由于这种侧重区域垃圾回收，命名为Grabage First - G1
适合多核CPU和大容量内存机器，JDK8 需要开启参数 +XX:UseG1GC，现在就是G1的下了，JDK9之后都是默认回收器

优势

并行和并发
- 并行：多个GC线程同时工作，会出现STW
- 并发：可以和用户线程一起运行，不会出现整个应用停顿的情况
分代收集
- 会区分新生代、老年代针对不同的进行不同的操作，可以物理不连续
- 同时兼顾新生代、老年代的垃圾回收
空间整合
- 每个Region是复制算法，整体看是标记-压缩，有利于程序长时间运行，堆很大的时候很适合G1
可预测的停顿时间模型
- 可以在M时间内，在GC上消耗N
- 由于分区，这样可以缩小了回收范围，因此对于全局的SWT可控
- 相对CMS，最好的情况G1可能没办法做到，但是最差的情况要好很多