并发gc性能优化核心是让并发阶段真正并发起来且不拖慢应用线程，需平衡并发标记/清理进度、应用分配速度与stw可控性；低延迟场景重压最大停顿（如-xx:maxgcpausemillis），高吞吐场景重单位时间回收量，混合负载建议分进程部署不同gc；须显式控制并发线程数防cpu过载，避免并发失败退化为full gc，并通过jstat、jmx等监控并发阶段健康度。
并发 GC 的性能优化不是调参数本身，而是让并发阶段真正“并发得起来”，同时不让它拖慢应用线程。核心在于平衡三件事：并发标记/清理的进度、应用分配速度、以及 STW 阶段的可控性。
明确目标：区分“低延迟”和“高吞吐”场景
并发 GC（如 G1、ZGC、Shenandoah）本质是把原本 Stop-The-World 的工作拆成可并发执行的部分。但不同目标下优化重点不同：
- 低延迟优先（如支付网关、实时风控）：重点压降最大停顿时间（Max GC pause），容忍少量并发线程开销；关注 -XX:MaxGCPauseMillis（G1）或 -XX:ZCollectionInterval（ZGC）等目标导向参数
- 高吞吐优先（如日志聚合、ETL 任务）：更看重单位时间回收对象量，可适当放宽单次停顿，但需控制并发阶段 CPU 占用率不挤占业务线程
- 混合负载（如微服务网关既处理请求又跑定时任务）：建议分进程部署——交易链路用 ZGC，批处理用 Parallel GC，避免互相干扰
控制并发线程资源，防 CPU 过载
并发 GC 线程默认按物理 CPU 核数计算，但在容器或共享环境里容易超配：
- G1 的 -XX:ConcGCThreads 默认值 ≈ (ParallelGCThreads + 2) / 4，若宿主机 64 核，可能自动设为 16+，但容器只分配 4 核 → 实际并发能力远低于预期，反而引发标记滞后
- 解决办法：显式设置 -XX:ConcGCThreads=2～4（视容器 CPU limit 而定），并配合 -XX:ParallelGCThreads=4 控制并行回收线程数
- ZGC 在 JDK 17+ 支持 -XX:+UseContainerSupport 自动识别 cgroups 限制，务必开启；否则可能在 32C 容器里起 20+ 并发线程，导致 CPU 抢占严重
避免并发失败，减少退化为 Full GC
并发 GC 失败（如 G1 的 “Concurrent Mode Failure”，ZGC 的 “Allocation Stall”）会直接触发 STW 回收，停顿飙升：
- 根本原因通常是堆增长快于并发标记进度：比如突发流量导致对象分配速率激增，老年代快速填满，而并发标记还没完成
- 应对策略：
– 提前触发标记：G1 调低 -XX:InitiatingHeapOccupancyPercent（如从默认 45% 改为 35%）
– 增加堆冗余空间：-Xms 和 -Xmx 设为相同值（禁用动态伸缩），避免扩容时触发并发失败
– ZGC 可启用 -XX:+ZUncommit（JDK 15+）定期归还空闲内存，缓解压力
监控关键信号，不只看 GC 日志
光看 “GC pause (G1 Evacuation Pause)” 行不够，要盯住并发阶段是否健康：
- 用 jstat -gc -t pid 1s 查看 G1 的 CMC（Concurrent Mark Cycle）耗时是否稳定；若 CMC 时间持续 > MaxGCPauseMillis × 3，说明标记跟不上
- ZGC 关注 “ZStat” 输出中的 “Mark” 和 “Relocate” 阶段平均耗时，若 relocate 平均 > 5ms，检查是否对象迁移太频繁（如大量短命大对象）
- 通过 JMX 暴露的 G1OldGenSize、ZGCCycles、ZGCTotalPausedTime 等指标接入 Prometheus，设置告警：连续 3 次 CMC 超时 或 ZGC 单次 pause > 10ms
