java stream并行流基于fork/join框架，采用工作窃取机制，默认使用forkjoinpool.commonpool()，线程数为cpu核心数−1；性能依赖spliterator质量，要求终端操作满足无状态、无干扰、可结合性，避免阻塞操作影响全局线程池。
Java Stream并行流在大规模数据处理中采用的是基于Fork/Join框架的分治式并发模型，不是简单的线程池轮询或任务队列调度，而是将数据源递归拆分为可独立计算的子任务，由工作窃取（Work-Stealing）线程池协同执行。
底层运行机制：ForkJoinPool + 工作窃取
并行流默认使用ForkJoinPool.commonPool()，其线程数通常为CPU核心数 − 1（例如8核机器默认7个并行线程）。该池采用“双端队列+工作窃取”策略：每个线程维护自己的任务队列，空闲时主动从其他线程队列尾部“窃取”任务，避免线程饥饿，提升负载均衡性。这种设计特别适合树形递归拆分的计算任务，天然适配Stream的split→compute→combine流程。
数据拆分依赖Spliterator
并行流能否高效执行，关键取决于数据源是否提供高质量的Spliterator：
- ArrayList、数组、IntStream.range等：支持O(1)随机访问，能实现均匀、低成本的二分拆分，性能最优；
- LinkedList、Stream.iterate生成的流：只能顺序遍历，Spliterator被迫线性扫描拆分，开销大且不均，易导致部分线程长期空闲；
- 自定义集合可通过重写spliterator()方法，返回支持SIZED | SUBSIZED | IMMUTABLE特性的Spliterator，显著改善并行效率。
结果合并遵循无状态与结合律
并行流要求终端操作满足无状态、无干扰、可结合（associative）三原则，才能安全合并子任务结果：
- sum()、count()、max()、reduce(…)：天然满足结合律，无需额外同步；
- findFirst()、limit(n)、sorted()：强依赖顺序，会强制转为串行处理或引入全局排序/索引协调，大幅削弱并行收益；
- collect(Collectors.groupingByConcurrent())：内部使用ConcurrentHashMap，避免同步瓶颈；而groupingBy()则需全局锁或复制中间map，不推荐用于并行流。
线程上下文与资源隔离考量
commonPool是JVM全局共享的，若并行流中混入阻塞操作（如数据库查询、HTTP调用），会导致整个池卡死，影响其他模块。此时应：
- 对I/O型任务，改用CompletableFuture.supplyAsync(task, customPool)配合专用线程池；
- 对长耗时CPU任务，显式创建new ForkJoinPool(parallelism)并调用stream.parallel().unordered().collect(...)；
- 通过System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "N")调整commonPool大小（仅适用于启动前配置）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
