vlambda博客
学习文章列表

JVM真香系列:图解垃圾回收器

关注Java后端技术全栈

回复“000”获取大量电子书


不知不觉,JVM系列已经到回收算法的实现了。

本文主要内容

JVM真香系列:图解垃圾回收器


先普及三个概念:

并行收集:指多条垃圾收集线程并行工作,但此时用户线程仍处于等待状态。

并发收集:指用户线程与垃圾收集线程同时工作(不一定是并行的可能会交替执行)。用户程序在继续运行,而垃圾收集程序运行在另一个CPU上。

吞吐量:即CPU用于运行用户代码的时间与CPU总消耗时间的比值(吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 ))。

例如:虚拟机共运行100分钟,垃圾收集器花掉1分钟,那么吞吐量就是99%。


新生代

JVM真香系列:图解垃圾回收器

Serial

Serial收集器是最基本、发展历史最悠久的收集器,曾经(在JDK1.3.1之前)是虚拟机新生代收集的唯一选择。

它是一种单线程收集器,不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更重要的是其在进行垃圾收集的时候需要暂停其他线程。

优点:简单高效,拥有很高的单线程收集效率
缺点:收集过程需要暂停所有线程
算法:复制算法
应用:Client模式下的默认新生代收集器

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

ParNew

可以把这个收集器理解为Serial收集器的多线程版本。

优点:在多CPU时,比Serial效率高。
缺点:收集过程暂停所有应用程序线程,单CPU时比Serial效率差。
算法:复制算法
应用:运行在Server模式下的虚拟机中首选的新生代收集器

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

Parallel Scanvenge

Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器,看上去和ParNew一样,但是Parallel Scanvenge更关注系统的吞吐量 。

吞吐量 = 运行用户代码的时间 / (运行用户代码的时间 + 垃圾收集时间)

比如虚拟机总共运行了120秒,垃圾收集时间用了1秒,吞吐量=(120-1)/120=99.167%。

若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序的运算任务。

可设置参数:

-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间,
-XX:GC Time Ratio直接设置吞吐量的大小。


JVM真香系列:图解垃圾回收器



老年代

JVM真香系列:图解垃圾回收器

CMS=Concurrent Mark Sweep

特点:最短回收停顿时间,

回收算法:标记-清除

回收步骤:

  1. 初始标记:标记GC Roots直接关联的对象,速度快

  2. 并发标记:GC Roots Tracing过程,耗时长,与用户进程并发工作

  3. 重新标记:修正并发标记期间用户进程运行而产生变化的标记,好事比初始标记长,但是远远小于并发标记

  4. 表发清除:清除标记的对象

缺点:

对CPU资源非常敏感,CPU少于4个时,CMS岁用户程序的影响可能变得很大,由此虚拟机提供了“增量式并发收集器”;无法回收浮动垃圾;采用标记清除算法会产生内存碎片,不过可以通过参数开启内存碎片的合并整理。

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

serial old

Serial Old收集器是Serial收集器的老年代版本,也是一个单线程收集器,不同的是采用"标记-整理算法",运行过程和Serial收集器一样。

适用场景:

JDK1.5前与Parallel Scanvenge配合使用,作为CMS的后备预案。

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

Parallel old

Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多线程和"标记-整理算法"进行垃圾回收,吞吐量优先。

回收算法:标记-整理

适用场景:

为了替代serial oldParallel Scanvenge配合使用。

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

G1=Garbage first

JDK 9 开始,JVM 的默认垃圾回收器就从 Parallel GC 调整为 G1并且开始全面废除 CMS

限制或者减少 GC 停顿时间相比系统吞吐量而言更加重要,从 PGC 切换至低延迟的 G1 能够为大部分用户带来更好的体验。G1 的性能在 JDK 8 以及后续的 release 版本都得到了极大的优化,G1 是一个具备所有 GC 特性的垃圾回收器,因此将 G1 设置为 JVM 默认的 GC。

根据 JEP-291 中的说明,为了减轻 GC 代码的维护负担以及加速新功能开发,决定在 JDK 9 中废弃 CMS GC。

从 Java 9 开始,如果您使用 

-XX:+UseConcMarkSweepGC

(激活 CMS GC 算法的参数)参数启动应用程序,则会在下面显示警告消息:

Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.

如果你想知道当前应用对应的 JVM 版本,你可以使用以下命令进行查询:

JVM真香系列:图解垃圾回收器

G1将整个JVM堆划分成多个大小相等的独立区域regin,跟踪各个regin里面的垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许的收集时间,优先回收最大的regin当然还保留有新生代和老年代的概念,但新生代和老年代不在是物理隔离了,他们都是一部分regin集合。

内存“化整为零”的思路:GC根节点的枚举范围汇总加入remembered set 即可保证不对全堆扫面也不会遗漏。

回收步骤:

  1. 初始标记:标记GC Roots直接关联的对象

  2. 并发标记:对堆中对象进行可达性分析,找出存活对象,耗时长,与用户进程并发工作

  3. 最终标记:修正并发标记期间用户进程继续运行而产生变化的标记

  4. 筛选回收:对各个regin的回收价值进行排序,然后根据期望的GC停顿时间制定回收计划

G1收集器优势

并行与并发:G1能充分利用多CPU、多核环境下的硬件优势,使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作,G1收集器仍然可以通过并发的方式让Java程序继续运行。

分代收集:G1能够独自管理整个Java堆,并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合:G1运作期间不会产生空间碎片,收集后能提供规整的可用内存。

可预测的停顿:G1除了追求低停顿外,还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内,消耗在垃圾收集上的时间不得超过N毫秒。

JVM真香系列:图解垃圾回收器

收集过程:

JVM真香系列:图解垃圾回收器

G1的回收过程主要分为 3 类:

(1)G1“年轻代”的垃圾回收,同样叫 Minor G1,这个过程和我们前面描述的类似,发生时机就是 Eden 区满的时候。

(2)老年代的垃圾收集,严格上来说其实不算是收集,它是一个“并发标记”的过程,顺便清理了一点点对象。

(3)真正的清理,发生在“混合模式”,它不止清理年轻代,还会将老年代的一部分区域进行清理。

JVM真香系列:图解垃圾回收器


ZGC

ZGC(Z Garbage Collector)是一款由Oracle公司研发的,以低延迟为首要目标的一款垃圾收集器。它是基于动态Region内存布局,(暂时)不设年龄分代,使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的收集器。

JDK 11新加入,还在实验阶段,主要特点是:回收TB级内存(最大4T),停顿时间不超过10ms。

优点:低停顿,高吞吐量,ZGC收集过程中额外耗费的内存小

缺点:浮动垃圾

目前使用的非常少,真正普及还是需要写时间的。


垃圾收集器搭配关系

JVM真香系列:图解垃圾回收器



新生代收集器:Serial、ParNewParallel Scavenge

老年代收集器:CMS、Serial Old、Parallel Old

整堆收集器:G1ZGC(因为不涉年代不在图中)

JVM真香系列:图解垃圾回收器



如何选择垃圾收集器?

JVM真香系列:图解垃圾回收器

前面我们已经介绍完八种垃圾收集器。那么我在真实场景中应该如何去选择呢,下面给出几种建议,希望对你有帮助:

  1. 如果你的堆大小不是很大(比如 100MB),选择串行收集器一般是效率最高的。

    参数:-XX:+UseSerialGC

  2. 如果你的应用运行在单核的机器上,或者你的虚拟机核数只有单核,选择串行收集器依然是合适的,这时候启用一些并行收集器没有任何收益。

    参数:-XX:+UseSerialGC

  3. 如果你的应用是“吞吐量”优先的,并且对较长时间的停顿没有什么特别的要求。选择并行收集器是比较好的。

    参数:-XX:+UseParallelGC

  4. 如果你的应用对响应时间要求较高,想要较少的停顿。甚至 1 秒的停顿都会引起大量的请求失败,那么选择G1ZGCCMS都是合理的。虽然这些收集器的 GC 停顿通常都比较短,但它需要一些额外的资源去处理这些工作,通常吞吐量会低一些。

    参数:

    -XX:+UseConcMarkSweepGC

    -XX:+UseG1GC

    -XX:+UseZGC 等。

从上面这些出发点来看,我们平常的 Web 服务器,都是对响应性要求非常高的。选择性其实就集中在 CMSG1ZGC上。而对于某些定时任务,使用并行收集器,是一个比较好的选择。


总结

回顾文章前面的目录

这几点你学会了吗?


推荐阅读:




免费获取500G最新学习资料