Java ZGC是什么？ZGC垃圾回收器原理及参数配置详解

Java ZGC（Z Garbage Collector）是一款面向低延迟场景设计的垃圾回收器，核心目标是在较大 Java Heap 下尽可能降低 GC 对应用线程的停顿影响。随着 Java 应用逐渐从传统中小型业务发展到高并发、实时计算、大数据处理、缓存服务和大型微服务系统，GC 延迟已经成为影响应用响应速度的重要因素。ZGC 采用并发回收、分区化堆管理、读屏障以及染色指针等技术，使大量 GC 工作可以与 Java 应用线程并行执行。Oracle 官方资料显示，ZGC 面向低延迟应用设计，其暂停时间与 Heap 大小并不呈线性增长关系，并适用于从数百 MB 到最高 16TB 的堆规模。

一、Java ZGC是什么？

1.1 ZGC的基本概念：ZGC 全称为 Z Garbage Collector，是 HotSpot JVM 中面向低延迟场景的垃圾回收器。与传统 GC 主要依靠 Stop-The-World（STW）完成大量回收工作不同，ZGC 将标记、重定位等耗时操作尽可能放到并发阶段执行，让应用线程和 GC 线程同时运行，从而降低 GC 对业务请求的影响。

ZGC 特别适合对响应时间敏感的 Java 应用，例如大型互联网网站、交易系统、实时数据处理、消息服务、游戏后台、搜索服务、缓存服务以及高并发 API 服务等。如果应用更关注吞吐量而不是延迟，G1、Parallel GC 等垃圾回收器也可能更加合适，因此不能简单认为 ZGC 在所有业务中都优于其他 GC。

1.2 ZGC的主要特点：ZGC 的设计重点可以概括为“低延迟、并发回收、自动调节和大堆支持”。Oracle 官方文档指出，ZGC 的昂贵 GC 工作主要以并发方式执行，应用线程停顿通常可以控制在毫秒级甚至更低，同时 GC 暂停时间不会随着 Heap 增大而按照传统方式明显增加。

• 低延迟：重点降低 GC 停顿对业务线程的影响。
• 并发回收：大量 GC 工作与 Java 应用线程并行执行。
• 支持大堆：官方资料显示 ZGC 可支持最高 16TB Heap。
• 自动调优：JVM 会根据运行负载动态调整部分 GC 行为。
• 内存归还：可以将暂时不用的 Heap 内存归还操作系统。
• 分代回收：现代 JDK 中的 ZGC 已采用 Generational ZGC。

二、ZGC的发展及Generational ZGC

2.1 ZGC从实验特性走向生产：ZGC 最初作为低延迟垃圾回收方案进入 OpenJDK，随后逐渐成为生产环境可使用的重要 GC。JDK 15 中 ZGC 成为正式生产特性，而 JDK 21 又引入了 Generational ZGC。JEP 439 对 Generational ZGC 的目标包括降低 Allocation Stall 风险、减少所需 Heap 内存开销以及降低 GC CPU 开销。

2.2 JDK 21中的Generational ZGC：如果使用 JDK 21，在开启 ZGC 后可以通过 -XX:+ZGenerational 启用分代模式，即使用 -XX:+UseZGC -XX:+ZGenerational。官方资料指出，Generational ZGC 通过区分新生对象和老对象，提高垃圾回收效率，尤其适合对象创建速度较高、短生命周期对象较多的应用。

2.3 新版本配置注意事项：需要特别注意 JDK 版本差异。JDK 21时代需要显式关注 ZGenerational 参数，而较新的 JDK 已经将分代 ZGC 作为默认方向。Oracle 当前资料指出，JDK 24 起非分代 ZGC 已被移除，因此在部署新项目时，应优先根据实际 JDK 版本选择对应参数，而不能直接照搬旧版 ZGC 教程。

三、ZGC垃圾回收器原理详解

3.1 Region分区化Heap管理：ZGC 并不是按照传统连续的新生代、老年代方式简单管理整个 Java Heap，而是将 Heap 划分为大量可独立管理的内存区域。对象根据生命周期和内存管理策略被放置在不同区域中，GC 可以针对需要回收的区域进行处理。

这种设计使 ZGC 更容易处理大规模 Heap，并且能够将内存回收过程拆分为多个阶段进行。对于拥有几十 GB、甚至更大 Heap 的 Java 服务来说，这种设计能够降低单次 GC 对应用线程造成的影响。

3.2 并发标记：垃圾回收首先需要判断哪些对象仍然被程序引用。ZGC 会从 GC Roots 开始扫描对象引用关系，并在应用线程继续运行的情况下完成大量标记工作。

传统 GC 如果需要在标记过程中长时间暂停应用线程，就可能造成明显的接口延迟。例如一个 API 服务正常响应只需要几十毫秒，但一次 GC 停顿达到数百毫秒，就可能造成请求堆积。ZGC 的核心思路就是把大量工作放到并发阶段，从而降低这种长时间停顿风险。

3.3 染色指针：Colored Pointers（染色指针）是 ZGC 的核心技术之一。简单理解，ZGC 不仅利用对象引用保存对象地址，还利用指针中的额外信息记录对象状态，从而帮助 JVM 判断对象当前的 GC 状态。

这种机制配合读屏障（Load Barrier）使用，可以让应用线程在访问对象时协助 GC 完成必要的状态处理。相比完全依赖 Stop-The-World 来完成对象状态更新，ZGC 可以将更多工作放在并发阶段。

3.4 并发重定位：传统压缩型 GC 通常需要移动对象，并在移动完成后更新大量引用关系。ZGC 将对象重定位过程设计成高度并发的过程，并通过指针处理机制解决对象地址发生变化的问题。

因此，ZGC 的核心价值并不是“完全没有 STW”，而是尽可能把耗时工作放到并发阶段，使真正需要暂停 Java 应用线程的阶段保持很短。Oracle 官方文档明确将 ZGC 定义为可扩展的低延迟垃圾回收器，并指出其暂停时间与 Heap 大小无关。

四、ZGC完整垃圾回收流程

4.1 GC Roots处理：JVM 首先处理 GC Roots，包括线程栈、静态变量、JNI 引用等能够直接或间接访问 Java 对象的引用。这个阶段需要非常短的停顿，但大量后续工作会进入并发阶段。

4.2 并发标记：GC 线程继续扫描对象图，将仍然存活的对象进行标记。与此同时，Java 应用线程仍然可以正常执行，这也是 ZGC 实现低延迟的重要基础。

4.3 引用处理：对于软引用、弱引用、虚引用等特殊引用，ZGC 会在 GC 周期中进行相应处理，从而确定哪些对象可以被回收。

4.4 并发重定位：对于已经确定可以回收的内存区域，ZGC 会将仍然存活的对象移动到新的位置，并通过屏障及引用修复机制保证程序继续访问正确对象。

4.5 回收内存：完成对象处理后，原来的内存区域即可重新用于对象分配。整个过程中，大量耗时操作不需要长时间暂停业务线程，因此能够保持较低的应用延迟。

五、ZGC与G1垃圾回收器有什么区别？

5.1 定位不同：G1 的目标是兼顾吞吐量和可预测停顿，适用于大量企业级 Java 应用；ZGC 则更加关注极低延迟场景。两者都属于现代并发/分区式垃圾回收方案，但优化方向存在明显区别。

5.2 Heap规模不同：G1 可以很好地支持大型 Heap，而 ZGC 在设计之初就重点考虑大规模 Heap 下的低延迟问题。官方资料显示，ZGC 可工作在从数百 MB 到 16TB 的 Heap 范围内。

5.3 调优思路不同：G1 常见调优参数包括暂停时间目标、Region、IHOP 等，而 ZGC 更强调给 JVM 足够的 Heap 空间和 GC Headroom。Oracle 官方明确指出，对于 ZGC，最重要的调优项是 -Xmx，因为 ZGC 必须同时容纳应用 Live Set，并留出足够空间应对 GC 运行期间持续发生的对象分配。

六、Java ZGC常用参数配置详解

6.1 启用ZGC：最基础的参数是 -XX:+UseZGC，用于告诉 JVM 使用 ZGC。现代 JDK 中应结合具体版本确认 Generational ZGC 的默认行为。Oracle 当前文档将 -XX:+UseZGC 作为 ZGC 的启用参数。

6.2 设置-Xms与-Xmx：-Xms表示 JVM 初始 Heap，-Xmx表示 JVM 最大 Heap。例如服务器拥有 32GB 物理内存，可以根据应用实际内存需求规划 16GB、20GB 或 24GB Heap，而不是简单将全部物理内存分配给 Java。

例如：

-Xms16g -Xmx16g

对于稳定运行的服务器程序，将 Xms 与 Xmx 设置为相同值是一种常见方案，可以减少 Heap 动态扩展带来的变化。OpenJDK 的 ZGC 调优资料也建议在追求稳定性能时考虑将初始 Heap 与最大 Heap 设置为相同值。

6.3 SoftMaxHeapSize：如果希望 JVM 平时控制在一个较低 Heap 水平，同时允许在业务高峰期临时扩大，可以使用 -XX:SoftMaxHeapSize。例如 -Xmx8g -XX:SoftMaxHeapSize=6g，意味着 6GB 可以作为软目标，但 JVM 在必要时仍然能够使用到 8GB。Oracle 官方资料明确说明，超过 SoftMaxHeapSize 并不是绝对禁止，而是为了避免应用因 GC 无法及时回收而停顿。

6.4 ZUncommit：-XX:+ZUncommit允许 ZGC 将没有使用的 Heap 内存解除提交，从而降低 JVM 的实际内存占用。当前 Oracle 文档显示，该功能默认开启。

6.5 ZUncommitDelay：-XX:ZUncommitDelay=300用于控制未使用 Heap 保持多久后才归还操作系统，默认值为 300 秒，即 5 分钟。过度降低该值可能造成内存频繁提交和解除提交，因此生产环境不建议为了追求低内存占用而盲目修改。

6.6 ZCollectionInterval：-XX:ZCollectionInterval可以设置两次 GC 周期之间的最大时间间隔，默认值为 0，即不主动限制周期。对于特殊的低分配应用，可以结合业务特征研究该参数，但大多数情况下不需要主动设置。

6.7 ZFragmentationLimit：-XX:ZFragmentationLimit用于设置可接受的 Heap 碎片比例，Oracle 当前文档默认值为 25。降低该值会让 ZGC 更积极地进行整理，但也可能增加 CPU 开销，因此不建议没有监控数据就直接修改。

6.8 ZProactive：-XX:+ZProactive用于启用主动 GC 周期，目前默认开启。对于长时间空闲或者对象分配量较低的程序，主动 GC 可以帮助维持 Heap 状态并进行引用处理。

七、ZGC推荐配置示例

7.1 JDK 21生产环境基础配置：如果服务器运行 JDK 21，可以根据实际业务采用以下基础参数作为测试起点：

java -Xms16g -Xmx16g -XX:+UseZGC -XX:+ZGenerational -Xlog:gc* -jar app.jar

这里的 16GB 只是示例，并不意味着所有 Java 服务都应该配置 16GB Heap。实际大小应根据服务器物理内存、应用 Live Set、对象分配速率、并发请求量和其他系统进程共同确定。

7.2 新版JDK配置：如果使用较新的 JDK，应先执行 java -version 确认版本，再根据对应版本的官方参数说明进行配置。尤其是 JDK 24 及之后版本，不应该继续按照 JDK 21 的方式强制添加已经发生变化的 Generational ZGC 参数。Oracle 文档已经说明，JDK 24 起 ZGC 已进入分代模式，并移除了旧的非分代模式。

八、ZGC参数配置汇总表

参数	作用	常见使用方式	配置建议
-XX:+UseZGC	启用ZGC	Java低延迟应用	根据JDK版本确认
-Xms	设置初始Heap	控制JVM初始内存	稳定型服务可与Xmx保持一致
-Xmx	设置最大Heap	控制最大Java堆	优先保证Live Set和GC Headroom
-XX:SoftMaxHeapSize	设置软Heap上限	控制平时内存使用	适合有明显业务峰谷的应用
-XX:+ZUncommit	归还闲置Heap	降低JVM内存占用	默认开启
-XX:ZUncommitDelay	设置归还延迟	控制内存释放时间	默认300秒
-XX:ZCollectionInterval	限制GC周期最大间隔	特殊GC周期控制	普通业务通常无需设置
-XX:ZFragmentationLimit	控制碎片率	调整内存整理积极程度	默认25，谨慎修改
-XX:+ZProactive	主动GC	低分配/空闲应用	默认开启
-Xlog:gc*	输出GC日志	性能分析和故障排查	生产环境建议保留日志策略

九、ZGC适合哪些Java应用？

9.1 高并发Web服务：对于访问量较大的 Java Web 服务，如果业务对 P99、P999 等尾延迟指标非常敏感，GC 停顿可能直接影响接口响应时间。ZGC 的低停顿设计可以作为这类业务的候选方案。

9.2 大内存Java服务器：当 Java 应用需要配置几十 GB 甚至更大的 Heap 时，传统 GC 的停顿风险更加值得关注。ZGC 从设计层面针对大 Heap 和低延迟进行了优化，因此比较适合大型 Java 服务。

9.3 实时数据处理：实时计算、消息消费、流式处理等应用通常需要持续处理大量数据。如果对象分配速度较快，GC 处理能力跟不上应用分配速度，就可能产生 Allocation Stall。Generational ZGC 的目标之一就是降低这类风险。

9.4 不适合盲目使用的场景：如果应用 Heap 很小、GC 本身并不是性能瓶颈，或者业务主要追求最高吞吐量，那么没有必要为了使用 ZGC 而更换垃圾回收器。GC 选择应该建立在 GC 日志、CPU 使用率、Heap 使用率、分配速率以及接口延迟等数据基础上。

十、ZGC生产环境调优建议

10.1 首先解决Heap空间问题：ZGC 是并发垃圾回收器，因此 GC 执行期间应用仍然可能不断创建新对象。如果 Heap 没有足够余量，GC 就可能无法及时回收内存，最终出现 Allocation Stall。因此，ZGC 调优首先应该检查 Xmx 是否足够，而不是一开始就大量修改 GC 参数。Oracle 官方也明确将最大 Heap 设置视为 ZGC 最重要的调优项。

10.2 保留GC日志：推荐使用 -Xlog:gc* 记录 GC 行为，然后结合 GC 周期、Heap 使用、CPU 消耗、对象分配速率以及应用延迟进行分析。OpenJDK 的 ZGC 调优资料同样将 GC 日志作为基础诊断手段。

10.3 不要过度调参：ZGC 本身强调自适应设计，官方文档指出它需要较少的人工调优。对于绝大多数应用，合理设置 Xmx、观察 GC 日志并确保有足够 Headroom，比同时修改大量 ZGC 参数更加重要。

10.4 根据业务指标优化：生产环境不能只观察平均响应时间，还应该重点关注 P95、P99、P999 延迟、GC CPU 占比、Heap 使用率、Allocation Rate 和应用吞吐量。只有当这些指标形成完整监控闭环后，才能判断 ZGC 配置是否真正有效。

十一、Java ZGC常见问题解答

问题1：ZGC是不是完全没有STW？

不是。ZGC 的目标是将大量昂贵的 GC 工作放到并发阶段，而不是完全消除所有 Stop-The-World。部分阶段仍然可能产生短暂停顿，只是其设计目标是将应用线程暂停时间控制在非常低的水平。Oracle 官方资料将 ZGC 描述为低延迟垃圾回收器，并强调其暂停时间与 Heap 大小无关。

问题2：JDK 21应该如何开启Generational ZGC？

在 JDK 21 中，可以使用 -XX:+UseZGC -XX:+ZGenerational 开启 Generational ZGC。该模式是 JDK 21 引入的重要 ZGC 能力，能够针对对象生命周期进行更加细致的垃圾回收优化。{index=22}

问题3：ZGC的-Xmx应该设置多大？

没有一个适用于所有 Java 应用的固定数值。应根据服务器物理内存、Java 应用实际 Live Set、对象分配速率以及业务高峰期负载综合计算。ZGC 需要同时容纳存活对象，并为 GC 并发运行期间产生的新对象预留足够空间，因此不能把 Xmx 设置得过于紧张。

十二、总结：ZGC是低延迟Java应用的重要选择

ZGC 是 HotSpot JVM 面向低延迟场景设计的重要垃圾回收器，其核心技术包括并发标记、并发重定位、染色指针、读屏障以及分区化 Heap 管理。与传统垃圾回收器相比，ZGC 最大优势并不是简单追求更快的 GC，而是在较大 Heap 和高对象分配压力下，尽可能降低垃圾回收对业务线程造成的停顿影响。

对于高并发 Java Web、实时计算、大数据服务、消息系统、缓存服务以及大型微服务平台，ZGC 值得进行性能测试。但实际生产部署时，应优先选择匹配业务的 JDK 版本，合理设置 -Xms、-Xmx，保证足够的 GC Headroom，并通过 GC 日志和监控数据持续验证效果，而不是简单复制网上的参数模板。

如果企业需要部署大内存 Java 应用、低延迟业务系统或高并发服务，可以结合服务器 CPU、内存、磁盘、网络和业务访问量制定 JVM 配置方案。天下数据可提供多种服务器及云计算资源，适用于 Java Web、数据库、中间件、实时计算及企业级应用部署。用户可以根据实际业务需求咨询合适的服务器配置、内存规格和部署方案，进一步了解 Java ZGC 运行环境及服务器资源配置，选择更适合生产环境的部署方案。

【免责声明】：部分内容、图片来源于互联网，如有侵权请联系删除，QQ：228866015