并发流 parallelStream()：分析其默认使用的 ForkJoinPool 对非计算密集型任务的负面影响

说实话，parallelStream() 默认走的是 ForkJoinPool.commonPool()，这个全局线程池天生是为 CPU 密集型任务优化的。那要是拿它处理数据库查询、HTTP 调用、文件读写这类 I/O 任务呢？后果就是一连串让人头疼的问题。

来，咱们一个个拆开看。

共享线程池导致资源争用

commonPool 是全局唯一的静态单例，不光 parallelStream() 用它，CompletableFuture（没显式指定 Executor 时）甚至某些框架内部的并发任务也挤在同一池子里。这意味着什么？

• 一个耗时的 I/O 操作（比如等远程接口返回）会占着一个线程长达几百毫秒甚至几秒
• 其他本来该并行跑的计算任务只能排队干瞪眼，明明有活却拿不到空闲线程
• 整个应用里所有依赖 commonPool 的并发逻辑都会被拖慢——一损俱损，谁都跑不掉

线程数配置与实际负载严重错配

commonPool 默认的并行度大约是 CPU 核心数减一（最少是 1）。这个值对付纯计算任务挺合理，但用在 I/O 场景就完全不对味了：

• I/O 任务大部分时间都在等待，而不是吃 CPU，所以需要更多线程才能撑起吞吐量
• 硬着头皮用几个线程去处理一大堆 I/O 请求，结果就是请求越积越多、响应延迟飙升、超时频频发生
• 要是有人想通过系统属性调大 commonPool 并行度，又可能把下游服务压垮（比如数据库连接池直接被耗尽）

阻塞操作破坏 ForkJoinPool 工作窃取机制

ForkJoinPool 之所以高效，靠的是“工作窃取”——前提是线程能快速完成小任务。一旦遇到 I/O 阻塞，整个节奏就乱了：

• 被阻塞的线程既没法参与窃取，也没法释放资源给别人用
• 线程池里实际能干活的线程数量锐减，整体吞吐能力断崖式下滑
• 极端情况下，几个长时间执行的 I/O 任务就能让 commonPool 接近“瘫痪”，连简单的计算都排不上队

缺乏隔离性与可观测性

因为是全局共享池，你没法给不同业务场景单独做配置：

• 不能设置专属的拒绝策略、自定义队列，也没法监控特定任务的执行耗时
• 出问题的时候很难定位到底是哪个模块的 parallelStream 拖累了整个池子
• 在容器环境（比如 Kubernetes 限制了 CPU 配额）里，commonPool 可能误判可用算力，让调度失衡雪上加霜