你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

京东云开发者
• 阅读 283

1、前言

不要犹豫了,GC最大停顿时间小于1ms,支持16TB内存,这么高的性能提升,也不需要复杂的调优,节省了这个时间,你去陪对象不香嘛。

上篇文章给大家带来了JDK11升级JDK17的最全实践,相信大家阅读后对于升级JDK17有了基本的了解。同时我们也会比较好奇,ZGC的原理是啥样的,怎么做到停顿时间那么短? 本文将通过对比ZGC与传统垃圾回收器的改动点,从多个维度综合分析为什么ZGC的停顿时间那么短。同时由于ZGC的深层次原理可能较为晦涩难懂,本文将尽可能采用图文并茂的方式,以使大家更容易理解ZGC的核心原理。

2、ZGC是什么

ZGC垃圾收集器( Z Garbage Collector )是一种可伸缩的低延迟垃圾收集器,ZGC 可以很好地处理从几百兆字节到16TB堆大小空间的垃圾回收,而中断应用程序线程的时间不超过1ms。特别适合需要低延迟的应用,同时暂停时间与正在使用的堆大小无关。。

ZGC 最初作为 JDK 11 中的实验性功能引入,并在 JDK 15 中宣布生产就绪。

ZGC的技术特点:

•并发

•基于分区的,不再是传统的分代模型,JDK21开始支持分代

•自动整理内存

•支持NUMA,Non-Uniform Memory Access(非一致内存访问)

•染色指针,将GC标识信息存储在指针上的技术

•读屏障,读取的时候去更新对象的指针引用关系

ZGC的目标:

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

3、有了G1,为什么还要引入ZGC

G1垃圾收集器采用了部分区域回收的处理方式,有效解决了传统垃圾收集器中全堆扫描所带来的性能问题,极大地改善了在堆内存较大情况下的停顿时间。然而,随着硬件性能的不断提升,G1回收器也面临着极大的性能限制。尽管G1经过多个版本的优化和调优,已经接近极限,但仍然无法满足日益增长的机器内存需求。

说到底,G1的性能还是不能满足现阶段的硬件配置,G1的GC停顿时间相对较长,比如我上篇文章中的压测报告中,G1的最大停顿时间达到了610ms

4、ZGC为什么那么快?

4.1、分代模型和分区模型

传统的垃圾回收器都采用分代的垃圾回收模型。新一代ZGC采用分区模型(类似于G1),分为三种类型的分区(2MB、32MB、N*2MB),从JDK21开始支持分代模型

低延迟:

ZGC的分页模型允许并发地处理内存分配和回收操作,从而减少了垃圾收集的停顿时间。相比之下,分代模型需要在不同代之间进行对象的复制或移动,可能会导致更长的停顿时间。

内存利用率高:

ZGC的分页模型可以动态地调整页的大小,以适应不同大小的对象。这样可以提高内存的利用率,减少内存碎片的产生。而分代模型中,不同代的内存空间是固定的,可能会导致内存碎片的问题。

可伸缩性:

ZGC的分页模型允许将堆内存划分为多个页区,并且每个页区都有独立的垃圾收集线程。这样可以实现垃圾收集的并行性,提高系统的可伸缩性和吞吐量。而分代模型中,不同代的垃圾收集是串行或并发-串行的,可能无法充分利用多核处理器的性能。

适应大内存堆:

ZGC的分页模型可以有效地管理大内存堆。它可以根据需要动态地增加或减少页的数量,以适应大内存堆的需求。而分代模型中,不同代的内存空间是固定的,无法有效地管理大内存堆。

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

4.2、GC标记信息位置的变化

传统垃圾回收器通过扫描堆中的对象(扫描堆空间是很慢的),根据对象头中的可达性标记信息,来确定对象是否应该被回收。

ZGC不直接依赖于对象头中的信息来进行垃圾回收决策,而是把GC信息存在内存引用地址上。GC时通过扫描栈上的内存引用指针来确定对象的引用关系和可达性,从而来判断对象是否应该被回收。

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

4.3、引用指针的变化-指针着色

ZGC通过64位指针(64位操作系统才支持)的高位来标识对象的可达性,其中第44位到47位标识GC信息

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

源码查看:

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

4.4、GC标记过程

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

1、初始标记

扫描所有线程栈的根节点,然后再扫描根节点直接引用的对象并进行标记。这个阶段需要停顿所有的应用线程(STW),但由于只扫描根对象直接引用的对象,所以停顿时间很短。停顿时间高度依赖根节点的数量,从JDK16开始,已经解决了此问题:https://malloc.se/blog/zgc-jdk16

2、并发标记/并发对象重定位

第1个GC周期:并发遍历上一次标记下引用的对象并标记。

第2个GC周期:并发遍历的过程中,顺便把上周期"并发迁移"阶段迁移的对象指针修正指向到新分区。

3、标记结束/再标记

标记上一次标记过程新产生的对象。并发标记过程中,应用线程可能会产生一些新对象,所以需要再标记出来。这个阶段需要停顿所有的应用线程。(STW),但由于只标记新增的对象,数量很少,所以停顿时间很短。

4、并发转移准备

为对象转移做一些前置准备,比如引用处理、弱引用清理和重定位集选择等。

5、转移开始/初始转移

迁移根节点直接引用的对象到新分区,这个阶段需要停顿所有的应用线程(STW),但由于只迁移根节点直接引用的对象,所以停顿时间很短。

6、并发迁移

并发迁移“并发标记”阶段标记的对象到新分区(对象引用指针未修改,仍指向旧分区)。

4.5、几个问题说明

1、为何并发转移阶段,对象已转移至新分区后,却没有修改线程栈上实际的引用,依然指向旧分区?

因为如果此时再扫描线程栈,修改引用地址,要扫描的量太大,效率太低。

刚好下一个GC周期也要进行扫描标记,可以利用扫描标记的时间,同时把对象引用修正指向到新分区,以此提升效率,减少停顿时间

2、并发转移阶段对象已迁移,但引用指针仍指向旧分区,如何保证旧分区被清理后对象仍然可以访问?

•由于未修改对象引用指针,为防止旧分区被清理,导致对象找不到的问题,此处引入了读屏障和转发表

•转发表记录了对象从旧位置到新位置的映射关系,实现类似一个hash表,key是旧分区的位置,value是新分区的位置,此时当访问旧位置的对象时,通过转发表可以获取新位置。这样可以避免在整个堆空间中更新对象引用的开销,因为只需要更新转发表中的条目即可。

•读屏障的作用是在读取对象引用时,检查对象的标记状态并获取转发表中的映射关系。通过读屏障,ZGC能够在读取对象引用时,将访问重定向到新位置,以确保对象的访问仍然有效。如下图:每次读取引用时会触发一次读屏障

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

5、GC全流程示意图

此示意图依据JDK11的ZGC理念绘制,尽管在JDK11至JDK17的多个版本迭代过程中,部分技术实现或许发生了变动,然而核心原理依旧保持不变。

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

6、GC日志分析

下面是我压测过程的GC日志,【STW】表示暂停业务线程执行GC,【并发】表示不暂停业务线程并发执行GC,可以看到STW停顿时间很短

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

我们再把上面的关键日志贴到到GC示意图中来分析实际的GC过程,可以发现总停顿时间只有0.07ms,符合官方说的小于1ms

你还在“垃圾”调优?快来看看JDK17的ZGC如何解放双手 | 京东云技术团队

7、ZGC如何调优

结论: 1、ZGC 被设计为自适应且需要最少的手动配置。在 Java 程序执行期间,ZGC 通过调整代大小、扩展 GC 线程数量以及调整保有阈值来动态适应工作负载。主要的调整旋钮是增加最大堆大小。 2、不再需要调整–Xmn、–XX:TenuringThreshold 和–XX:ConcGCThreads(动态调整,JDK17开始)等 3、只需要设置:–Xmx -XX:+UseZGC

7.1、设置堆大小

ZGC 最重要的调整选项是设置最大堆大小,您可以使用-Xmx命令行选项进行设置。由于 ZGC 是并发收集器,因此您必须选择最大堆大小,以便堆可以容纳应用程序的实时集,并且堆中有足够的空间以允许在 GC 运行时处理分配。需要多少空间很大程度上取决于分配率和应用程序的实时设置大小。一般来说,给 ZGC 的内存越多越好。但同时,浪费内存也是不可取的,因此关键在于在内存使用量和 GC 需要运行的频率之间找到平衡。

7.2、设置并发GC线程

不需要特意设置GC线程数,程序会自动调整。

我们可能想要考虑的第二个调整选项是设置并发 GC 线程的数量 ( -XX:ConcGCThreads=)。ZGC 具有启发式方法来自动选择此数字。这种启发式方法通常效果很好,但根据应用程序的特性,可能需要进行调整。该选项本质上决定了应该为 GC 提供多少 CPU 时间。给予太多,GC 将从应用程序中窃取过多的 CPU 时间。如果设置太少,应用程序分配垃圾的速度可能会快于 GC 收集垃圾的速度。

从 JDK 17 开始,ZGC 动态扩展和缩减并发 GC 线程数。这使得您更不需要调整 GC 线程的并发数量。

一般来说,如果低延迟(即低应用程序响应时间)对您的应用程序很重要,那么永远不要过度配置您的系统。理想情况下,您的系统的 CPU 利用率不应超过 70%。

7.3、ZGC特有参数配置

正如我上面说的,大部分情况的都不需要进行调优,特殊情况设置最好结合压测情况。

-XX:ZAllocationSpikeTolerance

表示ZGC 垃圾回收器在检测到内存分配波动时的容忍度,默认50,越小越敏感,会更快地对内存分配波动做出反应,可能会导致更频繁的垃圾回收。一般不需要手动设置,应对突发流量时,可以考虑设置。

-XX:ZCollectionInterval

该参数用于设置 ZGC 的垃圾回收间隔时间。默认值为 4s,表示 ZGC 每 4 秒进行一次垃圾回收。您可以根据应用程序的性能需求和停顿时间目标进行调整。

-XX:ZProactive

该参数用于启用或禁用 ZGC 的主动模式。默认情况下,ZGC 处于主动模式,以最大程度地减少停顿时间。如果将该参数设置为 false,则 ZGC 将进入被动模式,可能会导致更长的停顿时间,但可以提高吞吐量。

-XX:UseLargePages

开启大页面,此选项依赖Linux的内核,且需要用root去开启。理论上堆内存越大,回收效率越好。

7.4、开启 GC 日志

要启用基本日志记录(每个 GC 输出一行):-Xlog:gc:gc.log

要启用对调优/性能分析有用的 GC 日志记录:-Xlog:gc:gc.log,其中 gc 表示记录包含该gc标签的所有标签组合, :gc.log 表示将日志写入名为 gc.log

8、总结

通过本文的介绍,我们大致了解了ZGC的核心原理、日志分析方法以及调优技巧。总的来说,ZGC作为一种现代化的垃圾回收器,它为大规模应用程序的性能和可用性带来了显著的提升,希望本文能帮助大家更好的理解和应用ZGC。

作者:京东科技 曲振富

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
基于Spring Cache实现Caffeine、jimDB多级缓存实战
在早期参与涅槃氛围标签中台项目中,前台要求接口性能999要求50ms以下,通过设计Caffeine、ehcache堆外缓存、jimDB三级缓存,利用内存、堆外、jimDB缓存不同的特性提升接口性能,内存缓存采用Caffeine缓存,利用WTinyLFU算法获得更高的内存命中率;同时利用堆外缓存降低内存缓存大小,减少GC频率,同时也减少了网络IO带来的性能消耗;利用JimDB提升接口高可用、高并发;后期通过压测及性能调优999性能<20ms
Wesley13 Wesley13
3年前
5G 时代,从视频互动特效技术看未来趋势
疫情期带来了在线娱乐行业的爆棚式发展,也让行业本身更加审视在交互体验上的突破价值。优酷团队开始了对互动视频体验的全新升级,升级集中体现在三个方面:直播化、游戏化、特效化。_本文根据阿里巴巴的资深算法专家李静,在云栖大会的《5G时代,优酷新型视频互动特效技术实践》的演讲整理而成,为大家分享优酷在互动视频领域的创新技术。__
Stella981 Stella981
3年前
JVM调优思路
一、jvm内存调优(Gc 和Fullgc)hotspot\Xms40m 最小堆内存\Xmx512m最大值内存\verboose:gc\XX:PrintGCDetails\XX:printGCDateStamps\Xloggc:D:/gc/gc.log调优主要调到Gc\PSYoungGen:
Stella981 Stella981
3年前
JVM性能调优详解
前面我们学习了整个JVM系列,最终目标的不仅仅是了解JVM的基础知识,也是为了进行JVM性能调优做准备。这篇文章带领大家学习JVM性能调优的知识。性能调优性能调优包含多个层次,比如:架构调优、代码调优、JVM调优、数据库调优、操作系统调优等。架构调优和代码调优是JVM调优的基础,其中架构调优是对系统影响最大的。性能调优基本上按照以下
Stella981 Stella981
3年前
JVM系列【6】GC与调优3
JVM系列笔记目录虚拟机的基础概念class文件结构class文件加载过程jvm内存模型JVM常用指令GC与调优调优前的基础概念1.吞吐量:用户代码时间/(用户代码执行时间垃圾回收时间)2.响应时间:STW越短,响应时间越好3.
sum墨 sum墨
3个月前
我有点想用JDK17了
大家好呀,我是summo,JDK版本升级的非常快,现在已经到JDK20了。JDK版本虽多,但应用最广泛的还得是JDK8,正所谓“他发任他发,我用Java8”。其实我也不太想升级JDK版本,感觉投入高,收益小,不过有一次我看到了一些使用JDK17新语法写的代
轻量灵动: 革新轻量级服务开发 | 京东云技术团队
从JDK8升级到JDK17可以让你的应用程序受益于新的功能、性能改进和安全增强。下面是一些JDK8升级到JDK17的最佳实战:
JDK11升级JDK17最全实践干货来了 | 京东云技术团队
从JDK11到JDK17,到底带来了哪些特性呢?亚毫秒级的ZGC效果到底怎么样呢?值得我们升级吗?而且升级过程会遇到哪些问题呢?带着这些问题,本篇文章将带来完整的JDK11升级JDK17最全实践。
性能加速包: SpringBoot 2.7&JDK 17,你敢尝一尝吗 | 京东物流技术团队
前言众所周知,SpringBoot3.0迎来了全面支持JDK17的局面,且最低支持版本就是JDK17,这就意味着,Spring社区将完全抛弃JDK8,全面转战JDK17。作为JAVA开源生态里的扛把子,Spring可以说是整个JAVA生态的风向标,可以说,
京东云开发者 京东云开发者
6个月前
JDK11升级JDK17最全实践干货来了
1、前言如果你仍在使用JDK8,那你是否曾经遇到过OutOfMemoryError的问题?你是否曾经为JVM的调优问题感到困扰?本篇文章将为你介绍一种能够提供百倍性能提升的垃圾回收器,也许能够解决你的问题。上篇文章给大家带来了相信大家阅读后已经对JDK11