容器内Java应用因读取宿主机CPU核数导致线程膨胀，应显式配置线程池或通过cgroup v2获取真实限额。
因为容器内看到的 CPU 核心数是宿主机的，不是它被分配到的真实可用核心数。
容器视角与实际资源严重错位
Docker 默认不隐藏宿主机的硬件信息。Java 应用调用 Runtime.getRuntime().availableProcessors() 或通过 /proc/cpuinfo 读取 CPU 数量时，拿到的是物理机或虚拟机的总逻辑核数（比如 16 核），而非容器被 --cpus=0.5 或 cpu-quota 限制后的等效算力。继承 Thread 的线程池若据此创建 16 个线程，实际却只能争抢 0.5 个核心的时间片——大量线程长期就绪、频繁切换，CPU 时间全耗在上下文保存/恢复上，有效计算几乎归零。
线程膨胀触发级联故障
一个典型场景：定时任务每分钟唤醒，每个任务再 fork 出 availableProcessors() × 10 个子线程处理数据。宿主机 16 核 → 容器内开 160 个线程；但配额仅 0.5 核 → 每 100ms 最多运行 50ms → 线程平均等待超 200ms。结果：
- 健康探针请求因线程调度延迟超时，K8s 触发重启
- JVM GC 线程得不到及时调度，STW 延长，加剧响应抖动
- 线程堆栈持续增长，内存压力上升，可能间接诱发 OOM
Java 应用特别容易踩坑
Spring Boot 默认线程池（如 Tomcat 的 maxThreads）、ForkJoinPool、CompletableFuture 的公共 ForkJoinPool.commonPool()，都会默认使用 availableProcessors() 初始化大小。如果镜像没做适配，一模一样的 jar 包在裸机跑得稳，在容器里却线程爆炸。更隐蔽的是：有些 SDK（如某些数据库连接池、日志异步刷盘器）内部也依赖这个值做并发控制。
正确做法不是“读对”，而是“不依赖”
不要让应用自己猜资源上限。应该：
- 显式配置线程池大小，例如 spring.task.execution.pool.max-size=8
- 把 CPU 配额作为部署参数传入应用（如环境变量 CPU_LIMIT=0.5），代码中解析后设为线程数基准
- 使用 cgroup v2 接口读取容器真实限额（如 /sys/fs/cgroup/cpu.max），再换算成合理线程数（注意：需 JDK ≥ 10 且启用 -XX:+UseContainerSupport）
不复杂但容易忽略。
