停顿敏感型应用应将-XX:ParallelGCThreads设为容器实际可用逻辑核数，避免线程过多引发上下文切换开销；K8s中按spec.containers[].resources.limits.cpu取整，JDK8u131+可自动识别cgroup，推荐值=min(可用核数,8)，4核容器设为4可降低GC暂停30%~50%。
停顿时间敏感型应用（比如实时接口、低延迟交易、互动类服务）最怕 GC 期间线程抢资源、上下文疯狂切换，导致响应毛刺甚至软锁。而 -XX:ParallelGCThreads 这个参数，恰恰是控制并行 GC 阶段“用多少个线程一起干”的开关——设得太大，不是更快，反而更卡。
为什么 ParallelGCThreads 过大会拖慢停顿表现
并行 GC（如 Parallel Scavenge / Parallel Old）在执行 Young GC 或 Full GC 的标记-复制/整理阶段时，会启用多个线程并行工作。但这些线程不是免费的：
- 每个 GC 线程都需要独立栈空间和寄存器上下文，占用内存与 CPU 缓存资源
- 线程数远超可用 CPU 核心时，OS 调度器被迫高频切换，大量 CPU 时间花在保存/恢复上下文上，而非真正做 GC
- 尤其在容器（Docker/K8s）中，JVM 若感知不到 CPU limit（如 JDK 8u131 之前），会按宿主机核数算出几十个线程，实际却只分配了 2~4 个 vCPU —— 这就是“虚假并行”
- 实测案例显示：4 核容器里设
-XX:ParallelGCThreads=16，Young GC 暂停时间反而比设为 4 高 30%~50%，且 CPU user% 居高不下
怎么设才合理：按实际可用核数取整，不盲目对齐物理核
目标不是“用满 CPU”，而是让 GC 线程数与业务线程竞争最小化。关键看 JVM 实际能调度到的逻辑核数：
- 查清容器真实 CPU 配额：K8s 中看
spec.containers[].resources.limits.cpu，Docker 中看--cpus=2.5或--cpu-quota/--cpu-period - JDK 8u131+ 和 JDK 9+ 默认已支持 cgroup v1/v2 自动识别，可跳过手动设置；旧版本必须显式指定
- 推荐值 = min(容器可用逻辑核数, 8)；超过 8 核后增长极缓，公式为
8 + (N−8) × 5/8，但对停顿敏感场景，直接取 N 更稳妥 - 举例：K8s 分配 3 个 vCPU → 设
-XX:ParallelGCThreads=3；分配 1.5 个 vCPU → 取整为 2（避免设 1 导致单线程 GC 拖慢吞吐）
搭配 ConcGCThreads 控制并发阶段线程数（G1/CMS 场景）
如果你用的是 G1 或 CMS 这类并发收集器，-XX:ParallelGCThreads 只管 STW 阶段（如初始标记、最终标记重标记），而并发标记、清理等非 STW 阶段由 -XX:ConcGCThreads 控制。它同样影响 CPU 占用：
-
-XX:ConcGCThreads默认值 ≈ParallelGCThreads / 4，但上限常为 2~4；过高会导致并发线程与用户线程争抢 CPU，延长并发阶段耗时，间接拉长整体 GC 周期 - 停顿敏感型建议：设为
min(2, 可用核数)，例如 2 核容器就固定写-XX:ConcGCThreads=2 - 验证方式：加
-XX:+PrintGCDetails -Xloggc:gc.log，观察 GC 日志中[GC pause (G1 Evacuation Pause)]的 duration 和[GC concurrent-mark-start]到end的跨度
上线前必做的三件事
光改参数不够，得闭环验证：
- 启动时加
-XX:+PrintCommandLineFlags，确认参数是否生效（注意拼写：是ParallelGCThreads，不是ParallelGCThread） - 压测时用
pidstat -t -p观察 GC 线程（线程名含1 GCTaskThread）的 %CPU 和上下文切换频次（cswch/s），对比调优前后 - 结合 APM 工具（如 Prometheus + JVM Micrometer）看
jvm_gc_pause_seconds_max{action="end of major GC"}的 P95/P99 值是否收敛、无尖刺
