parallelstream 仅在任务计算量大、无强依赖且集合元素超1000时可能提速；小集合或i/o密集型操作反而更慢；cpu密集型任务更适配；需避免共享变量修改、谨慎处理异常与中断，并慎用自定义线程池。
ParallelStream 什么时候真能提速
并行不等于快。只有当任务本身计算量大、无强依赖、且集合足够大（通常 > 1000 元素）时，parallelStream() 才可能比 stream() 快。小集合或 I/O 密集型操作（比如每个元素都查一次数据库），反而因线程调度开销变慢。
- CPU 密集型任务（如数值计算、字符串解析）更适合并行
- 集合大小低于几百时，几乎总慢于串行流
- 底层用的是
ForkJoinPool.commonPool()，默认线程数 = CPU 核心数 - 1，无法自动适配长耗时阻塞操作
共享变量修改直接崩给你看
在 parallelStream() 里对普通变量（如 int count = 0）做 count++，结果必错——这不是线程安全问题，而是连基本执行顺序都无法保证。JVM 不保证并行流中各分支的执行次序，更不会帮你同步局部变量。
- 别在 lambda 里改外部局部变量（编译都过不去）
- 改
AtomicInteger或ConcurrentHashMap可以，但性能损耗大，不如换思路 - 优先用
collect()或reduce()：比如list.parallelStream().map(...).reduce(0, Integer::sum)
异常捕获和中断行为反直觉
parallelStream() 遇到第一个未捕获异常就终止整个流，但不会立刻抛出——它会等所有已启动的分支完成才把异常包装成 CompletionException 抛出。你看到的堆栈里，Caused by 才是真实错误位置。
- 不能靠 try-catch 包住整个流调用来“兜底”单个元素失败
- 想跳过异常元素？得在 map/filter 里自己 try-catch 并返回空值或默认值
- 中断信号（
Thread.interrupt()）对 commonPool 中的任务无效，别指望用它停掉并行流
自定义线程池不是加个参数就完事
想换线程池？别直接传 new ForkJoinPool(4) 给 parallelStream() ——它根本不接受。Java 8 没提供 API 替换 commonPool，只能靠反射或全局替换（危险），或者绕道：用 ForkJoinPool.submit(() -> list.parallelStream().forEach(...)).join()。
立即学习“Java免费学习笔记（深入）”；
- 全局替换
ForkJoinPool.commonPool()会影响所有用它的代码（包括 CompletableFuture），极不推荐 - 真正可控的做法：把数据分片，手动提交到自定义
ExecutorService，再用stream()处理每片 - 注意：
parallelStream()的分割策略基于Spliterator，对 LinkedList 或自定义集合可能退化为串行
并行流的“自动并行”只在理想路径上成立；一旦涉及状态共享、异常处理、线程控制或非标准集合，就得亲手接管逻辑，否则出问题连日志都难定位。
