parallel() 并非调用即并行，实际执行取决于 ForkJoinPool.commonPool() 线程可用性及数据源是否支持高效分割（如 ArrayList 可、LinkedList 不可）；常见错误包括共享变量非原子操作、forEach 无序不安全、未预热导致性能误判，优化关键在确认其真比串行快且无竞态。
parallel() 什么时候真正并行？
Java 8 的 Stream.parallel() 不是“调了就并行”，它只是把流标记为「可能并行」，最终是否并行取决于底层的 ForkJoinPool.commonPool() 是否有空闲线程，以及数据源是否支持高效分割（比如 ArrayList 可以，LinkedList 就不行）。
常见错误现象：parallel().map(...).count() 在小数据量（比如 sequential() 还慢——因为任务拆分、线程调度、结果合并的开销压倒了计算收益。
- 使用场景：适合 CPU 密集型、无状态、可分割、单次处理耗时 ≥ 100μs 的操作（如解析 JSON 字段、数值计算）
- 不适用场景：IO 操作（DB 查询、HTTP 调用）、含同步块或共享可变状态的 lambda、数据量
- 验证是否真并行：在 lambda 里加
System.out.println(Thread.currentThread().getName())，看到多个ForkJoinPool.commonPool-worker-X才算生效
默认并行阈值怎么改？
Stream 并行不是按“元素个数”切分，而是按「任务拆分成本模型」决定的。底层用的是 CountedCompleter + 动态阈值，但这个阈值由 java.util.stream.SizeHelper 控制，**用户不能直接配置**——你看到的“阈值”其实是 ForkJoinTask 拆分策略的副作用。
真正能干预的只有两件事：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 强制指定最小拆分粒度：用
Arrays.stream(arr, from, to)或IntStream.range(0, n).parallel()手动控制范围，避免小集合被强行进 commonPool - 替换公共池：通过
-Djava.util.concurrent.ForkJoinPool.common.parallelism=4调整线程数（注意：这是 JVM 全局设置，影响所有使用 commonPool 的代码） - 更稳妥的做法：不用 commonPool，自己构造
ForkJoinPool，用stream.parallel().collect(toList())前先pool.submit(() -> stream.collect(...)).get()
parallel() 导致结果错乱的典型原因
并行流本身线程安全，但你的 lambda 不一定安全。最常踩的坑是「以为 map/filter 是纯函数，其实偷偷改了外部变量」。
错误示例：list.parallelStream().map(s -> { counter++; return s.toUpperCase(); }) —— counter 是共享变量，++ 非原子操作，结果必然少计数。
- 正确做法：用
mapToInt+sum()、collect(Collectors.toList())等归约操作，让 Stream 自己管理中间状态 - 如果必须累积状态，用
Collectors.groupingByConcurrent()或Collectors.toConcurrentMap()，别自己 new HashMap - 注意
forEach()在并行流里不保证顺序，且不是线程安全的消费方式；要用forEachOrdered()（牺牲并行性）或收集后再遍历
性能对比必须测什么？
只跑一次 System.nanoTime() 差值没意义。JIT 编译、GC、commonPool 预热都会干扰结果。
- 至少预热 5 轮，再测 10 轮取平均（用 JMH 最好，手写至少用
Thread.sleep(100)隔开轮次） - 对比组必须一致：都用
toArray()或都用collect(toList())，别一个 collect 一个 forEach - 监控线程池状态：
ForkJoinPool.commonPool().getActiveThreadCount()和getQueuedSubmissionCount()，如果后者持续 > 0，说明任务积压，线程数不够或任务太重 - 特别注意 GC：并行流临时对象多，小堆下容易触发频繁 Young GC，用
jstat -gc看真实耗时是否被 GC 吃掉
并行流的优化点从来不在“怎么开”，而在“开之前有没有确认它真比串行快、且不会引入竞态”。阈值没法配，但数据规模、任务性质、共享状态这三样，漏看任何一样，都白调 parallel()。
