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的目标：

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

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

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

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

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

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

源码查看：

4.4、GC标记过程

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能够在读取对象引用时，将访问重定向到新位置，以确保对象的访问仍然有效。如下图：每次读取引用时会触发一次读屏障

5、GC全流程示意图

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

6、GC日志分析

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

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

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=<number>)。ZGC 具有启发式方法来自动选择此数字。这种启发式方法通常效果很好，但根据应用程序的特性，可能需要进行调整。该选项本质上决定了应该为 GC 提供多少 CPU 时间。给予太多，GC 将从应用程序中窃取过多的 CPU 时间。如果设置太少，应用程序分配垃圾的速度可能会快于 GC 收集垃圾的速度。

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

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