盘点Java中的那些常用的Garbage Collector
GC总览
Java是一门面向对象的语言。在使用Java的过程中,会创建大量的对象在内存中。而这些对象,需要在用完之后“回收”掉,释放内存资源。这件事我们称它为垃圾收集(Garbage Collection,简称GC),而实际执行者就是各种各样的“垃圾收集器”(Garbage Collector,以下也简称GC)。
为什么会有各种各样的GC?因为时代在发展,以前的GC可能不能满足现在的需求,所以就会有源源不断的GC推出来。先来看一下都有哪些主流的GC:
新生代:
Serial:单线程,新生代;
ParNew: 多线程,新生代;
Parallel Scavenge:多线程,新生代,关注吞吐量;
老年代:
Serial Old: 单线程,Serial的老年代版本;
Parallel Old:多线程,Parallel Scavenge的老年代版本,关注吞吐量;
CMS:多线程,标记-清除算法,关注停顿时间,可以与Serial和ParNew配合。
其它
G1:同时负责新生代和老年代,是目前一段时间主流的垃圾收集器(JDK 9到现在JDK 16的默认垃圾收集器)。
ZGC:在大堆下也可以控制STW时间极短(几毫秒内),在JDK 11 为实验阶段,在JDK 15转正。Oracle发起,2017年贡献给OpenJDK。
Shenandoah GC:停顿时间极短,在JDK 12为试验阶段,在JDK 15转正。Red Hat发起,与ZGC和G1是竞争关系。
STW: Stop The World,指的是停止用户线程。GC应该尽量避免STW或者缩减STW的时间。
各JDK版本默认GC
下面来看一下从JDK 7开始在默认GC(JDK 7之前的,我就不考古了,现在大家项目上用的也少)。
- 在JDK 7,默认是Parallel Scavenge + Serial Old。
- 在JDK 8 及JDK 7u4之后的版本,默认是Parallel Scavenge + Parallel Old。
- 在JDK 9 到JDK 16,默认是G1
严格来说之前的版本应该是JDK 1.7, JDK 1.8,这里及下文为了表述方便,我就写成了JDK 7, JDK 8。
聊聊几种主流的GC
考虑到现在大家用的Java版本主要都是JDK 8起,所以主要聊JDK 8及之后可能会用到的GC。
Parallel Scavenge + Parallel Old
以下简称为PS,PO
PS + PO是JDK 7u4之后一直到JDK 9之前server模式都在用的默认GC组合。
PS用于新生代,是一个并行的多线程收集器,使用了复制算法。它关注吞吐量,可以通过参数设置最大GC停顿时间、吞吐量的大小等。
PS收集器相比于ParNew来说,多了一个“自适应调节策略”。当+UseAdaptiveSizePolicy这个参数打开之后,就不需要手动指定新生代的大小,Eden和Survivor区的比例,晋升老年代对象等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大吞吐量。
PO用于老年代,同样是关注吞吐量。它是一个多线程的收集器,采用“标记-整理”算法。PO是在JDK 1.6之后才提供的,目的就是为了与PS配合。在此之前,PS只能与Serial Old配合(因为框架不适配的原因,不能与CMS配合),老年代GC效率低下,所以PO应运而生。
ParNew + CMS
ParNew是一个新生代多线程收集器,使用复制算法。它的出现比PS更早,主要是为了替代Serial单线程低下的效率。在新生代复制期间,使用多线程来降低STW的时间。
CMS是JDK 5才推出的一款关注停顿时间的GC。与PO不同的是,CMS使用的是“标记-清除”算法,这能够让它实现更小的停顿时间,但代价是会产生大量的空间碎片,可能会在大对象晋升老年代时由于没有连续的内存空间,触发full gc。
了解到这里,其实我有两个疑问。
1 CMS为什么不使用“标记-整理”算法?
参考《并发垃圾收集器(CMS)为什么没有采用标记-整理算法来实现?》这篇文章(原文是在iteye的一个讨论,但现在已经找不到了)的说法。GC代码和用户代码需要保持同步,才能保证两者观察到的对象图是一致的。而保持同步有两种做法,一种是read barrier,一种是write barrier。因为读远大于写,所以CMS使用的是write barrier。这就导致CMS如果用“标记-整理”算法的话,需要在“整理”的时候STW,而如果使用“标记-清除”算法的话,在“清除”阶段是不用STW的。
2 为什么CMS从来没作为默认垃圾收集器?
参考知乎这篇文章《为什么 JDK 8 默认使用 Parallel Scavenge 收集器?》的回答。总结有三个原因:
- Java使用服务端的场景为主,服务端更专注吞吐量,所以JDK 8默认的是PS + PO;
- 使用、调优很复杂,有高达70多个参数
- “后浪”太优秀,CMS比G1早不了多少,5开始加入,6成熟,9被标记弃用,14被删除。而G1是7加入,8成熟,9正式成为默认。
然而事实上,有很多互联网大厂选择了CMS+ParNew的组合。前段时间美团出了一篇文章《Java中9种常见的CMS GC问题分析与解决》,阿里也用得比较多,所以还是可以了解一下。
G1
前面提到了,G1是一个优秀的后浪。从JDK 9到当前JDK 16一直都是默认的GC。相较于之前的几款GC来说,G1可以说是有一些颠覆性的设计,比如Region、Card Table、Remember Set等。
关于G1,需要一篇单独的文章来介绍。我之前在个人网站上有一篇文章介绍,《JVM - G1》
文章地址:https://yasinshaw.com/article...
在我的个人网站https://yasinshaw.com,文章页面搜索“G1”即可搜到。
这里大致介绍一下它的特点:
- 低延迟优先,即主要侧重于响应能力;
- 与CMS相同的地方在于,它们都属于并发收集器,在大部分的收集阶段都不需要挂起应用程序;
- 更精确的预测GC停顿时间,可以根据-XX:MaxGCPauseMillis参数指定停顿时间;
- 收缩空闲空间不会造成由长GC引起的应用停顿时间;
- G1没有CMS的碎片化问题(或者说不那么严重)。
ZGC
关于ZGC,笔者了解得也不多。ZGC在JDK 11推出实验版,在JDK 15成为正式版。ZGC的目标是在尽量不牺牲吞吐量(官方宣称,目标是对程序吞吐量影响小于15%)的情况下,做到极低的停顿时间,并且停顿时间不会随着对的内存大小变大而升高。
虽然ZGC在JDK 15已经转正,但还是在不断完善和迭代。JDK 16最近发布,在这个版本中ZGC有46 个功能增强以及25 个 bug 修复。已经可以做到平均暂停时间约为 50 微秒(0.05 毫秒),最大暂停时间约为 500 微秒(0.5 毫秒)。暂停时间不受堆、活动集和根集大小的影响。这个停顿时间,对业务的影响可以说已经微乎其微了,我等只能大呼NB。
想要深入了解ZGC原理的同学,可以参考美团技术的这篇文章《新一代垃圾回收器ZGC的探索与实践》(只找到知乎官方号的链接)。
Shenandoah GC
按理说G1和ZGC已经很牛逼了,为什么还有其它的GC出来?学不动了啊,有木有。。。
Shenandoah GC,我们称它为SGC吧,它是Red Hat发起的一款GC,与ZGC是竞争关系。Shenandoah更像是G1的继承者,有很多相同之处。它跟ZGC一样,目标也是低停顿时间,不过实现原理有些不同,ZGC是基于colored pointers来实现,而Shenandoah GC是基于brooks pointers来实现。
SGC没有承诺停顿时间小于10ms,也没有说要牺牲吞吐量(但实际吞吐量有没有降低就不知道了)。在官方的性能测试图来看,停顿时间也是极低的。
GC(3) Pause Init Mark 0.771ms
GC(3) Concurrent marking 76480M->77212M(102400M) 633.213ms
GC(3) Pause Final Mark 1.821ms
GC(3) Concurrent cleanup 77224M->66592M(102400M) 3.112ms
GC(3) Concurrent evacuation 66592M->75640M(102400M) 405.312ms
GC(3) Pause Init Update Refs 0.084ms
GC(3) Concurrent update references 75700M->76424M(102400M) 354.341ms
GC(3) Pause Final Update Refs 0.409ms
GC(3) Concurrent cleanup 76244M->56620M(102400M) 12.242ms
它只有在标记和更新引用的时候会暂停,看起来也是只有几毫秒的停顿时间。
总结一下
现在市面上很大一部分Java程序都还是基于Java 8(甚至有些是Java 7的),所以PS + PO,和ParNew + CMS都是可以了解一下的,毕竟工作中很有可能会用到。尤其是CMS,大厂用得很多,面试基本上必问。
ZGC和SGC,虽然在JDK 15都已经成为正式版,但实际生产中使用很少,有些潜在问题不一定能很好地发现,可以慢慢去了解和尝试。
可以预见的是,G1会在未来很长一段时间内成为最主流的垃圾收集器,所以很有必要好好了解一下G1,做好知识储备。
我是Yasin,一个坚持技术原创的博主