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

71be7277db6066ae28b3c321d7170ee7.png

本文主要内容

2f9f4068678eff99cafce6f41a165a92.png


先普及三个概念:

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

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

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

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


新生代

3c1a46a7f3513d9ac5dde8e567625abe.png

Serial

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

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

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

fe53236afacbcf2ba877f7c613fab64b.png

收集过程:

11c361aa002197ee5f00ba20c940ae64.png

ParNew

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

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

b90c1254aa1a7625fd0694b791e36913.png

收集过程:

c9623b4f6f4567f6a85b3ff798654d8b.png

Parallel Scanvenge

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

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

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

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

可设置参数:

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


ff6c95da5358f80ba3992c1c349a5426.png



老年代

3c1a46a7f3513d9ac5dde8e567625abe.png

CMS=Concurrent Mark Sweep

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

回收算法:标记-清除

回收步骤:

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

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

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

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

缺点

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

d8fc6ca8c5a98f083dd72c432907a550.png

收集过程:

dd85e0cb8c624a4bf952dd48446d524c.png

serial old

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

适用场景:

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

04d85eaadf874b35975ba6fa480e6beb.png

收集过程:

dabe96b3644d16c8c977424ba5bfa9d4.png

Parallel old

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

回收算法标记-整理

适用场景

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

cfa28dbfbd67aaaaeffecc1c8e09f9dc.png

收集过程:

a685b92d943fcb00e7e6d6c6ccd91932.png

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 版本,你可以使用以下命令进行查询:

54ca09ff25227d8d950b15144d67f796.png

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毫秒。

f6dd3a6a40558895e89922de7d90cac0.png

收集过程:

caefe07833fca44f860e3d5bc18c60a2.png

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

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

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

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

02b12296cab16f46deaa73d384680bd8.png


ZGC

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

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

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

缺点浮动垃圾

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


垃圾收集器搭配关系

3c1a46a7f3513d9ac5dde8e567625abe.png



新生代收集器Serial、ParNewParallel Scavenge

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

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

3c1a46a7f3513d9ac5dde8e567625abe.png



如何选择垃圾收集器?

a718e5e2790b8b0f52de63c54faeaee5.png

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

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

    参数:-XX:+UseSerialGC

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

    参数:-XX:+UseSerialGC

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

    参数:-XX:+UseParallelGC

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

    参数:

    -XX:+UseConcMarkSweepGC

    -XX:+UseG1GC

    -XX:+UseZGC 等。

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


总结

回顾文章前面的目录

e747de9987c7813cdce4a951fc48adac.png

这几点你学会了吗?