ZGC (Z Garbage Collector) 是 Java 垃圾收集器发展史上的革命性突破。它由 Oracle 开发，旨在解决大内存堆下的延迟问题。
从 JDK 15 开始成为正式特性，到 JDK 21/25 已经极度成熟，ZGC 已成为超低延迟应用和超大堆内存应用的首选方案。
🚀 核心目标：停顿时间与堆大小解耦
ZGC 的核心承诺只有一句话：
无论堆内存是 100MB 还是 10TB，GC 的停顿时间（Pause Time）都能控制在 1 毫秒以内（通常 < 0.5ms）。
这与 G1 或 CMS 完全不同：
- G1/CMS：堆越大，需要扫描和整理的对象越多，停顿时间越长（线性增长）。
- ZGC：停顿时间是恒定的，与堆大小无关。
🧠 底层核心技术原理
ZGC 之所以能实现“并发整理”且停顿极短，主要依赖于两项黑科技：染色指针 (Colored Pointers) 和 读屏障 (Load Barriers)。
1. 染色指针 (Colored Pointers)
- 传统方式：对象的状态（如是否被标记、属于哪一代、是否被移动）通常存储在对象头（Object Header）中。GC 修改状态需要访问对象本身，这在并发环境下很难处理。
- ZGC 方式：
- ZGC 将对象的状态信息（4 个标志位：Marked0, Marked1, Remapped, Finalizable）直接存储在对象引用的指针高位上（64 位指针中，高几位 unused bit）。
- 优势：
- 无需访问对象：GC 线程只需查看指针的高位就能知道对象状态，无需读取对象头，极大减少了缓存一致性开销。
- 节省空间：对象头不需要存储 GC 状态位，对象更紧凑。
- 限制：由于占用了指针高位，ZGC 目前仅支持 64 位平台，且最大堆内存受限（早期版本 4TB，JDK 21+ 已支持更大，理论上可达 PB 级）。
2. 读屏障 (Load Barriers)
- 问题：在 GC 并发移动对象时，如果应用程序线程（Mutator）正在读取一个即将被移动的对象的引用，该怎么办？
- 解决方案：ZGC 在应用程序线程读取对象引用的指令处，插入了一段极短的代码（读屏障）。
- 工作流程：
- 应用线程读取指针
P。 - 触发读屏障：检查
P的染色位。 - 如果需要修正：
- 如果对象已被移动到新地址，读屏障会自动更新指针
P为新地址，并清除染色位。 - 如果对象正在被标记，读屏障会协助 GC 完成标记。
- 如果对象已被移动到新地址，读屏障会自动更新指针
- 返回正确的对象引用给应用线程。
- 应用线程读取指针
- 结果：应用线程永远拿到的是最新、正确的对象地址。GC 可以随意移动对象，而应用线程无感知（除了极微小的屏障开销）。这使得并发整理成为可能。
3. 多重映射视图 (Multi-Mapping Views)
- ZGC 使用虚拟内存映射技术，让同一块物理内存可以通过不同的虚拟地址访问。
- 当对象从 Region A 移动到 Region B 时，ZGC 暂时保留 Region A 的映射指向新位置。读屏障负责将访问 Region A 的请求重定向到 Region B。一旦所有旧引用都被修正，旧的映射被移除。
⚙️ ZGC 的运行阶段
ZGC 的所有关键阶段几乎都是并发执行的，只有极短的 STW（主要用于根扫描和栈扫描）。
| 阶段 | 名称 | 是否 STW | 动作描述 |
|---|---|---|---|
| 1 | 暂停 (Pause) | ✅ 是 (<1ms) | 1. 标记 GC Roots。2. 扫描栈（找出本地变量中的引用）。3. 设置 Marked0 位。 |
| 2 | 并发标记 (Concurrent Mark) | ❌ 否 | 后台线程遍历对象图，设置 Marked1 位。应用线程通过读屏障协助标记。 |
| 3 | 暂停 (Pause) | ✅ 是 (<1ms) | 1. 再次扫描栈（处理标记期间变化的引用）。2. 转移存活对象到新的 Region（并发开始）。 |
| 4 | 并发转移 (Concurrent Transfer) | ❌ 否 | 后台线程将存活对象复制到新 Region。应用线程通过读屏障自动修正引用指向新地址（自愈）。 |
| 5 | 暂停 (Pause) | ✅ 是 (<1ms) | 清理旧 Region，重置指针染色位，完成回收。 |
注：随着 JDK 版本升级（特别是 JDK 21+），部分原本需要短暂 STW 的步骤（如栈扫描）也逐步实现了并发化，停顿时间进一步缩短。
⚖️ ZGC vs. G1 vs. CMS
| 特性 | CMS (已死) | G1 (默认) | ZGC (高性能) |
|---|---|---|---|
| 最大停顿时间 | 低，但不可控 (Full GC 长) | 可预测 (随堆增大而增加) | 极低 (<1ms)，与堆大小无关 |
| 堆内存支持 | < 4GB | 4GB - 32GB+ | 任意大小 (TB/PB 级) |
| 算法核心 | 标记 - 清除 | 分区 + 复制整理 | 染色指针 + 读屏障 |
| 吞吐量 | 高 | 高 | 中高 (JDK 21+ 已达 G1 的 90%+) |
| CPU 开销 | 中 | 中 | 略高 (读屏障有微小开销，但在现代 CPU 上可忽略) |
| 碎片问题 | 严重 | 无 | 无 |
| 适用场景 | 历史遗留 | 通用服务端 | 超低延迟、超大堆 |
🛠️ 如何使用与调优
在 JDK 15+ 中，启用 ZGC 非常简单。
1. 启用命令
java -XX:+UseZGC -jar your-app.jar
(在 JDK 21+ 中，ZGC 甚至可以作为某些场景下的默认选项，或者通过 -XX:+UseZGC 显式开启)
2. 核心调优参数
-
堆大小设置 (强烈推荐固定)
-Xms16g -Xmx16gZGC 在固定堆大小下表现最佳，避免动态扩容带来的开销。
-
软上限 (Soft Max Heap Size) - JDK 21+ 新特性
-XX:SoftMaxHeapSize=8g允许堆在空闲时收缩到 8GB，但在需要时可扩展到
-Xmx设定的最大值。这解决了 ZGC 早期版本“吃了内存就不吐”的问题，非常适合云原生环境。 -
分页视图 (Large Pages)
-XX:+UseLargePages使用操作系统的超大页（Huge Pages），减少 TLB Miss，显著提升 ZGC 性能（尤其是大堆场景）。需在 OS 层面配置支持。
-
并发线程数
-XX:ConcGCThreads=4通常 JVM 会自动根据 CPU 核数计算，无需手动调整，除非在容器受限环境中。
-
着色指针模式 (JDK 21+ 优化)
在 JDK 21 中，ZGC 引入了无指针染色模式（在某些架构上），进一步降低开销，通常自动选择。
💡 适用场景与最佳实践
✅ 强烈推荐场景
- 超低延迟要求：金融高频交易、实时竞价广告、在线游戏服务器、电信核心网。任何不能容忍 >10ms 卡顿的场景。
- 超大堆内存：堆内存 > 32GB，甚至达到 TB 级别。G1 在这种规模下停顿时间可能达到秒级，而 ZGC 依然保持毫秒级。
- 内存波动大：利用 JDK 21 的
SoftMaxHeapSize，在云环境中节省成本。
⚠️ 注意事项
- CPU 开销：读屏障意味着每条读取引用的指令都要多执行几行代码。在极度 CPU 敏感且内存很小（< 2GB）的场景下，Parallel GC 或 Serial GC 的吞吐量可能略高于 ZGC。但在现代多核 CPU 上，这种差异通常小于 5%，几乎可忽略。
- JDK 版本：
- JDK 11/15：ZGC 可用，但功能有限（如不支持压缩指针，最大堆受限）。
- JDK 17：性能大幅提升，支持更多架构。
- JDK 21/25：生产环境首选。性能已完全媲美 G1，且增加了弹性堆大小等高级特性。
- 监控：使用
-Xlog:gc*查看日志。关注Pause Total，应该始终维持在 1ms 以下。
📊 总结
ZGC 是 Java 并发垃圾收集的终极形态之一。
- 如果你在使用 JDK 21 或更高版本，并且没有极端的吞吐量优先需求（如纯离线批处理），ZGC 应该是你的默认选择。
- 它消除了“堆大小”与“停顿时间”之间的权衡，让开发者可以大胆分配大内存，而不用担心 GC 卡顿。
- 随着 JDK 25 的发布，ZGC 的性能和稳定性已经达到了前所未有的高度，标志着 Java 进入了“亚毫秒级 GC”的新时代。
一句话建议：新项目直接用 JDK 21/25 + ZGC，享受丝滑的低延迟体验。