必须设置-XX:ActiveProcessorCount，否则JVM会读取宿主机总核数而非容器实际CPU limit，导致线程池过大、上下文切换激增；该参数仅在OpenJDK 8u191+有效，且值须≤limits.cpu向下取整。
容器里跑Java且设置了CPU limit时必须设
只要你的Java应用部署在Kubernetes或Docker中，并显式配置了resources.limits.cpu（比如"2"、"500m"），就该设置-XX:ActiveProcessorCount。不设 ≠ 没问题，而是JVM大概率会读到宿主机总核数（如64），而非容器实际能用的核数（如2），导致线程池创建过多、上下文切换爆炸、CPU利用率虚高但吞吐极低。
常见触发场景包括：
- 使用
ForkJoinPool.commonPool()处理并行流、CompletableFuture异步任务 - Spring Boot默认线程池（如
TaskExecutor）基于Runtime.getRuntime().availableProcessors()推导核心线程数 - Log4j2异步Appender、Netty EventLoopGroup等依赖可用处理器数的组件
OpenJDK 8u191+才支持，旧版本无效
-XX:ActiveProcessorCount从java 1.8.0_191起才正式支持。如果你用的是更早的JDK 8（比如8u181或8u172），这个参数会被JVM静默忽略，Runtime.getRuntime().availableProcessors()依然返回宿主机核数——你以为设了，其实没生效。
验证方式：
- 进容器执行：
jcmd <pid> VM.system_properties | grep availableProcessors</pid> - 对比
cat /sys/fs/cgroup/cpu.max（cgroup v2）或cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（cgroup v1）中的值 - 若两者不一致，且JDK版本-Djava.util.concurrent.ForkJoinPool.common.parallelism=2硬编码）
值必须≤容器CPU limit向下取整
-XX:ActiveProcessorCount不是随便填个接近的数就行。它必须是整数，且不能超过容器实际可用的CPU核数（按limits.cpu向下取整）。例如：
-
limits.cpu: "2"→ 设-XX:ActiveProcessorCount=2✅ -
limits.cpu: "1500m"→ 实际是1.5核，向下取整为1 → 设-XX:ActiveProcessorCount=1✅ -
limits.cpu: "500m"→ 实际0.5核 → 仍应设为1（JVM最小有效值），但需同步调低线程池并发度，否则1个线程也抢不到足量时间片 ❗ -
limits.cpu: "2"却设-XX:ActiveProcessorCount=4→ JVM会按4核建线程池，但OS强制限流，饥饿更严重 ❌
和虚拟线程调度参数要协同
Java 21+启用虚拟线程后，-Djdk.virtualThreadScheduler.parallelism默认等于Runtime.getRuntime().availableProcessors()。如果-XX:ActiveProcessorCount没设对，这个调度器也会误判平台线程数，导致虚拟线程大量阻塞在调度队列里。
建议组合设置：
-XX:ActiveProcessorCount=2-Djdk.virtualThreadScheduler.parallelism=2-
-Djdk.virtualThreadScheduler.maxPoolSize=200（避免突发IO时平台线程无限膨胀）
单独调其中一个，另一个仍可能拉垮整体并发表现——这点容易被忽略，尤其在压测时只盯着commonPool()而漏看虚拟线程调度器。
