Java Stream API并行流（Parallel Stream）底层实现原理

Java Stream API的并行流基于Fork/Join框架实现分治调度，通过Spliterator拆分任务、Work-Stealing均衡负载、combiner/merger安全合并结果，但仅适用于计算密集型大数据量场景。

Java Stream API 的并行流（parallelStream()）不是简单地“开多线程”，而是基于一套成熟、精细的分治调度机制实现的。它的核心在于自动拆分任务、均衡调度执行、安全合并结果，全程对开发者透明。

基于 Fork/Join 框架构建分治流水线

并行流的底层完全依托于 Java 的 Fork/Join 框架，这是专为递归分治型任务设计的并发框架。当你调用 parallelStream() 时，整个处理流程被划分为三个阶段：

• Fork（拆分）：数据源（如 ArrayList、HashMap 等）通过 Spliterator 接口被递归切分成更小的、可独立处理的块；切分策略因数据结构而异——ArrayList 支持随机访问，切分高效；HashSet 则按哈希桶粗粒度划分。
• 并行执行：每个子块作为独立任务提交到默认的 ForkJoinPool.commonPool()；JVM 根据可用 CPU 核心数动态设定并行度（通常为 Runtime.getRuntime().availableProcessors() - 1）。
• Join（合并）：各线程完成局部计算后，中间结果按操作语义（如 reduce 的 combiner、collect 的 merger）逐层合并，最终生成统一结果。

Spliterator 是并行能力的源头

串行流靠 Iterator 顺序遍历，而并行流依赖 Spliterator——它不仅可遍历，更关键的是能 split。一个 Spliterator 可以不断调用 trySplit() 方法，将自身一分为二，直到子任务足够小（例如元素数 ≤ 阈值 1024 或已不可再分）。这个过程决定了：

• 是否支持并行（characteristics() 返回 SIZED | SUBSIZED | IMMUTABLE 等特征）
• 切分是否均衡（如 ArrayListSpliterator 能精确按索引中分，而 LinkedHashSetSpliterator 只能近似）
• 是否保留 encounter order（影响 findFirst、forEachOrdered 等有序操作的正确性）

工作窃取（Work-Stealing）保障负载均衡

任务并非静态绑定到线程。ForkJoinPool 中每个线程维护自己的双端队列（deque），新任务压入队尾，执行时从队首取；当某线程队列空了，它会去其他线程队列的尾部“窃取”一个任务。这种设计带来两个好处：

立即学习“Java免费学习笔记（深入）”；

• 避免空闲线程等待，提升 CPU 利用率
• 窃取尾部任务可减少数据竞争（因原线程刚压入，该任务尚未开始执行，状态更“新鲜”）

这使得即使某些子任务耗时差异大，整体吞吐仍较稳定。

结果合并需谨慎：不是所有操作都线程安全

并行流本身不保证中间操作线程安全，终端操作才是关键分水岭：

• ✅ 安全操作：map、filter、reduce（提供 combiner）、collect（使用线程安全的 Collector，如 Collectors.toList()）
• ❌ 危险操作：forEach 直接修改共享变量（如 list.add()）、peek 打印日志但未同步、自定义无状态但非幂等的函数

例如：.forEach(result::addAll) 是典型错误——addAll 不是原子操作，多个线程并发调用会导致数据丢失或 ConcurrentModificationException。应改用 collect(Collectors.toList()) 或 forEachOrdered（牺牲部分并行性保序）。

不复杂但容易忽略：并行流提速的前提是任务计算密集且数据量足够大。小集合或 I/O 绑定操作反而因调度开销而变慢。