ZGC 是 Oracle 开发的低延迟垃圾回收器，通过染色指针、读屏障和内存多重映射实现亚毫秒停顿，适用于 TB 级大堆，需 JDK 13+、Linux ≥4.1，启用时需固定堆大小并合理监控调优。
不是 Zend，而是 Z Garbage Collector——ZGC 是 Oracle 开发的 JVM 垃圾回收器，名字里的 “Z” 代表可伸缩（Scalable），和 PHP 的 Zend Engine 完全无关。它专为超大堆（TB 级）、亚毫秒停顿场景设计，不是“Zend GC”，这点常被误读。
为什么 ZGC 能做到 10ms 以内停顿？
关键不在“多线程快”，而在于几乎不暂停应用线程。它把原本必须 STW 的工作（标记、移动对象、更新引用）全部搬到了并发阶段执行：
- 靠染色指针：把对象状态（如是否已标记、是否被移动）直接编码进 64 位指针的高位，省掉额外标记表和同步开销
- 靠读屏障：每次读取对象引用时做轻量检查，自动修正指向新地址的引用，让对象迁移对业务代码透明
- 靠内存多重映射：同一块物理内存映射多个虚拟地址，切换“颜色”视图即可完成重定位，无需改写指针值
ZGC 启用与基础配置要点
从 JDK 13 起已是生产就绪，但需匹配运行环境（Linux ≥4.1，64 位系统）：
- 启用命令：
-XX:+UseZGC，必须搭配-Xmx和-Xms设为相同值（如-Xmx32g -Xms32g），避免动态扩容引发额外延迟 - 释放未用内存（JDK 13+）：
-XX:+ZUncommit+-XX:ZUncommitDelay=300，让空闲堆内存归还 OS，提升资源利用率 - 避免盲目调参：像
-XX:ZCollectionInterval或-XX:ZAllocationSpikeTolerance应基于监控数据调整，而非默认值硬套
监控与评估 ZGC 实际表现
不能只看“用了 ZGC”，要验证它是否真达预期：
- 用
jstat -gc <pid>查看ZGCTotal（总 GC 次数）、ZGCTime（总暂停时间），计算平均单次停顿是否稳定低于 10ms - 关注
ZGC pauses字段总和，若持续上升，说明触发频率过高，可能需调大堆或检查内存泄漏 - 吞吐率（Throughput）应保持在 99% 以上——意味着应用线程 99% 时间都在干活，GC 占比极低
ZGC 不是万能解药，适用有边界
它强在大堆低延迟，但也有现实约束：
- 不区分年轻代/老年代，所有对象统一管理，小对象高频分配场景下，相比 G1 可能年轻代回收效率略低
- 读屏障带来约 1–3% 的 CPU 开销，对纯计算密集型服务需权衡
- 堆大小建议不超过物理内存的 90%，避免 swap 导致延迟飙升
- 若应用堆长期在 4GB 以下、且 GC 停顿本就不明显，升级 ZGC 收益有限，反而增加维护复杂度
