ZGC圣经：ZGC垃圾回收器的原理、调优，ZGC 漏标的 分析与 研究

本文的 原始地址  ，传送门

本文的 原始地址 ，传送门
尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

听说你是高手，说说，你的ZGC 怎么调优？
说说，ZGC 垃圾回收器的底层原理？
说说，ZGC   的浮动垃圾，是怎么处理的？
说说，ZGC   垃圾回收器的调优过程？

最近有小伙伴在面试 阿里，又遇到了相关的面试题。小伙伴懵了，因为没有遇到过，所以支支吾吾的说了几句，面试官不满意，面试挂了。
所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V171版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，回复：领电子书

另外，此文的内容，作为 第14章，收入尼恩的《JVM 调优圣经》PDF。
尼恩三大 GC 学习圣经

第一大 gc 学习圣经：
《cms圣经：cms 底层原理和调优实战》
第二大 gc 学习圣经：
《G1圣经：G1 底层原理和调优实战》
接下来，咱们言归正传，开始讲 cms
第3大 gc 学习圣经：
《ZGC 圣经：ZGC  底层原理和调优实战》
ZGC解决了什么问题？

JVM 老大难问题:   STW 卡顿（StopTheWorld）

对于Java的项目来说，JVM进行垃圾回收会有一个很大的问题，就是 STW （StopTheWorld）。
在很多业务场景中，STW时间太长是非常致命的，比如说手机系统 （Android ) 显示卡顿，通过对 GC 算法的不断演进，停顿时间控制在几个ms 级别；
再比如说一些实时证券交易系统以及一些大数据平台，大规模部署的情况下，STW太久会造成很严重的影响。
为了满足不同的业务需求，Java 的 GC 算法也在不停迭代，对于特定的应用，选择其最适合的 GC 算法，才能更高效的帮助业务实现其业务目标。
对于这些延迟敏感的应用来说，GC 停顿已经成为阻碍 Java 广泛应用的一大顽疾，需要更适合的 GC 算法以满足这些业务的需求。
首先，来看看大厂的 GC 垃圾回收器的 技术选型

主要 从 堆大小维度 进行技术选型
超小堆（小于 100M）：这类场景下，Serial 串行收集器能有效减少额外开销，因为超小堆的垃圾回收任务本身不复杂，串行收集器按顺序执行回收操作，不会因多线程协调产生额外负担，能较好满足需求。
小堆1G - 4G 堆：可采用CMS 收集器。CMS 收集器以多线程并行方式进行垃圾回收，在这个堆大小范围内，能充分利用多核处理器性能，大幅提升垃圾回收效率，降低停顿时间。
中堆4G - 8G 堆：推荐使用 G1 收集器。G1 将堆划分为多个区域，能更精准地控制垃圾回收的范围和时间，在这个堆大小区间，其优势可有效平衡回收效率和停顿时间。
大堆8G - 16G 堆：推荐使用 G1 收集器。G1（Garbage-First）垃圾收集器在设计上旨在提供可预测的停顿时间，适用于大堆内存、低延迟需求的场景。对于8-16g内存的应用，G1可以通过设置-XX:MaxGCPauseMillis参数来控制最大停顿时间，通常可以将停顿时间控制在200ms以内。 1ms以内低延迟场景，在JDK 16之后，ZGC的停顿时间可以优化至1ms以内。对于8-16g内存的应用，如果对延迟要求极高，例如金融交易系统、实时数据分析等场景，ZGC是一个很好的选择。
超大堆（百 G 以上）：ZGC 是最佳选择。超大堆下，CMS 或 G1 发生 Full GC 时停顿会达分钟级别，严重影响业务，而 ZGC 能将停顿时间控制在毫秒级，满足超大堆的业务需求。
三大 经典 GC的STW平均时间分析

以下是Parallel、CMS、G1三大GC的STW平均时间分析：

• Parallel GC：在年轻代回收时，STW时间较短，通常在几毫秒到几十毫秒之间，但在发生Full GC时，停顿时间会显著增加，可能达到几百毫秒甚至更长，因为它采用的是标记-整理算法，且在多线程环境下工作，需要暂停所有应用程序线程来完成回收操作。
  
• CMS GC：STW时间主要集中在初始标记和重新标记阶段。初始标记阶段的停顿时间很短，通常在几毫秒内，但重新标记阶段在高负载情况下可能会有较长的停顿，一般在几十毫秒到几百毫秒不等。
  
• G1 GC：STW时间受多种因素影响，包括年轻代回收、混合回收以及Full GC等。在年轻代回收时，停顿时间相对较短，通常在几十毫秒左右；混合回收阶段的停顿时间会比年轻代回收稍长，但一般也能控制在几百毫秒以内
  

超大堆 百 G  / TB场景下STW 卡顿难题

近些年来，服务器的性能越来越强劲，各种应用可使用的堆内存也越来越大，常见的堆大小从  10G 到百 G  级别，部分机型甚至可以到达 TB 级别。
在这类大堆应用上，传统的 GC，如 CMS、G1 的停顿时间也跟随着堆大小的增长而同步增加，即堆大小指数级增长时，停顿时间也会指数级增长。
特别是当触发 Full GC 时，停顿可达分钟级别(百GB级别的堆)， 传统的 GC，如 CMS、G1 的停顿时间 很长，以大型金融交易系统为例，运行在 64 核 CPU、512GB 内存的服务器上，因业务数据量巨大且交易频繁，对象分配和回收极为频繁，G1 收集器在执行 Full GC 时，需花费约 1 分钟来完成对全堆对象的处理，对业务的实时性造成显著影响。
超大堆 百 G  / TB场景下， 当业务应用需要提供高服务级别协议（Service Level Agreement，SLA），例如 99.99% 的响应时间不能超过 100ms，此时 CMS、G1 等就无法满足业务的需求。
为满足当前应用对于 超低停顿、并应对大堆和超大堆 带来的挑战，伴随着 2018 年发布的 JDK 11，A Scalable Low-Latency Garbage Collector - ZGC 应运而生。

ZGC介绍

ZGC（The Z Garbage Collector）是JDK 11中推出的一款追求极致低延迟的垃圾收集器，它曾经设计目标包括：

• 支持TB量级的堆。我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求了吧。
  
• 最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，Major GC一般都需要100ms以上（G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反），之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关，而Root数量和堆大小是没有任何关系的。
  
• 奠定未来GC特性的基础。
  
• 最糟糕的情况下吞吐量会降低15%。这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。
  

另外，Oracle官方提到了它最大的优点是：它的停顿时间不会随着堆的增大而增长！
也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下。
‌ZGC（Z Garbage Collector）‌ 是 Java 平台自 JDK 11 起引入的一款‌低延迟、可扩展的垃圾回收器‌，专为‌大堆内存（TB级）‌和‌亚毫秒级停顿‌场景设计。
其核心目标是通过完全并发操作，消除传统垃圾回收器（如 G1、CMS）在处理大堆内存时的长停顿问题，适用于对延迟极度敏感的实时系统（如金融交易、在线游戏、实时数据处理等）。
ZGC的优势

[table][tr]‌场景需求‌‌ZGC的优势‌‌传统GC（如G1）对比‌[/tr][tr][td]‌低延迟要求（