在 JDK 11+ 引入的 ZGC（Z Garbage Collector）凭借亚毫秒级停顿时间与 TB 级堆扩展能力，已成为低延迟服务的首选垃圾回收器。然而与 G1、Parallel GC 不同，ZGC 拥有自己独立的参数命名空间 -XX:Z*，这些参数的行为与阈值在不同 JDK 版本中存在差异。本文聚焦生产环境中最高频使用的 ZGC 专属参数，给出筛选逻辑、阈值推荐与避坑建议。

一、为什么需要关注 -XX:Z* 参数子集

ZGC 的核心设计理念是「自适应」—— 它会动态调整堆大小、GC 线程数量与晋升阈值。这意味着大多数场景下，仅需设置 -Xmx 即可获得不错的性能。但当业务对尾延迟有严格要求、或在容器化环境中运行时，理解并调优 ZGC 专属参数能够显著改善以下问题：

  • 内存 footprint：容器内存受限场景下，ZGC 的内存释放策略直接影响 OOM 风险与节点调度。
  • 停顿时间分布：尽管 ZGC 声称亚毫秒级停顿，但在高分配压力下仍可能出现短暂的 STW 峰值。
  • CPU 竞争：并发 GC 线程会与业务线程共享 CPU 资源，在多租户环境中需要精细控制。

以下参数是生产调优中最需要关注的 -XX:Z* 集合。

二、堆与内存管理参数

2.1 -XX:SoftMaxHeapSize（软最大堆）

这是一个常被忽视但极其有用的参数。它允许在不影响吞吐量的前提下设定一个「软上限」——ZGC 会努力将堆保持在该阈值以下，仅在紧急情况下才扩展至 -Xmx 指定的最大值。

推荐阈值：对于典型的 Web 服务，可将软最大堆设为预期存活数据的 1.2–1.5 倍。例如，若日常堆峰值约为 8GB，建议设置 -XX:SoftMaxHeapSize=12g。这既为突发流量预留了缓冲，又避免了常态化内存浪费。

使用场景：多实例容器部署时，每个 Pod 的内存上限通常由调度器统一指定。设置软最大堆可以帮助 K8s 更准确地评估资源需求，减少因内存超卖导致的 OOMKill。

2.2 -XX:+ZUncommit 与 -XX:ZUncommitDelay

ZGC 默认会主动将未使用的堆内存归还操作系统，该行为由 -XX:+ZUncommit 控制（默认开启）。与之配合的是 -XX:ZUncommitDelay，默认值为 300 秒（5 分钟），表示一块内存区域空闲多长时间后可以被释放。

阈值推荐：对于需要长时间运行的服务，建议将 ZUncommitDelay 设置为 600–1800 秒（10–30 分钟）。过短的延迟会导致频繁的内存映射与解除映射，增加内核开销；过长的延迟则会让内存长期驻留，削弱容器调度的灵活性。

避坑指南：如果同时设置了 -Xms 与 -Xmx 为相同值，ZUncommit 会被自动禁用 —— 因为最小堆已固定，无所谓「释放未使用内存」。此时若仍希望控制内存 footprint，应优先调整软最大堆而非依赖 uncommit。

2.3 -XX:+AlwaysPreTouch

此参数强制 JVM 在启动阶段将所有堆页面逐个访问一遍（touch），确保运行时不会因为缺页中断（page fault）导致延迟毛刺。

阈值与适用性：这不是一个数值参数，而是布尔开关。生产环境中，以下两类服务强烈建议启用：

  • 延迟敏感型服务：如实时交易引擎、在线游戏后端、消息队列消费者。对首笔请求的响应时间（P99）要求极高。
  • 大堆场景：当 -Xmx 超过 16GB 时，运行时 touch 页面可能导致数秒的停顿，不如在启动阶段集中完成。

代价：启用此选项会显著延长 JVM 启动时间（与堆大小线性相关），且启动后内存会立即全部 commit。因此在 Serverless 短生命周期函数中应谨慎使用。

三、并发线程与调度参数

3.1 -XX:ConcGCThreads

此参数显式指定 ZGC 用于并发标记 / 回收的工作线程数。JDK 17 及以后版本实现了自动调优 ——JVM 会根据可用 CPU 核心数与堆大小动态选择合理的默认值。

阈值推荐：在大多数场景下，依赖默认值即可。若需要手动干预，经验公式为：

ConcGCThreads = min(CPU核心数 * 0.25, 8)

即保留至少 75% 的 CPU 给业务线程，GC 最多占用 8 个线程。对于 32 核以上的机器，建议上限不超过 12，否则可能因线程切换开销抵消并发收益。

避坑指南：在容器化环境中，必须确保 JVM 能正确识别容器 CPU 配额。自 JDK 10 起，默认启用 -XX:+UseContainerSupport，但仍建议通过 -XX:ActiveProcessorCount 显式声明可用核心数，以避免 cgroup 隔离失效导致的过度订阅。

3.2 -XX:ZCollectionInterval

该参数强制 ZGC 以固定时间间隔触发垃圾回收周期，单位为秒。默认值为 0，表示完全由自适应算法决定何时启动 GC。

使用建议：除非有明确的业务需求（例如金融交易系统需要在每个结算周期前确保堆处于健康状态），否则保持默认值为佳。强制固定间隔可能导致两种负面后果：

  • 过度 GC：分配速率较低时仍强制启动回收，浪费 CPU。
  • 回收不足：分配速率突增时无法及时响应，导致停顿时间上升。

替代方案：若需要更精细的延迟控制，建议通过外部监控系统（如 Prometheus + Grafana）观测堆使用趋势，动态调整 -XX:SoftMaxHeapSize 而非依赖固定间隔。

3.3 -XX:ZFragmentationLimit

此参数控制 ZGC 触发主动压缩（compaction）之前允许的堆碎片化程度，以百分比表示。默认值通常在 25% 左右。

阈值调优：

  • 降低阈值（如 15%）：更积极地压缩内存，减少因碎片导致的分配失败。代价是更频繁的 GC 周期与更高的 CPU 消耗。
  • 提高阈值（如 35%）：容忍更多碎片，减少 GC 开销。适用于对吞吐量敏感、但对偶发 OOM 有容忍度的批处理作业。

监控要点：观察 GC 日志中的 zfragmentation 指标，若持续接近或超过阈值但仍未触发压缩，可能需要结合 ZCollectionInterval 或调整堆大小。

四、大页与 NUMA 优化

4.1 -XX:+UseLargePages 与 -XX:+UseTransparentHugePages

ZGC 的着色指针（colored pointers）与读屏障（load barrier）实现对内存对齐有较高要求。使用大页（huge pages，2MB）可以显著降低 TLB miss，提升吞吐量与延迟。

配置前提：需要在操作系统层面预留足够的大页内存。例如 16GB 堆需要至少 8192 个大页（加上内部结构约需 9216 页）。在 Linux 上执行：

echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

阈值建议：对于生产环境，建议优先配置透明大页（transparent huge pages）而非预分配静态大页 —— 前者无需 root 权限，且对容器环境更友好。但需注意，透明大页在某些内核版本中可能导致延迟毛刺，若观察到异常停顿，可考虑回退至标准页或静态大页。

4.2 -XX:+UseNUMA

在多插槽（multi-socket）服务器上，NUMA 拓扑会影响内存访问延迟。ZGC 支持 NUMA 感知的内存分配策略，可在一定程度上将对象分配在靠近使用线程的 NUMA 节点上。

推荐做法：保持默认开启状态（+UseNUMA）。在单插槽容器环境中此参数无效果，但在物理机上运行大规模微服务时，开启 NUMA 有助于减少跨节点内存访问。

五、生产环境参数模板

以下是针对不同业务场景的推荐参数组合，可作为起步基准：

场景 A：低延迟 API 服务（容器化，16GB 堆）

-Xms16g -Xmx16g \
-XX:SoftMaxHeapSize=12g \
-XX:+UseZGC \
-XX:+ZGenerational \
-XX:+AlwaysPreTouch \
-XX:+UseLargePages \
-XX:+UseTransparentHugePages \
-XX:-ZUncommit \
-XX:ConcGCThreads=4 \
-XX:+UseContainerSupport

场景 B：高吞吐批处理（物理机，64GB 堆）

-Xms64g -Xmx64g \
-XX:+UseZGC \
-XX:+ZGenerational \
-XX:+UseLargePages \
-XX:+UseNUMA \
-XX:+ZUncommit \
-XX:ZUncommitDelay=1200 \
-XX:ConcGCThreads=12

场景 C：Serverless 函数（短生命周期，2GB 堆）

-Xms2g -Xmx2g \
-XX:+UseZGC \
-XX:+ZGenerational \
-XX:-ZUncommit \
-XX:-AlwaysPreTouch \
-XX:ConcGCThreads=2

六、监控与调优循环

参数调优不是一次性工作，而是一个持续迭代的过程。以下指标应纳入日常监控：

  1. GC 停顿时间分布：关注 P50、P99、P999 三个分位值。ZGC 正常情况下 P999 应低于 2ms，若超过 10ms 需检查是否出现了内存压力或碎片化问题。
  2. 堆使用率趋势：观察 used 与 max 的比值。若持续超过 80%，应考虑扩容或优化对象生命周期。
  3. 内存回收效率：通过 -XX:+PrintZStatistics 或 GC 日志观察每次 GC 的回收量与耗时比，评估是否需要调整 ZFragmentationLimit 或 ConcGCThreads。
  4. 容器 cgroup 压力：确保内存使用量未触发 OOMKill，否则所有调优努力将归零。

建议每 2–4 周进行一次参数评审，结合业务流量变化做微调。

七、版本兼容性速查

ZGC 参数在不同 JDK 版本间的支持存在差异，以下是关键版本分水岭：

  • JDK 11：ZGC 正式引入，仅支持非分代模式。
  • JDK 15：并发类卸载（class unloading）默认启用，减少 metaspace 压力。
  • JDK 17：引入动态 ConcGCThreads 调优，减少手动干预需求。
  • JDK 21：分代 ZGC（Generational ZGC）正式 GA，标记为 -XX:+ZGenerational。建议新项目直接使用。

若生产环境仍在 JDK 11/17 上运行，建议至少升级至 JDK 21 以获得分代模式的延迟优化。

资料来源：本文参数阈值参考自 Oracle 官方 GC 调优文档（Java 21）及 Chris Whocodes VM Options Explorer 的 JDK 21 选项列表，并结合生产环境实际经验做了适度的工程化调整。