zgc是java 11引入的低延迟垃圾收集器，专为tb级大堆设计，目标停顿≤10ms且基本不随堆增大而上升；需jdk 17+、-xx:+usezgc、-xms=-xmx，并结合并发线程数、对象分配特征与日志监控调优。
ZGC（Z Garbage Collector）是 Java 11 引入的低延迟垃圾收集器，专为超大堆（TB 级）场景设计，目标是将 GC 停顿时间稳定控制在 10 毫秒以内，且停顿时间基本不随堆大小增长而显著上升。要真正发挥 ZGC 的毫秒级停顿能力，不能只靠简单启用，需结合 JVM 配置、应用特征与运行环境协同调优。
启用 ZGC 并确认生效
ZGC 仅支持 64 位 Linux 和 Windows（Java 15+），macOS 从 Java 21 开始支持。启用前需确认 JDK 版本 ≥ 11（推荐 Java 17 或更高版本，因早期 ZGC 功能受限）。
- 启动参数：添加 -XX:+UseZGC，并建议显式设置初始堆和最大堆（如 -Xms4g -Xmx4g），ZGC 要求两者相等（即堆不可动态伸缩）
- 验证是否启用：加上 -Xlog:gc*:stdout:time,uptime,level,tags，运行时观察日志中是否出现
ZGC相关阶段（如ZMarkStart、ZRelocateStart），且停顿标记为Pause类型（如Pause Mark End） - 注意：ZGC 不兼容 CMS、G1 或 Parallel GC；若同时指定多个 GC，JVM 会报错退出
合理设置堆大小与并发线程数
ZGC 的停顿时间主要取决于对象图遍历和重定位阶段的并发处理能力，而非堆总量本身。但过小的堆会导致频繁 GC，过大的堆若并发线程不足，仍可能拖慢并发阶段进度，间接影响下一次停顿。
- 堆大小建议：从应用常驻对象量的 2–3 倍起步（例如常驻 2GB，设
-Xmx6g），避免过于激进地分配 TB 级堆——除非真实需要，否则反而增加元数据开销 - 并发 GC 线程数：默认为 CPU 核心数的 1/4（最小 2），可通过 -XX:ZCollectionParallelism=4 手动调整；对高核数服务器（如 64 核），适当提高（如设为 8–12）可加快并发标记/重定位，减少下次 GC 触发压力
- 避免过度调小 -XX:ZUncommitDelay（默认 300 秒）：频繁归还内存可能引发额外系统调用开销，一般无需修改
规避 ZGC 不擅长的场景
ZGC 在绝大多数常规对象分配/释放模式下表现优异，但在以下情况可能触发更长停顿或降级行为：
- 大量短生命周期、超高频分配的小对象（如每毫秒百万级临时字符串）：虽不影响停顿上限，但会快速填满“分配缓冲区”，导致更频繁的 GC 循环；建议结合对象池或结构复用缓解
- 巨型对象（> 256KB）占比过高：ZGC 将其单独管理，重定位开销较大；可考虑拆分或使用堆外内存（如
ByteBuffer.allocateDirect）替代 - 开启 -XX:+UnlockExperimentalVMOptions -XX:+UseZGCStrict（实验性）可强制拒绝不兼容操作（如某些 JNI 直接内存访问），但生产环境慎用
监控关键指标并持续验证
ZGC 的毫秒级承诺依赖实际运行反馈，不能仅凭参数启用就认定达标。
- 核心观察项：Pause Mark Start → Pause Mark End（标记停顿）、Pause Relocate Start → Pause Relocate End（重定位停顿），理想值均
- 工具推荐：使用 JDK 自带 jstat -gc
查看 ZGC 统计（列含 ZGC-Used、ZGC-Count、ZGC-Time）；配合 Grafana + Prometheus（通过 JVM Micrometer 暴露指标）做长期趋势分析 - 压测验证：用真实流量或模拟负载（如 JMeter + 高并发对象创建）持续运行 30 分钟以上，检查停顿 P99 是否稳定达标，而非只看平均值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
