parallelStream() 默认使用 ForkJoinPool.commonPool()，该线程池专为 CPU 密集型任务设计，用于 I/O 等非计算密集型任务会导致资源争用、并行度错配、工作窃取失效、缺乏隔离与可观测性等问题。
parallelStream() 默认使用 ForkJoinPool.commonPool()，这个线程池专为 CPU 密集型任务设计。一旦用于非计算密集型任务（比如数据库查询、HTTP 调用、文件读写等），就会引发一系列连锁问题。
共享线程池导致资源争用
commonPool 是全局静态单例，所有 parallelStream()、CompletableFuture（未显式指定 Executor）、以及部分框架内部任务都共用它。这意味着：
- 一个耗时的 I/O 操作（如等待远程接口响应）会占用一个线程长达数百毫秒甚至数秒
- 其他本该并行执行的计算任务只能排队等待，无法获取空闲线程
- 整个应用中所有依赖 commonPool 的并发逻辑都会被拖慢，出现“一损俱损”现象
线程数配置与实际负载严重错配
commonPool 默认并行度 ≈ CPU 核心数 − 1（最小为 1）。这个值对纯计算任务合理，但对 I/O 任务完全不适用：
- I/O 任务大部分时间在等待，而非消耗 CPU，因此需要更多线程才能维持吞吐量
- 强行用少量线程处理大量 I/O 请求，会导致请求堆积、响应延迟升高、超时频发
- 若盲目调大 commonPool 并行度（如通过系统属性），又可能压垮下游服务（如数据库连接池耗尽）
阻塞操作破坏 ForkJoinPool 工作窃取机制
ForkJoinPool 依赖“工作窃取”提升效率，前提是线程能快速完成小任务。而 I/O 阻塞会直接卡住线程：
- 被阻塞的线程无法参与窃取，也无法释放资源供其他任务使用
- 线程池中有效工作线程数锐减，整体吞吐能力断崖式下降
- 极端情况下，多个 long-running I/O 任务可能让 commonPool 几乎“瘫痪”，连简单计算都无法及时执行
缺乏隔离性与可观测性
由于是全局池，你无法为不同业务场景单独配置：
- 不能设置专属拒绝策略、自定义队列、或监控特定任务的执行耗时
- 出问题时难以定位是哪个模块的 parallelStream 拖累了整个池
- 容器环境下（如 Kubernetes 限制 CPU 配额），commonPool 可能误判可用算力，进一步加剧调度失衡
