OpenJDK默认按宿主机物理核数初始化线程池，不自动适配容器CPU limit；JDK 8u191+起内存感知启用，但CPU仍需显式配置-XX:ActiveProcessorCount才能对齐cgroup配额，否则ForkJoinPool、Parallel GC等将超量创建线程，引发调度抖动与性能劣化。
OpenJDK默认按物理CPU核心数初始化线程池，不看容器CPU limit
容器里跑的Java进程，Runtime.getRuntime().availableProcessors() 返回的值，决定了 ForkJoinPool 并行度、Parallel GC 线程数、Executors.newWorkStealingPool() 默认并行度等关键行为。在 JDK 8u191 之前，这个值永远是宿主机 CPU 核心数；8u191+ 默认开启 -XX:+UseContainerSupport，但仅限内存感知——CPU 仍不自动适配 cgroup 配额。也就是说，哪怕你给容器只配了 cpu: 250m（即 0.25 核），JVM 仍可能起 8 个 GC 线程、开 8 路并行流，结果就是 CPU 时间片被强抢、调度延迟飙升、应用响应卡顿。
必须显式用 -XX:ActiveProcessorCount 控制线程规模
这是目前最直接有效的解法。该参数会覆盖 availableProcessors() 的返回值，并联动影响：
-
ParallelGC和G1GC的并行标记/清理线程数（例如-XX:ParallelGCThreads不设时就按它算） ForkJoinPool.commonPool().getParallelism()-
CompletableFuture异步任务默认执行器的并行度 - 某些框架（如 Netty 的
EpollEventLoopGroup）内部线程数推导逻辑
实操建议：
- 若容器
limits.cpu是500m，建议设-XX:ActiveProcessorCount=1（避免 0.5 核上起多线程反拖慢） - 若配的是
cpu: 2（即 2 核），可设为2，但需结合实际负载观察：高吞吐 I/O 场景下，有时1反而更稳 - 不要依赖
-XX:ParallelGCThreads单独调 GC 线程——它不控制 ForkJoinPool，容易漏掉关键线程源
别信“自动感知”，JDK 版本和 cgroup v2 会影响实际行为
不同 JDK 版本对 CPU 配额的响应差异很大：
- JDK 8u191–8u292：
-XX:+UseContainerSupport仅作用于内存，CPU 完全无视 cgroup - JDK 10+：
UseContainerSupport默认开启，但 CPU 感知仍需手动加-XX:ActiveProcessorCount - JDK 17+（cgroup v2 环境）：
availableProcessors()在部分发行版（如 Temurin、Zulu）中开始尝试读取cpu.max，但行为不稳定，不能作为生产依据
验证方式很简单：进容器执行
java -XX:+PrintFlagsFinal -version | grep ActiveProcessorCount
再跑一段代码输出 Runtime.getRuntime().availableProcessors()，对比容器 cpu.limit 是否一致。不一致，就说明 JVM 没真正“看到”配额。
线程数错配的典型现象不只是卡顿
除了响应变慢，还容易触发连锁问题：
- GC 线程过多 → CPU 使用率虚高（
top显示 java 进程 300%+），但实际吞吐没提升，反而 GC 停顿变长 - ForkJoinPool 并行度过高 → 大量虚拟线程或平台线程争抢 carrier thread，导致
VirtualThread#park延迟突增 - Netty 或 Spring WebFlux 默认线程组膨胀 → 连接建立慢、HTTP 2 流复用失效
- 容器 CPU throttling 频繁（
cat /sys/fs/cgroup/cpu/cpu.stat | grep throttled有非零值）→ 应用日志出现大量超时、重试
真正要命的不是线程多，而是线程数和容器能稳定分到的 CPU 时间不匹配——这会让 JVM 的“并发友好”变成“调度灾难”。
