并行流并非总能加速，仅在数据量≥10万、单元素处理≥1ms、操作无状态且数据源高效时才有效；需避免forEach写共享集合，改用collect；parallelStream()语义更清晰；可通过日志验证多线程执行。
直接用 parallelStream() 或在已有流上调用 parallel() 就能开启并行，但是否真能加速，取决于数据规模、操作类型和共享状态——不是所有场景都适合。
什么时候调用 parallelStream() 才真正有效
并行流不是“开了就快”，它背后是 ForkJoinPool.commonPool()，默认线程数等于 CPU 核心数。如果任务太轻或数据太小，线程调度和结果合并的开销反而拖慢整体性能。
- 数据量建议 ≥ 10 万条（比如
ArrayList或数组） - 单个元素处理耗时 ≥ 1ms（如复杂计算、IO 模拟、正则匹配）
- 操作必须无状态：只读、不修改外部变量，避免
forEach直接往ArrayListadd - 避免
LinkedList、Stream.generate()等低效分割的数据源
为什么 forEach 在并行流里容易出错
常见错误是把串行习惯直接搬过来，比如用 forEach 往一个共享 ArrayList 写数据：
List<Integer> result = new ArrayList<>();
numbers.parallelStream()
.filter(n -> n % 2 == 0)
.forEach(result::add); // ❌ 非线程安全，可能丢数据、抛 <code>ConcurrentModificationException</code>正确做法是用 collect() 或 toList()（Java 16+）让框架内部完成线程安全聚合：
List<Integer> result = numbers.parallelStream()
.filter(n -> n % 2 == 0)
.map(n -> n * 2)
.collect(Collectors.toList()); // ✅ 安全且高效
parallel() 和 parallelStream() 的区别与选型
二者最终行为一致，但创建时机不同，影响可读性和调试成本：
-
list.parallelStream()：推荐，语义清晰，从源头明确声明并行意图 -
list.stream().parallel()：可用于已有流对象的动态切换，但易被忽略，尤其在链式调用中埋下隐患 - 注意：一旦调用
parallel()，后续所有中间操作（filter、map）和终止操作（reduce、collect）都会走并行路径，无法中途切回串行
如何验证并行是否真的起作用
不能只看耗时，要确认线程是否实际参与。加一句日志就能观察：
numbers.parallelStream()
.filter(n -> {
System.out.println("Thread: " + Thread.currentThread().getName() + ", value: " + n);
return n % 2 == 0;
})
.count();如果输出中出现多个 ForkJoinPool.commonPool-worker-X，说明已并行；若全是 main 线程，则流被退化为串行（常见于空集合、极小数据或 JVM 自动优化）。
另外，ForkJoinPool.commonPool() 是全局共享的，如果其他模块也在大量使用并行流或 CompletableFuture，可能造成线程争抢——这时要考虑自定义线程池，但那是更复杂的边界情况了。
