parallelStream 默认共享 ForkJoinPool.commonPool()，其并行度为 CPU 核数减 1 且不可动态调整，IO 密集型任务易导致线程阻塞和性能下降；应按任务类型选用自定义线程池，并避免 forEach 等非线程安全操作。
parallelStream 默认用的是 ForkJoinPool.commonPool()
所有未显式指定线程池的 parallelStream，底层都走 ForkJoinPool.commonPool() —— 这是一个 JVM 全局单例，不是每个流独享的。它的并行度默认为 Runtime.getRuntime().availableProcessors() - 1（比如 16 核机器只有 15 个 worker 线程），且无法通过系统属性动态调整（ForkJoinPool.common.parallelism 只在 JVM 启动时读取一次）。
这意味着：你在 Service A 调用 list.parallelStream().map(this::callHttp)，同时 Service B 也在跑 data.parallelStream().filter(...).reduce(...)，它们实际在争抢同一组线程资源。一旦某个 IO 操作阻塞（如 HTTP 超时、数据库锁等待），整个 commonPool 就可能被拖慢甚至卡住。
IO 密集型任务用 parallelStream 会放大阻塞风险
常见错误现象：parallelStream 处理含网络/磁盘 I/O 的操作时，耗时反而比 stream 更长，甚至引发超时雪崩。
- 根本原因：commonPool 的线程数少 + 阻塞式 IO 让线程长时间空转，其他任务只能排队等待
- 典型场景：
.map(this::fetchFromRemoteApi)、.forEach(this::writeToFile)、.collect(toConcurrentMap(...))中混用非线程安全集合 - 性能影响：100 万条日志调用外部服务，parallelStream 耗时 45s，而顺序流仅 25s（实测数据）
如何隔离并行流线程池避免共享污染
不能改 commonPool，但可以绕过它 —— 把 parallelStream 的任务手动提交到自定义 ForkJoinPool 或普通 ThreadPoolExecutor。
推荐做法：
- 对 CPU 密集型任务（如数值计算、图像处理）：创建专用
ForkJoinPool，并行度设为availableProcessors() - 对 IO 密集型任务（如 HTTP 请求、DB 查询）：用
ThreadPoolExecutor，线程数按预期并发量设（如 50~200），避免偷懒复用commonPool - 关键代码模式：
final ForkJoinPool customPool = new ForkJoinPool(8); customPool.submit(() -> list.parallelStream().map(...).collect(...)).join();
- 注意：不要在每次调用时新建
ForkJoinPool，应复用或交由 Spring 管理为 bean
collect 和 forEach 的线程安全陷阱必须手动兜底
parallelStream 不保证中间操作线程安全，尤其 forEach 是无序且不保证原子性的；collect 若用非并发收集器（如 Collectors.toList()），结果虽正确但内部仍依赖同步机制，性能打折。
容易踩的坑：
- 误用
forEach修改共享ArrayList→ 数据丢失或ConcurrentModificationException - 用
Collectors.toMap()但 key 冲突未指定 merge 函数 → 运行时报IllegalStateException: Duplicate key - 期望结果有序却用了
parallelStream().forEach()→ 实际执行顺序完全不可控 - 正确姿势：
collect(Collectors.toConcurrentMap(...))或先map再collect(toList())，避免副作用
真正难处理的不是“怎么写并行流”，而是判断“该不该用并行流”——当你的任务里出现 Thread.sleep、HttpClient.execute、FileInputStream.read 这类调用，就该立刻停手，换 CompletableFuture.supplyAsync 配合自定义线程池，而不是硬套 parallelStream。
