并行流如何提升大数据处理效率？

不一定。parallelStream仅在计算密集型、数据量大且无强顺序依赖时才明显更快；小数据量因线程开销反而更慢，IO密集型还可能拖垮线程池。

parallelStream 在超大数据量下真比 stream 快吗？

不一定。它只在「计算密集型 + 数据足够大 + 无强顺序依赖」时才明显占优。小数据量反而因线程启动、拆分、合并开销更慢；IO 密集型任务（比如读文件、发 HTTP 请求）还可能把线程池拖垮。

• parallelStream 底层用的是 ForkJoinPool.commonPool()，默认线程数 ≈ CPU 核心数，不是无限扩容
• 如果集合是 ArrayList 或数组，拆分高效；但 LinkedList 或自定义 Collection 可能退化成单线程遍历
• 中间操作含 forEach、peek 等非线程安全操作，结果不可预测——要用 forEachOrdered 或同步写入

示例对比：对 1000 万个整数求平方和

list.stream().map(x -> x * x).reduce(0L, Long::sum);          // 单线程，稳定，易调试
list.parallelStream().map(x -> x * x).reduce(0L, Long::sum); // 多线程，快约 2.3×（8 核机器）

哪些操作会让 parallelStream 彻底失效？

一旦链中出现以下任一操作，性能可能不升反降，甚至出错：

• 使用了非线程安全的收集器，比如 Collectors.toCollection(ArrayList::new) —— 多个线程并发 add 会丢数据或抛 ConcurrentModificationException
• 出现 sorted()、limit()、findFirst() 等强顺序依赖操作：JVM 必须等全部分片完成再排序/截断，失去并行意义
• 自定义 Collector 没实现 CONCURRENT 特性标志，或 combiner 逻辑有状态（比如用了静态变量）

常见错误现象：java.util.ConcurrentModificationException 或结果每次运行都不一样

怎么安全地用 parallelStream 写入文件或数据库？

别直接在 forEach 里写。每个线程都去连 DB / 开文件句柄，大概率崩。

• 收集中间结果：用线程安全的容器，如 ConcurrentLinkedQueue，最后统一处理
• 或改用 collect(Collectors.groupingByConcurrent(...)) 分组聚合，再逐组落库
• 更稳妥的做法：先 parallelStream 计算出所有待写入对象，再用单线程批量插入（如 JdbcTemplate.batchUpdate）

注意：parallelStream 不解决 IO 瓶颈，只解决 CPU 计算瓶颈。磁盘或网络才是慢的根源。

替代方案比 parallelStream 更适合什么场景？

• 数据量在百万级以下，或需要严格顺序输出 → 老老实实用 stream + forEachOrdered
• 要控制并发度（比如最多 4 个线程调第三方 API）→ 别碰 commonPool，改用 CompletableFuture.supplyAsync(..., executor) 配自定义线程池
• 集合本身来自数据库游标或文件流（不能随机访问）→ parallelStream 根本没法拆分，直接报 UnsupportedOperationException

最容易被忽略的一点：parallelStream 的行为受 JVM 参数影响，比如 -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 会覆盖默认核数，线上环境常被误配成 1，等于白开。