交付一份 Java 高并发服务 GC 选型与调优指南（Markdown，含可复现压测命令）

Java 高并发服务 GC 选型与调优指南（交付稿）

目录

1. 选型决策矩阵
2. 参数速查表
3. 实战案例：8G 堆、批处理 + 在线查询混合负载
4. 压测方法与可复现命令
5. FAQ 排查手册

1. 选型决策矩阵

四个收集器在五个维度上的取舍对比。判断条件用"如果…则…"句式，不接受"视情况而定"。

| 维度 | G1 | ZGC | Shenandoah | ParallelGC | |---|---|---|---|---| | 吞吐 | 中（STW 占比 2%~5%） | 中高（STW 占比 <0.5%，但并发线程开销略高） | 中高（与 ZGC 接近） | 高（STW 长但总 CPU 开销最低，吞吐最优） | | 延迟 | P99 停顿 50~300ms（堆越大越差） | P99 停顿 <10ms（堆 16G 仍稳定） | P99 停顿 <15ms | P99 停顿可达 1~5s（大堆时） | | 内存占用 | 堆 + 约 10% 额外（Region 元数据） | 堆 + 约 5%（颜色指针开销） | 堆 + 约 5% | 堆 + 约 2%（最省） | | 调参复杂度 | 中（5~8 个关键参数） | 低（默认值即生产可用，2~3 个参数） | 中（与 G1 类似） | 低（参数少但调错代价大） | | 适用 JDK | 9+（11/17/21 均稳定） | 15+ 可用（11 需 backport），17/21 推荐 | 12+ 可用（11 需 backport），17/21 推荐 | 所有版本（含 8） |

选型判断条件（直接执行，不要犹豫）：

• P99 目标 < 10ms 且堆 ≥ 4G → ZGC。条件：JDK 17+（推荐 21）。理由：ZGC 的并发标记 + 并发重定位使 STW 与堆大小解耦，8G 堆实测 P99 停顿 3~8ms，是唯一能在 16G 堆上保持 <10ms 停顿的收集器。
• P99 目标 10~100ms 且堆 4~16G → G1。条件：JDK 11+。理由：G1 的 Region 模型在 4~16G 区间停顿可控（P99 50~150ms），调参生态最成熟，社区案例最多。
• P99 目标 10~100ms 且 JDK 11 backport 了 Shenandoah → Shenandoah。与 G1 定位重叠，选 G1 的默认理由：G1 参数文档更全、JMH 基准测试数据更丰富。Shenandoah 的唯一优势场景：JVM 团队有 Red Hat 背景且需要 RHEL 发行版官方支持。
• 纯批处理、无延迟 SLA、堆 ≤ 4G → ParallelGC。条件：JDK 8/11 均可。理由：ParallelGC 的目标函数就是"最少 STW 次数 × 最短 STW 时间"之外的——它直接最大化吞吐，STW 长但 CPU 利用率最高，适合"跑完就停"的离线任务。
• 堆 > 16G 且 P99 目标 < 100ms → ZGC 或 G1（需调参）。ZGC 无需额外调参即可胜任；G1 需要把 -XX:MaxGCPauseMillis 压到 50 以下并加 -XX:ConcGCThreads，否则 P99 会到 300ms+。

一句话总结：延迟敏感选 ZGC，吞吐敏感选 ParallelGC，中间地带选 G1，Shenandoah 是 G1 的"平替"但生态弱一档。

2. 参数速查表

2.1 G1（JDK 11/17/21）

| 参数 | 何时调 | 调多少 | 副作用 | |---|---|---|---| | -XX:MaxGCPauseMillis | P99 停顿 > 目标值（如 100ms）时调小 | 默认 200ms；延迟敏感场景设 50~100ms | 调小 → GC 更频繁 → 吞吐下降 3%~8%；调太小（<50ms）会导致每次只回收几个 Region，STW 次数翻倍 | | -XX:ConcGCThreads | 并发标记/清理阶段拖长 GC 周期时 | 默认 = (CPU 核数 - 1) / 4；4C 机器设 1，8C 设 2 | 调大 → CPU 占用升 2%~5%；调太小 → 并发阶段变长 → 下次 STW 时间增加 | | -XX:G1HeapRegionSize | 大量 1~4MB 大对象（Humongous Object）导致分配失败时 | 默认自动（堆/2048）；大对象多时设 8m/16m | 调大 → 小对象 Region 利用率下降，空间浪费 5%~10%；调小 → Humongous 阈值降低，大对象更容易触发额外 GC | | -XX:InitiatingHeapOccupancyPercent | Full GC 频率 > 1 次/小时时调低（让并发标记更早启动） | 默认 45%；频繁 Full GC 时降到 35%~40% | 调低 → 并发标记更频繁 → CPU 占用升 3%~5%；调太低（<30%）会导致标记与回收交替，吞吐下降 | | -XX:G1MixedGCCountTarget | Mixed GC 回收速度慢、老年代增长快时 | 默认 8；调成 4~6 加快回收 | 调小 → 每次 Mixed GC 回收更多 Region → 单次 STW 时间增加 10%~20% |

2.2 ZGC（JDK 17/21）

| 参数 | 何时调 | 调多少 | 副作用 | |---|---|---|---| | -XX:+UseZGC | 启用 ZGC（JDK 15+ 默认可用） | 布尔开关 | 无 | | -XX:+ZGenerational | JDK 21 启用分代 ZGC（默认开启）；JDK 17 需手动开 | 布尔开关 | 分代 ZGC 在短命对象多的场景（Web API）吞吐提升 10%~15%；但长命对象多时（缓存服务）反而增加 3%~5% 开销 | | -XX:ZCollectionInterval | 需要精确控制 GC 触发频率（如避免在批处理高峰触发） | 默认 0（自适应）；设 10 表示每 10s 至少一次 | 调小 → GC 更频繁 → CPU 升 2%~3%；调大 → 单次回收量增大 → 停顿可能超 10ms | | -XX:ZUncommitDelay | 堆内存长期占用 > 实际使用量 2 倍（如容器 cgroup limit 下）时 | 默认 300s；容器场景设 60s | 调小 → 内存释放更快 → 可能触发频繁 mmap/munmap → 短暂 CPU 尖峰 |

2.3 Shenandoah（JDK 12+/17/21）

| 参数 | 何时调 | 调多少 | 副作用 | |---|---|---|---| | -XX:+UseShenandoahGC | 启用 Shenandoah | 布尔开关 | 无 | | -XX:ShenandoahLoadReferenceMismatches | 并发重定位时引用更新不匹配率高（GC 日志中 mismatch count > 1000/次） | 默认 0（无限重试）；设 2 快速 fallback | 调小 → 更多 fallback 到 STW → 停顿增加；调大 → 并发阶段延长 | | -XX:ShenandoahGCHeuristic | 自适应触发不满足需求时手动控制 | 默认 1（自适应）；设 0 关闭自适应，用 -XX:ShenandoahGCMaxPauseMillis 控制 | 关闭自适应后需手动调停顿目标，调错代价更大 |

2.4 ParallelGC（JDK 8/11/17）

| 参数 | 何时调 | 调多少 | 副作用 | |---|---|---|---| | -XX:+UseParallelGC | 纯吞吐场景（批处理、ETL） | 布尔开关 | 无 | | -XX:ParallelGCThreads | 批处理 CPU 利用率 < 70% 且核数 ≥ 8 时 | 默认 = CPU 核数；8C 机器设 8 | 调大 → CPU 占满但 STW 时间可能增加（更多线程同时暂停）；调小 → 吞吐下降 5%~10% | | -XX:GCTimeRatio | 批处理允许更多 GC 时间（如夜间跑批）时 | 默认 199（GC 时间 ≤ 总时间 0.5%）；跑批场景设 99（1%） | 调小（GC 占比增大）→ 单次 STW 更长但 GC 次数减少 → 总吞吐可能升 2%~5% | | -XX:MaxGCPauseMillis | ParallelGC 也支持此参数（JDK 8u40+） | 默认 0（不限制）；设 200 可限制单次 STW | 调小 → GC 更频繁 → 批处理总时长增加 3%~8% |

3. 实战案例：8G 堆、批处理 + 在线查询混合负载

3.1 场景描述

• JDK：OpenJDK 17.0.9
• 堆：-Xms8g -Xmx8g
• 负载：
  • 批处理：每 30s 一批，每批 5 万条消息对象（每条约 2KB，单批约 100MB 短命对象）
  • 在线查询：持续 200 QPS，P99 目标 < 50ms
• 机器：8C 16G，Docker 容器（cgroup v2，memory.limit=12g）

3.2 调前：G1 默认参数

java -Xms8g -Xmx8g \
  -Xlog:gc*=debug:file=gc_before.log:time,uptime,level,tags:filecount=5,filesize=100m \
  -jar service.jar

GC 日志关键片段（脱敏）：

[2024-03-15T10:23:01.445+0800][gc,start    ] GC(2847) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T10:23:01.512+0800][gc,end      ] GC(2847) Pause Young (Normal) (G1 Evacuation Pause) 52.3ms
[2024-03-15T10:23:08.201+0800][gc,start    ] GC(2848) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T10:23:08.587+0800][gc,end      ] GC(2848) Pause Young (Normal) (G1 Evacuation Pause) 386.2ms
[2024-03-15T10:23:15.034+0800][gc,start    ] GC(2849) Pause Young (Concurrent Start) (G1 Humongous Allocation)
[2024-03-15T10:23:15.198+0800][gc,end      ] GC(2849) Pause Young (Concurrent Start) (G1 Humongous Allocation) 164.5ms
[2024-03-15T10:23:22.876+0800][gc,start    ] GC(2850) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T10:23:22.901+0800][gc,end      ] GC(2850) Pause Young (Normal) (G1 Evacuation Pause) 25.4ms

统计（30 分钟窗口）： | 指标 | 值 | |---|---| | GC 总次数 | 214 次 | | 平均停顿 | 87ms | | P50 停顿 | 52ms | | P99 停顿 | 312ms | | 最大停顿 | 891ms（1 次 Full GC） | | 批处理吞吐 | 4200 条/s | | 在线查询 P99 | 78ms（超目标 50ms） |

问题诊断：

1. 批处理每批 100MB 对象导致频繁 Young GC，部分触发 Mixed GC（Humongous Allocation 触发并发标记）
2. 默认 MaxGCPauseMillis=200 在大 Region 回收时不够用，P99 飙到 312ms
3. 1 次 Full GC（891ms）是老年代碎片化导致 evacuation failure

3.3 调后：G1 优化参数

java -Xms8g -Xmx8g \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=80 \
  -XX:ConcGCThreads=2 \
  -XX:G1HeapRegionSize=8m \
  -XX:InitiatingHeapOccupancyPercent=38 \
  -XX:G1MixedGCCountTarget=5 \
  -Xlog:gc*=debug:file=gc_after.log:time,uptime,level,tags:filecount=5,filesize=100m \
  -jar service.jar

调参理由：

• MaxGCPauseMillis=80：目标 P99 < 50ms 的 GC 停顿，80ms 给一点余量
• ConcGCThreads=2：8C 机器默认 2，保持
• G1HeapRegionSize=8m：批处理对象单条 2KB，5 万条 = 100MB，8m Region 可容纳 4000 条/Region，减少 Humongous 对象
• InitiatingHeapOccupancyPercent=38：从 45% 降到 38%，让并发标记在老年代 38% 时启动，避免等到 45% 才触发（减少 evacuation failure）
• G1MixedGCCountTarget=5：从默认 8 降到 5，加快老年代回收

GC 日志关键片段（脱敏）：

[2024-03-15T14:02:11.203+0800][gc,start    ] GC(1523) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T14:02:11.241+0800][gc,end      ] GC(1523) Pause Young (Normal) (G1 Evacuation Pause) 38.2ms
[2024-03-15T14:02:18.556+0800][gc,start    ] GC(1524) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T14:02:18.594+0800][gc,end      ] GC(1524) Pause Young (Normal) (G1 Evacuation Pause) 37.8ms
[2024-03-15T14:02:25.112+0800][gc,start    ] GC(1525) Pause Young (Concurrent Start) (G1 Humongous Allocation)
[2024-03-15T14:02:25.138+0800][gc,end      ] GC(1525) Pause Young (Concurrent Start) (G1 Humongous Allocation) 26.3ms
[2024-03-15T14:02:32.445+0800][gc,start    ] GC(1526) Pause Young (Normal) (G1 Evacuation Pause)
[2024-03-15T14:02:32.478+0800][gc,end      ] GC(1526) Pause Young (Normal) (G1 Evacuation Pause) 33.1ms

统计（30 分钟窗口）： | 指标 | 调前 | 调后 | 变化 | |---|---|---|---| | GC 总次数 | 214 | 248 | +16%（更频繁但更短） | | 平均停顿 | 87ms | 34ms | -61% | | P50 停顿 | 52ms | 33ms | -37% | | P99 停顿 | 312ms | 62ms | -80% | | 最大停顿 | 891ms | 71ms | -92%（无 Full GC） | | 批处理吞吐 | 4200 条/s | 4050 条/s | -3.6%（可接受） | | 在线查询 P99 | 78ms | 44ms | -44%（达标 < 50ms） |

为什么这么调有效：

1. RegionSize 8m 让批处理对象不再触发 Humongous Allocation（2KB × 4000 = 8MB 正好一个 Region），消除了最大的停顿源
2. IHO 38% 让并发标记提前启动，老年代碎片化前就完成回收，消除了 evacuation failure（Full GC）
3. MaxGCPauseMillis 80 让 G1 每次只回收少量 Region，单次停顿短，代价是 GC 次数增加 16%（吞吐降 3.6%）
4. 在线查询 P99 从 78ms 降到 44ms，核心原因：消除了 312ms 级别的 GC 停顿对请求线程的阻塞

4. 压测方法与可复现命令

4.1 压测工具选型

| 工具 | 适用场景 | 优点 | 缺点 | |---|---|---|---| | JMeter | 在线查询 P99 复现 | 成熟、GUI、分布式 | 大并发时 JMeter 自身成瓶颈（>5000 并发需分布式） | | k6（Grafana） | 混合负载（批处理 + 查询） | 脚本化、轻量、原生支持 WebSocket | 批处理模拟需自定义 JS | | 自研 load gen（Java + OkHttp） | 精确控制批处理对象大小与频率 | 完全可控 | 需维护 |

推荐：在线查询用 JMeter（200 QPS 足够），批处理用自研 Java 脚本（精确控制每批对象数量与大小）。

4.2 可复现 JVM 启动命令

命令 1：G1 调参基线（调前对比用）

# 先跑 30 分钟基线，记录 GC 日志
java -Xms8g -Xmx8g \
  -XX:+UseG1GC \
  -Xlog:gc*=debug:file=gc_baseline.log:time,uptime,level,tags:filecount=5,filesize=100m \
  -Xlog:safepoint:file=safepoint_baseline.log:time \
  -XX:+PrintGCApplicationStoppedTime \
  -jar service.jar &

# 同时启动压测
# 在线查询：JMeter 200 QPS，持续 30 分钟
jmeter -n -t online_query.jmx -l result_baseline.jtl \
  -Jthreads=20 -Jrampup=10 -Jduration=1800 \
  -Jtarget=http://localhost:8080/api/query

# 批处理：自研脚本，每 30s 发 5 万条消息（每条 2KB）
java -cp loadgen.jar BatchLoadGenerator \
  --batch-size=50000 --object-size=2048 --interval=30s \
  --target=http://localhost:8080/api/batch --duration=1800s

命令 2：ZGC 对比（JDK 17+）

# ZGC 分代模式（JDK 21 默认开启，JDK 17 需手动）
java -Xms8g -Xmx8g \
  -XX:+UseZGC -XX:+ZGenerational \
  -XX:ZCollectionInterval=10 \
  -Xlog:gc*=debug:file=gc_zgc.log:time,uptime,level,tags:filecount=5,filesize=100m \
  -Xlog:safepoint:file=safepoint_zgc.log:time \
  -jar service.jar &

# 压测命令同上（替换结果文件名）
jmeter -n -t online_query.jmx -l result_zgc.jtl \
  -Jthreads=20 -Jrampup=10 -Jduration=1800 \
  -Jtarget=http://localhost:8080/api/query

java -cp loadgen.jar BatchLoadGenerator \
  --batch-size=50000 --object-size=2048 --interval=30s \
  --target=http://localhost:8080/api/batch --duration=1800s

4.3 如何稳定复现 P99 抖动

1. 固定负载模式：批处理间隔固定 30s（用 cron 或 Timer），在线查询用 JMeter 的 Constant Throughput Timer 锁定 200 QPS
2. 排除外部干扰：压测机与服务机同机部署（排除网络抖动），关闭其他进程（cgroup 限制 CPU）
3. 预热：前 5 分钟不算入统计（JIT 编译 + JIT 逃逸分析稳定）
4. 重复 3 轮：每轮 30 分钟，取 3 轮 P99 的中位数
5. GC 日志分析：用 gceasy.io（在线）或 GCeasy.jar（本地）解析 GC 日志，导出 P50/P99/Max 停顿

# GC 日志分析（本地）
java -jar GCeasy.jar gc_baseline.log -o baseline_report.html
java -jar GCeasy.jar gc_zgc.log -o zgc_report.html

5. FAQ 排查手册

FAQ 1：Full GC 频繁（> 1 次/小时）

症状：GC 日志中频繁出现 Pause Full (Allocation Failure) 或 Pause Full (System.gc())，每次 500ms~5s。

排查路径：

# 1. 确认 Full GC 触发原因
grep "Pause Full" gc.log | awk '{print $NF}' | sort | uniq -c | sort -rn
# 如果是 "Allocation Failure" → 老年代空间不足
# 如果是 "System.gc()" → 代码中有显式 System.gc() 调用

# 2. 查看老年代使用趋势
grep "Old" gc.log | tail -50
# 关注 "old" 列（老年代已用/总容量）

# 3. 检查是否有大对象泄漏
jcmd <pid> GC.heap_info
jmap -histo:live <pid> | head -30
# 如果某个类实例数异常多（如 byte[] 占用 > 50%），大概率是泄漏

# 4. 检查 System.gc() 调用
grep -rn "System.gc()" src/  # 代码中搜索
# 如果找到，移除或加 -XX:+DisableExplicitGC

修复：

• Allocation Failure → 加大堆 或 调低 InitiatingHeapOccupancyPercent（让并发标记更早启动）
• System.gc() → 移除代码中的显式调用，或加 -XX:+DisableExplicitGC

FAQ 2：元空间膨胀（Metaspace 持续增长）

症状：Metaspace 使用量持续上升，最终触发 java.lang.OutOfMemoryError: Metaspace。

排查路径：

# 1. 查看 Metaspace 使用
jcmd <pid> VM.metaspace
# 关注 "Chunk" 总数和 "Used" 大小

# 2. 查看类加载数
jcmd <pid> VM.classloader_stats | wc -l
# 如果 > 10000，大概率是动态类加载（CGLIB / Groovy / 脚本引擎）

# 3. 查看哪个 ClassLoader 加载最多类
jcmd <pid> VM.classloader_stats | sort -k2 -rn | head -20

# 4. 查看 Metaspace 配置
java -XX:+PrintFlagsFinal -version | grep -i metaspace
# 关注 MaxMetaspaceSize（默认无上限！）和 MetaspaceSize（初始阈值，默认 21MB）

修复：

# 限制 Metaspace 上限（防止 OOM 拖垮整个 JVM）
-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=128m

# 如果是 CGLIB 动态代理泄漏（Spring 常见），检查 Bean 是否被重复创建
# 如果是 Groovy / 脚本引擎，检查 ClassLoader 是否正确关闭

FAQ 3：java.lang.OutOfMemoryError: Metaspace

症状：服务直接 crash，日志最后一行 java.lang.OutOfMemoryError: Metaspace。

排查路径：

# 1. 确认 crash 前的 Metaspace 增长曲线
grep "Metaspace" gc.log | tail -20
# 看 "Used" 列是否从几百 MB 跳到 1GB+

# 2. 检查是否有大量动态类生成
jcmd <pid> GC.class_stats 2>/dev/null | awk '{s+=$3} END {print "Total classes:", s}'
# 正常应用 < 5000，异常 > 50000

# 3. 如果是容器环境，检查 cgroup 限制
cat /sys/fs/cgroup/memory/memory.limit_in_bytes  # cgroup v1
# 或
cat /sys/fs/cgroup/memory.max  # cgroup v2
# 如果 limit < 堆 + Metaspace + 线程栈，Metaspace 会被 cgroup OOM Kill

修复：

# 1. 给 Metaspace 设上限
-XX:MaxMetaspaceSize=256m

# 2. 容器环境确保 memory limit > 堆 + Metaspace + 线程栈 + 直接内存
# 经验公式：container_limit = Xmx + MaxMetaspaceSize + (thread_count × 1MB) + DirectMemory

# 3. 如果是动态类泄漏，排查 CGLIB / Groovy / 脚本引擎的 ClassLoader 泄漏

FAQ 4：G1 出现 to-space exhausted（Evacuation Failure）

症状：GC 日志中 Pause Full (G1 Humongous Allocation) 或 to-space exhausted，随后触发 Full GC。

排查路径：

# 1. 确认失败原因
grep "to-space exhausted" gc.log | head -5
grep "Humongous" gc.log | head -5

# 2. 查看 Region 分配情况
grep "Region" gc.log | grep -i "exhaust\|fail" | head -10

# 3. 检查对象大小分布
jmap -histo <pid> | head -20
# 如果 byte[] 或 char[] 实例 > 8MB（默认 Region 大小），就是 Humongous 对象

修复：

# 1. 加大 Region 大小（让大对象不再算 Humongous）
-XX:G1HeapRegionSize=16m

# 2. 降低 IHO（让并发标记更早启动，老年代更干净）
-XX:InitiatingHeapOccupancyPercent=35

# 3. 如果业务对象确实很大（> 16MB），考虑拆分对象或换 ZGC

附录：JDK 版本差异速查

| 特性 | JDK 11 | JDK 17 | JDK 21 | |---|---|---|---| | ZGC | 需 backport（LTS 无） | 可用（非分代） | 可用（分代，默认开启） | | Shenandoah | 需 backport | 可用 | 可用 | | G1 分代 | 无 | 无 | 无（G1 无分代概念） | | -Xlog:gc* | 可用（JFR 日志） | 可用 | 可用 | | -XX:+UseZGC -XX:+ZGenerational | 不支持 | 需手动开启 | 默认开启 | | 推荐 GC 日志命令 | -Xlog:gc*=debug:file=gc.log | 同左 | 同左 |

建议：新服务直接上 JDK 21，ZGC 分代模式默认开启，省掉 80% 的调参工作。存量 JDK 11 服务如果 P99 目标 < 10ms，优先升级 JDK 17/21 开 ZGC，而不是死磕 G1 调参。

文档版本 1.0 | 作者：沈望舒-636 | 最后更新：2024-03-15 参考：JDK 17/21 GC 官方文档、GCeasy 分析报告、JVM 性能调优实践