JVM垃圾收集器(三) ------ 垃圾回收器（一）

垃圾回收器分类

按照线程数分

• • 串行垃圾回收器

• • 同一段时间内只允许一个CPU执行垃圾回收的操作， 此时工作线程暂停，直至垃圾收集工作结束
• • 单CPU或者较小的应有等内存硬件平台不是特别优越的场合，串行回收器的表现就可以超过所并行回收器和并发回收器
• • 串行回收器默认应有在客户端的Client模式下面的JVM中

• • 并行垃圾回收器 ------- 运用多个CPU同时执行垃圾回收，因此提升了吞吐量

两个的相同特点:都采用了独占试，会产生STW

图示：

按照工作模式分

• • 并发式垃圾回收器 与引用线程交替工作,尽可能减少应用程序的停顿时间
• • 独占式垃圾回收器 垃圾收集线程一旦执行， 就停止应用程序中的所有用户线程，直到垃圾收集过程结束

图示：

按照碎片分

• • 压缩式垃圾回收器

• • 对存活的对象进行压缩整理，消除回收后的碎片 ------ 再分配对象的空间使用:指针碰撞

• • 非压缩式垃圾收集器

• • 不进行空间整理 ------ 分配对象使用的方式:空闲列表

工作的内存分

• • 老年代垃圾收集器
• • 年轻代垃圾回收器

GC评估指标

衡量垃圾收集器的三项最重要的指标是:内存占用(Footprint)、吞吐量(Throughput)和延迟(Latency)，三者共同构成了一个“不可能三角。

• • 吞吐量:运行的用户代码时间占总时间的比例
• • 垃圾收集的开销:吞吐量的补数，垃圾收集的时间和总运行时间的比例
• • 暂停时间:垃圾收集时程序的工作线程被暂停的时间
• • 收集频率:相对于应用程序的执行，收集操作发生的频率
• • 内存占用: Java堆所占的内存大小
• • 快速:垃圾从收集到被回收所经历的时间

在设计GC算法时，我们必须明确自己的目标，针对于吞吐量和暂停时间，我们只能取一个， 现在最大的目标就是最大吞吐量优化的情况下，降低停顿时间。

垃圾收集器

垃圾收集器与他们的搭配规则：

image-20210716141200120

• • 两个收集器之间有连线，表明他们可以搭配使用

• • Serial/Serial Old、Serial/CMS、ParNaw/Serial Old、Serial/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1

• • 其中Serial Old作为CMS出现“Concurrent Mode Failure”失败的后背预案
• • (红色虚线)由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、ParNew+Serial Old这两个组合声明为废弃(JEP 173)，并在JDK 9中完全取消了这些组合的支持(JEP214) ， 即:移除。
• • (绿色虚线)JDK 14中:弃用Parallel Scavenge和Serial Old GC组合(JEP366)
• • (青色虚线)JDK 14中:删除CMS垃圾回收器 (JEP 363 )

串行的垃圾收集器

图示：

image-20210716150452591

Serial（年轻代）

• • 串行回收
• • 最基本，历史最悠久的收集器
• • HotSpot中Client模式下默认的新生代垃圾收集器
• • 采用复制算法、串行回收和STW机制的方式内存回收

迄今为止，它依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器，有着优于其他收集器的地方，那就是简单而高效(与其他收集器的单线程相比)，所以Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。

Serial Old（老年代）

• • 串行回收和STW机制
• • 内存回收算法使用的是标记压缩算法
• • 运行在client模式下的默认老年代垃圾回收器
• • 在service模式下的两个用途

• • 与新生代的Parallel Scavenge配合使用
• • 作为老年代CMS垃圾收集的后背方案

作用：

• • 供客户端模式下的HotSpot虚拟机使用
• • 服务器端的模式下：

• • 在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用
• • 作为CM S 收集器发生失败时的后备预案，在并发收集发生Concurrent M ode Failure时使用。

Serial和Serial Old总结：

是一个单线程的垃圾回收器，该单线程指的不只是使用一个CPU,而且在运行的时候会产生STW

优势：

• • 简单而高效
• • 在client模式下是一个不错的选择

XX: +UserSerialGC指定年轻代和老年代都使用串行回收收集器

总结：

• • 单核CPU时候使用
• • 一般javaweb引用不会采用串行垃圾收集器的
• • 单CPU的情况下，他比并行垃圾收集器更高效

并行的垃圾收集器

ParNew（年轻代）

ParNew收集器实质上是Serial收集器的多线程并行版本

• • 并行回收
• • 在多CPU、多核等情况下，可以更快速的完成垃圾收集，提升程序的吞吐量
• • 目前，除了Serial外，就只有ParNew能和CMS收集器配合工作
• • -XX: +UserParNewGC手动设置

图示：

parallel Scavenge（年轻代）

目标：达到一个可控制的吞吐量(Throughput)。

吞吐量=运行用户代码时间/（运行用户代码时间+运行垃圾收集时间）

特点：

• • 吞吐量优先
• • 采用了复制算法，并行回收，stw机制
• • 和ParNew不同，Parallel收集器目标是达到一个可控的吞吐量，他也被称之为吞吐量优先的垃圾收集器
• • 比起ParNew新添加了自适应策略
• • 高吞吐量可以有效的利用CPU时间，尽快的完成运算任务，主要适合在后台运算而不需要太多交互的任务，因此，在常见的服务器中使用

图示：

parallel Old（老年代）

特点：

• • 采用标记压缩算法、并行回收，stw机制
• • 与Parallel组合是Java8中的默认组合
• • -XX: +UserAdapttiveSizePolicy 设置收集器的自适应调节策略

• • 这种模式下年轻代大小、Eden和Survivor的比例会被自动调整
• • 在手动调比较困难的时候可以考虑使用该方式

• • -XX: MaxGCPauseMllis 设置垃圾收集器最大停顿时间(STW停顿时间) ------ 该参数使用该谨慎
• • -XX:GCTimeRatio垃圾收集时间占总时间的比例

在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组 合。

并发垃圾回收器

CMS（老年代）

JDK 5发布时，HotSpot推出了一款在强交互应用中几乎可称为具有划时代意义的垃圾收集器 —— CMS收集器

特点：

• • 低延迟
• • 第一次让垃圾收集线程和用户线程同时工作
• • CMS的垃圾收集算法采用了标记清除算法，并且也会STW
• • 在1.4无法与Parallel配合工作

工作原理：

• • 初始标记

• • 该阶段会产生stw的短暂暂停
• • 该阶段仅仅是标记出GCRoot直接关联的对象
• • 仅仅只是标记一下GC Roots能直接关联到的对象，速度很快(因此stw时间非常短)

• • 并发标记

• • 从GCRoot的直接关联对象开始遍历整个对象图的过程

• • 该过程耗时长但是不需要停顿用户线程，可以与垃圾收集线程一起并发执行

• • 重新标记

• • 由于并发标记阶段，程序的工作线程会和垃圾收集线程同时运行或者交叉执行，因此该时期，修正并发标记时期，因为用户程序运作而导致标记产生变动的哪一部分对象的标记记录

• • 该阶段停顿时间通常会比初始标记阶段长一些但是远比标记阶段的短

• • 并发清除

• • 清除标记阶段已经判定为死亡岛饿对象，释放空间

• • 由于不需要移动存活的对象，所以这阶段也是可以与用户线程并发的

图示：

整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一 起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的

优点：

• • 采用并发回收(非独占式)，在初始标记和再次标记仍需要执行stw,但是暂停时间不会过长
• • 由于耗费时间的并发标记与并发清除阶段都不需要暂停工作,所以整体回收是低停顿的

缺点：

• • 在CMS回收过程中，由于用户线程还没有中断，所以应该确保用户线程有足够的内存可用
• • 所以当堆达到某一阈值的时候便开始垃圾回收
• • 采用的是标记清除算法，所以回收结束之后难免会产生一些内存碎片， 所以新对象分配空间的时候只能选择内存分配

图示：

注意：采用Mark Sweep会造成内存碎片，为什么不使用Mark Compact呢?并发清除的时候，用compact整理内存的话，会导致内存位置发生变化，要保证用户线程能够继续执行，就要保证运行时对象地址不变。

• • CMS收集器对CPU资源非常敏感
• • CMS无法处理浮动垃圾 ------ 在并发阶段如果产生了新的垃圾对象，CMS无法对这些垃圾对象进行标记，最后导致这些垃圾对象没有被及时回收

总结：

• • 如果想要最小化的使用内存和并行开销 ------ Serial GC
• • 如果想要最大化的应用程序吞吐量 ------ Parallel GC
• • 如果想要最小化GC中断或者停顿时间 ------ CMS GC

JDK后续变化：

• • JDK9被标记为Deprecate
• • JDK14删除了CMS垃圾回收器

JDK 9及以上版本的HotSpot虚拟机使用 参数-XX:+UseConcM arkSweep GC来开启CM S收集器的话，用户会收到一个警告信息，提示CM S未 来将会被废弃