容器中forkjoinpool默认并行度因availableprocessors()误读宿主机核数而错配，导致线程饥饿；应优先用-xx:activeprocessorcount=n或-djava.util.concurrent.forkjoinpool.common.parallelism=n显式设置，并避免在长周期任务中滥用commonpool。
在容器化环境里，ForkJoinPool 默认通过 Runtime.getRuntime().availableProcessors() 获取并行度（parallelism），而这个方法在旧版 JDK（ForkJoinPool.commonPool() 的 parallelism 设为 32 —— 线程数远超可用资源，引发争抢、上下文切换飙升、响应延迟激增，甚至掩盖真实瓶颈。
为什么 availableProcessors() 在容器里会“看错”
JVM 启动时默认不主动读取 cgroup 信息。Linux 容器通过 cpu.cfs_quota_us 和 cpu.cfs_period_us 限制 CPU 时间配额（例如 quota=200000, period=100000 表示最多用 2 核），但老版本 JVM 不解析这些文件，而是直接读取 /proc/cpuinfo —— 这个文件始终反映宿主机能力。
- 典型表现：K8s Pod 设置
resources.limits.cpu: "2"，但jstack显示 commonPool 启了 16 或 32 个 worker 线程 - 后果：大量线程竞争有限 CPU，
top -H观察到高 %CPU 但有效吞吐低；GC 日志中出现频繁的 “Concurrent Mode Failure” 或 STW 时间异常增长
如何确认当前 parallelism 是否错估
运行时验证最直接：
- 进容器执行：
java -XshowSettings:vm -version 2>&1 | grep "Available processors"—— 看输出是否等于你期望的核数 - 代码中打印：
System.out.println(ForkJoinPool.getCommonPoolParallelism()); - 检查 cgroup 配额：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us，若 quota 是 -1 表示无限制，否则计算quota / period（如 200000/100000 = 2）
正确设置 parallelism 的三种方式
优先级从高到低：
-
启动参数强制指定（推荐）：JDK 10+ 支持
-XX:+UseContainerSupport（默认开启），再配合-XX:ActiveProcessorCount=N直接覆盖检测结果。例如：-XX:+UseContainerSupport -XX:ActiveProcessorCount=2 -
系统属性覆盖：启动时加
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2。注意：该值必须是整数，且需早于 ForkJoinPool 首次使用（通常在应用初始化早期就生效） -
代码中显式构造池（适合关键路径）：避免依赖 commonPool，改用自定义池：
new ForkJoinPool(2, ..., true)，其中第三个参数true启用 asyncMode，更适合 I/O 型异步任务
特别注意 Kafka 消费等长周期任务场景
像 CompletableFuture.runAsync(() -> { while(true) { ... } }) 这类无限循环消费逻辑，如果误用 commonPool，一旦 parallelism 被设得过大，就会“吃掉”所有 worker 线程，导致其他异步任务（如 HTTP 调用、日志刷盘）严重饥饿。更稳妥的做法是：为 Kafka 消费单独配一个固定大小的 ThreadPoolExecutor，而不是依赖 ForkJoinPool。
