ZGC专为TB级堆设计，能在4TB甚至16TB堆下稳定维持低于10ms的停顿时间，依托着色指针、读屏障和并发标记/重定位机制实现低延迟垃圾回收。

ZGC专为TB级堆设计，能在4TB甚至16TB堆下稳定维持

ZGC支持的最大堆规模

Java 15起ZGC正式脱离实验状态，最大堆支持达16TB（64位平台）。实际生产中常见配置为2TB–4TB，兼顾稳定性与资源利用率。Java 11初始支持4TB，Java 13提升至8TB，演进路径清晰：版本升级直接带来堆上限扩容，无需修改代码逻辑。

• 启用方式统一：-XX:+UseZGC -Xmx4T（T代表TB，单位识别准确）
• 必须配对设置-Xms与-Xmx，避免运行时堆伸缩引发额外开销
• 超过8TB堆时，需确认操作系统支持足够大的虚拟地址空间（如Linux内核开启vm.max_map_count）

关键支撑技术：染色指针与读屏障

ZGC不扫描对象头，而是把标记状态“刻”进64位指针高4位（Marked0/Marked1/Remapped），对象访问时通过读屏障实时判断并修复引用。这使标记、转移全程并发，STW仅保留在初始标记、再标记、初始转移三个极短阶段（合计通常

• 染色指针降低内存访问压力，避免传统GC的记忆集、卡表等元数据结构开销
• 读屏障带来约1%~3%的CPU额外消耗，但换来毫秒级停顿，整体延迟收益远大于开销
• 应用线程无需等待GC完成即可继续执行，适合高QPS、低延迟服务（如支付网关、行情推送）

大内存下的必要配套配置

ZGC在TB级堆上发挥全部能力，离不开底层系统协同。单纯加堆不调参，可能触发频繁缺页或NUMA跨节点访问，反拖慢性能。

• 强制启用大页：-XX:+UseLargePages，并挂载hugetlbfs到指定路径（如/hugepages）
• NUMA感知优化：-XX:+UseNUMA，让ZGC Region分配优先落在本地内存节点
• 禁用压缩Oops：-XX:-UseCompressedOops（TB级堆下压缩指针失效，显式关闭更明确）
• 监控建议开启：-Xlog:gc*,gc+heap=debug,gc+metaspace=debug:file=gc.log:time,tags

典型场景验证效果

某实时风控系统将堆从32GB（G1）升至2TB（ZGC），GC平均停顿从87ms降至0.9ms，P99响应时间下降42%；另一PB级图计算平台使用4TB ZGC堆，单次Full GC消失，日志中不再出现“Concurrent Mode Failure”或“Humongous Allocation”警告。

• 停顿时间与堆大小解耦——这是ZGC区别于G1的根本特征
• 吞吐量未明显下降，实测在相同负载下，ZGC吞吐约为G1的92%~96%，但确定性延迟优势不可替代
• 运维复杂度略升（需协调OS层配置），但故障率显著降低，尤其规避了大堆下G1常见的长时间卡顿和OOM连锁反应