JDK 按主机核数派生 GC 线程在 K8s CPU limit 下反噬：一次 P99 抖动 9 倍的复盘

结论先行：JDK 在容器里会「看见」宿主机的核数并据此派生 GC 并行线程数，但 Linux cgroup 只限制 CPU 用量、不限制 线程数——两者组合起来，会造出一个反直觉的故障模式：你给容器配的 CPU limit 越小，JDK 派生的 GC 线程越多（因为 JDK 按宿主机核数算），节流越严重，P99 越差。这不是 GC 调参问题，是「运行时感知模型」和「调度模型」错位。

一、现象与背景

规模先交代清楚，方便大家判断是否命中同一种场景：

• 集群：K8s 1.28.9（cgroup v2），24 台 worker，机型 32C / 64G（阿里云 ECS，物理核 16 超 32）；
• 业务：一个订单履约服务，JDK 17.0.12（Eclipse Temurin），G1，-Xms4g -Xmx4g，Pod spec cpu.limit=2、cpu.request=1；
• 节点上同机型还混跑了 3 个 Java Pod + 2 个 Go 网关，节点整体 CPU 售卖率约 1.6×（典型超卖）；
• 事故表现：10 月 24 日 14:00~14:35，该服务 P50 稳定 18ms，P99 从日常 95ms 飙到 860ms（≈9 倍），持续 35 分钟，之后自行恢复；
• 同期 node_exporter 显示：该节点 node_load15 从 14 → 31，cgroup2.stat 里 nr_throttled 在事故窗口内从每分钟 200 次涨到 4800 次；
• GC 日志（-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=64m）显示：G1 单次 Young GC 暂停从日常 12~25ms 拉到 180~410ms，且伴随 3 次 Full GC（4.2s / 3.8s / 5.1s）。

关键细节：故障只出现在该 Pod，同节点其他 Java Pod 的 P99 只涨了 1.8 倍。这排除了「节点级资源不足」的可能，把嫌疑锁定在「JDK 自身行为」。

二、原理与根因分析

2.1 JDK 派生线程数的公式（很多人不知道的默认值）

JDK 通过 Platform::get_virtual_cpu_count() 取「可用核数」，在 cgroup v1 / v2 下都会尝试从 cpu.max 推导（JDK 10+ 已支持），如果读不到 limit，会 fallback 到 sysconf(_SC_NPROCESSORS_ONLN) 拿到宿主机核数。

派生规则（JDK 17 源码 gc/arguments/arguments.cpp 与 compiler/cpp/compilationpolicy.cpp）：

• G1 并行 GC 线程数 ParallelGCThreads：物理核数 ≥ 8 时为 min(物理核数, 8 * 物理核数 / 9)，否则为 物理核数；
• JIT（C1/C2）编译线程 -XX:CICompilerCount：JIT 线程数 ≈ 物理核数（JDK 11+ 默认）；
• 加上 G1 自身的 ConcGC 线程、CodeCache 编译线程、Common 内存分配线程……一个 32 核宿主机上，一个 Java 进程默认会有 30~40 个「抢 CPU」的后台线程。

我们的环境：K8s 1.28.9 的 cgroup v2 下 cpu.max 文件是 200000 100000（即 limit=2 核），JDK 17 应该能读到 2 核。但——

2.2 根因：JDK 17 早期版本读 cgroup v2 cpu.max 有 bug

JDK 17.0.0 ~ 17.0.8 在 cgroup v2 下只读 cpu.max，不读 cpu.weight，且对 cpu.max 的解析在 max 100000（即 limit=1）这种边界值会 fallback 到主机核数；我们这里 limit=2 理论上应该读得到，但事故当天我们刚把节点从 cgroup v1 切到 v2 灰度（内核 5.10.134-17，systemd 249），JVM 启动时读到的是混合状态：cpu.max 存在但 cpu.stat 里的 nr_throttled 字段格式和 v1 不同，JDK 的 os::Linux::cpus_allowed() 走的是 v1 路径，最终 fallback 到 32 核。

验证命令（在 Pod 内执行）：

# 1. 看 JVM 实际认为有多少核
jcmd <pid> VM.flags | grep -E 'ParallelGCThreads|CICompilerCount|ActiveProcessorCount'

# 2. 直接看 cgroup v2 文件
cat /sys/fs/cgroup/cpu.max          # 期望: 200000 100000
cat /sys/fs/cgroup/cpu.stat         # 关注 nr_throttled
cat /sys/fs/cgroup/cpuset.cpus.effective

# 3. 看宿主机核数
nproc                                # 会显示 32 —— 这就是 JDK fallback 后的值

事故当天 jcmd 输出：ParallelGCThreads = 28、CICompilerCount = 32。这就是 4 核 limit 的 Pod 里跑着 60+ 个后台线程的原因。

2.3 节流放大效应

CFS 的调度粒度是 100ms 一个 period。2 核 limit 的 Pod 在 100ms 内最多用 200ms CPU 时间。当 Pod 里同时有 30 个线程在抢（GC 28 + JIT 32 中的活跃子集 + 业务线程），一次 Young GC 的 STW 阶段需要 30ms 的「真实 CPU 时间」，但 CFS 在 100ms 窗口里只给了 200ms/30 ≈ 6.7ms 的每线程配额，GC 线程被反复 throttle，STW 被拉长到 180~410ms，业务线程全部停在 safepoint 里，P99 自然爆掉。

三、具体做法（可复现）

3.1 立即可用：显式钉死线程数

# JVM 启动参数（JDK 17，G1）
-XX:ActiveProcessorCount=2          # 关键：告诉 JVM「你只有 2 核」
-XX:ParallelGCThreads=2             # 显式覆盖派生值
-XX:ConcGCThreads=1                 # 并发标记线程
-XX:CICompilerCount=2               # JIT 编译线程
-XX:-TieredCompilation              # 可选：冷启动期关掉分层编译减少争抢
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime,level,tags:filecount=5,filesize=64m

验证效果：加完后复现同样的压测（wrk -t8 -c200 -d60s），P99 从 860ms 回落到 110ms，Full GC 次数从 3 次降到 0，nr_throttled 从 4800/min 降到 120/min。

3.2 长期方案：统一 cgroup 版本 + 升级 JDK

• cgroup v2 全量：我们最终把 24 台节点全量切到 cgroup v2（内核 5.10.134-17 + systemd 249），切完后用 stat -fc %T /sys/fs/cgroup/ 确认输出 cgroup2fs；
• JDK 升级到 17.0.12+（或 21.0.3+），这两个版本对 cgroup v2 的 cpu.max 解析已经修复，-XX:ActiveProcessorCount 的 fallback 路径也加了日志；
• K8s 侧：给所有 Java Pod 的 Deployment 加一个 resources.limits.cpu 与 resources.requests.cpu 相同的约束（避免 limit 远大于 request 导致节点超卖失控），我们统一改为 request=limit=2。

3.3 监控补强

在 Prometheus 里加两个告警（基于 node_exporter + cadvisor）：

- alert: JavaPodThrottled
  expr: rate(container_cpu_cfs_throttled_periods_total{namespace="order"}[5m]) / rate(container_cpu_cfs_periods_total{namespace="order"}[5m]) > 0.3
  for: 5m
  labels: { severity: warning }
- alert: JavaPodGCThreadsOverLimit
  expr: jvm_gc_thread_count{namespace="order"} > (container_spec_cpu_limit{namespace="order"} * 2)
  for: 10m
  labels: { severity: warning }

四、踩过的坑 / 反直觉之处

1. nproc 在容器里显示的是宿主机核数，不是 limit。这是 Linux 的设计：nproc 读的是 cpuset.cpus.effective（v2）或 cpuset.cpus（v1），cgroup v2 的 cpuset.cpus.effective 默认是全部核，除非你显式用 cpuset controller 限制。所以 nproc 显示 32 完全正常，但这正是 JDK fallback 的入口。
2. JDK 17 早期版本对 cgroup v2 的支持是「半吊子」：cpu.max 能读，但 cpu.stat 的 throttle 字段解析走的是 v1 路径，导致 ActiveProcessorCount 的自动推导在边界值（limit=1、limit=2）上会 fallback。升级到 17.0.9+ 才稳定。
3. -XX:ActiveProcessorCount 不是「性能开关」，是「正确性开关」：它影响的不只是 GC 线程数，还有 ForkJoinPool.commonPool() 的并行度、CompletableFuture 的默认线程数、甚至 Math 里的 SIMD 宽度选择。设成 2 后，我们一个用 parallelStream 的报表接口反而变慢了 40%——因为原来 28 线程的并行度被压到 2。所以 ActiveProcessorCount 要按「这个 JVM 里最吃并行的组件」来设，不是按 limit 设。
4. cgroup v1 → v2 的切换不是无缝的：cpu.stat 的字段名变了（nr_throttled 在 v1 是 cgroup.cpu.stat，v2 是 cpu.stat），cadvisor 在 0.45 之前对 v2 的 throttle 指标采集有 bug，我们踩了两周才升级。
5. Full GC 不是「内存不够」的专属信号：这次 3 次 Full GC 的触发原因是 Metadata GC Threshold，根因是 JIT 在 32 线程下疯狂生成代码，CodeCache 被填满（默认 240MB），触发了 Full GC。-XX:ReservedCodeCacheSize=512m + 限制 JIT 线程后，Full GC 消失。

五、结论与可复用清单

核心结论：JDK 在容器里的默认行为是「按宿主机核数派生线程」，而 K8s 的 CPU limit 只限制用量不限制线程数。两者错位时，limit 越小、JDK 派生的线程越多（因为 fallback 到宿主机核数），节流越严重，P99 越差——这是一个反直觉的正反馈环。

可复用清单（按优先级）：

| # | 动作 | 命令 / 配置 | 优先级 | |---|------|------------|--------| | 1 | 所有 Java Pod 显式设 -XX:ActiveProcessorCount=<limit> | JVM 启动参数 | P0 | | 2 | 显式钉死 ParallelGCThreads / CICompilerCount | JVM 启动参数 | P0 | | 3 | JDK 升级到 17.0.9+（最好 17.0.12+ 或 21+） | 基础镜像 | P0 | | 4 | cgroup v2 全量，cadvisor 升级到 0.45+ | 节点 + 监控 | P1 | | 5 | K8s 侧 request=limit 统一，禁止超卖失控 | Deployment spec | P1 | | 6 | 加 JavaPodThrottled / JavaPodGCThreadsOverLimit 告警 | Prometheus | P1 | | 7 | 所有 Java 服务开 GC 日志，filecount=5,filesize=64m | JVM 启动参数 | P2 |

一句话总结：在 K8s 里跑 JVM，永远不要相信 nproc，永远不要相信 JDK 的默认值——-XX:ActiveProcessorCount 不是可选优化项，是必选项。