Java 8 的 parallelStream() 默认共用 ForkJoinPool.commonPool()，根本原因是 JDK 为轻量复用而有意设计的全局共享池，但导致资源争抢、并行度错配、工作窃取失效及可观测性缺失四大生产问题。
java 8 的 parallelstream() 默认共用 forkjoinpool.commonpool()，根本原因在于 jdk 的设计取舍：它追求轻量复用、避免线程爆炸，但牺牲了业务隔离与负载适配能力。这个“全局共享”不是疏忽，而是有意为之的简化设计——可一旦进入真实生产环境，就立刻暴露出三类硬伤。
资源争抢：所有模块挤在同一个线程池里
commonPool 是 JVM 级静态单例，不区分调用方、不隔离业务域。只要用了默认的 parallelStream()、CompletableFuture.supplyAsync() 或某些框架内部并行逻辑（如 Spring Data JPA 的批量操作），全都会往里面提交任务。
- 订单服务做实时聚合计算（CPU 密集）和用户服务并发查 Redis（IO 密集）共用同一组 15 个线程（16 核机器）
- 一个慢查询阻塞 1 秒，就等于“锁死”1 个 worker 线程，其他本可并行的任务只能排队等待
- 没有优先级、没有熔断、没有拒绝策略，故障会横向扩散
并行度错配：CPU 核心数减 1 不适合混合负载
默认并行度 = Runtime.getRuntime().availableProcessors() - 1，这是为纯计算场景优化的数值，假设任务能快速完成、无阻塞。但生产中大量任务含网络调用、数据库访问、文件读写等 IO 操作。
- IO 任务需要更多线程“等待时也能干活”，而 commonPool 线程太少，导致请求堆积、响应延迟升高
- 盲目调大并行度（如设为 32）又可能引发上下文切换开销剧增、下游服务被打垮（如 DB 连接池耗尽）
- 该值在 JVM 启动时固化，运行时无法动态感知 CPU 配额变化（如 Kubernetes 中 CPU limit 被限制为 2 核，但进程仍读到物理机 32 核）
机制失灵：工作窃取在阻塞面前完全失效
ForkJoinPool 依赖“工作窃取”提升吞吐，前提是线程能高频完成小任务、主动去别处“偷活干”。但 IO 阻塞会让线程长时间挂起。
- 被阻塞的线程既不执行任务，也不参与窃取，实际可用 worker 数锐减
- 任务队列持续积压，commonPool 整体吞吐断崖下跌
- 极端情况下，7 个线程全卡在 HTTP 调用上，连最简单的
mapToInt().sum()都得排队等空闲
可观测性归零：无法监控、打标、限流
因为是全局池，你无法为不同业务设置专属指标：
立即学习“Java免费学习笔记（深入）”；
- 不能单独统计“促销活动 parallelStream 的平均耗时”或“支付回调的失败率”
- 不能给高优任务配置独立拒绝策略（比如直接抛异常而非丢弃）
- 日志、链路追踪中无法自动标记所属业务域，故障定位困难
