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 绑定操作反而因调度开销而变慢。
