并行流不一定更快，仅在数据量大（≥10,000）、操作cpu密集、数据源支持高效分割时才提速；需避免公共线程池瓶颈、共享变量竞态、装箱开销及错误收集方式。
并行流不一定更快——它只在特定条件下带来性能收益，用错场景反而更慢。
什么时候 parallelStream() 真的能提速
并行流提速的前提是：数据量大 + 操作计算密集 + 数据源支持高效分割。三者缺一不可。
-
数据量门槛通常在 10,000+ 元素：少于这个量级时，任务拆分、线程调度、结果合并的开销往往超过并行收益 -
操作必须是 CPU 密集型：比如map(x -> x * x + 2 * x + 1)、filter(n -> isPrime(n))；而map(x -> httpGet(x))或文件读写这类 I/O 操作，线程会大量阻塞，实际吞吐可能下降 -
数据源需支持随机访问：ArrayList、数组、IntStream.range()表现好；LinkedList、Stream.generate()或自定义迭代器几乎无法有效拆分，并行后可能比串行还慢
为什么默认的 ForkJoinPool.commonPool() 常成性能瓶颈
公共池被所有并行流（以及 ForkJoinTask、CompletableFuture）共享，且默认线程数 = Runtime.getRuntime().availableProcessors()，不区分任务类型。
- 多个并行流同时运行时，会互相抢占线程，导致任务排队、延迟升高
- CPU 密集型任务建议并行度设为
coreCount + 1；若混有短时阻塞（如日志写入），可适度提高，但不宜盲目乘以 2 - 避免全局污染：用自定义池隔离关键任务
int parallelism = Math.min(8, Runtime.getRuntime().availableProcessors() + 1); ForkJoinPool customPool = new ForkJoinPool(parallelism); <p>List<String> result = customPool.submit(() -> dataList.parallelStream() .filter(s -> s.length() > 5) .map(String::toUpperCase) .collect(Collectors.toList()) ).join();
forEach / collect / reduce 的线程安全陷阱
并行流中任何修改共享变量的操作都极易出错，不是“加个 synchronized 就完事”那么简单。
立即学习“Java免费学习笔记（深入）”；
-
forEach不保证顺序，且counter++这类操作必然竞态——结果小于预期是常态 -
collect必须搭配线程安全的收集器：Collectors.toList()是安全的，但new ArrayList()手动 add 就不行 - 分组统计优先用
Collectors.groupingByConcurrent()，而非groupingBy()+ConcurrentHashMap手动传入（后者仍可能因 merge 阶段不安全而出错）
别忽略基础类型流和装箱成本
用 List<integer></integer> 走 parallelStream()，每一步 map/filter 都触发自动装箱/拆箱，性能损耗可达 30% 以上。
- 优先用原始类型流：
IntStream.rangeClosed(1, 1_000_000).parallel().sum() - 若已有
List<integer></integer>，先转数组再流：numbers.stream().mapToInt(Integer::intValue).toArray()→Arrays.stream(arr).parallel() - 避免在并行流中间环节做
boxed()，尤其大数据量下
真正决定并行流快不快的，从来不是“开了 parallel”，而是你是否看清了数据规模、操作性质、线程池状态和收集方式这四个刚性约束——漏掉任何一个，就只是把串行 bug 换成了并发 bug。
