并行流处理几十到几百个元素时性能反差源于任务调度与线程开销压倒计算收益，而非线程竞争；根本原因是ForkJoinPool的任务拆分、队列操作、工作窃取及上下文切换等固有成本远超微秒级计算本身。
并行流在处理极小批量任务（比如几十到几百个元素）时，性能反而比顺序流差，核心原因不是“线程竞争”主导，而是**任务调度与线程开销压倒了计算收益**。所谓“线程竞争”在此类场景中往往被误读——真正拖慢速度的是 ForkJoinPool 的任务拆分、队列入队/出队、工作窃取协调、以及线程上下文切换等固有成本，而非多个线程争抢同一把锁。
为什么“竞争”不是主因？
对极小数据量调用 .parallel()，JVM 会尝试将流拆分为子任务（通过 Spliterator），但拆分粒度可能远大于实际元素数。例如，100 个整数可能只拆成 1–2 个任务，根本达不到多线程并发执行的条件；即便强行派发，ForkJoinPool.commonPool() 中的线程也需争抢任务队列，而此时每个任务执行时间微乎其微（纳秒级），线程唤醒、调度、合并结果的开销已占绝对大头。
如何验证是开销问题而非锁竞争？
可从三方面快速排查：
-
禁用并行流的默认池，改用单线程池：用
ForkJoinPool(1)执行相同并行流，若耗时仍显著高于顺序流，说明瓶颈在拆分/合并逻辑本身，而非多线程协作冲突； -
检查是否用了非线程安全的共享状态：如在
forEach中修改静态变量或外部集合，此时确实会触发同步（如 synchronized block 或 CAS 自旋），可用 JFR（Java Flight Recorder）抓取锁事件，观察java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject是否高频出现； -
对比 reduce 和 collect 行为：若用
reduce(0, Integer::sum)性能尚可，但换成collect(Collectors.toList())明显变慢，大概率是 ArrayList 的 add 操作在多线程下触发扩容竞争（内部数组复制+volatile 写），这时才是典型的写竞争。
实操建议：避免在小批量场景误用并行流
无需复杂压测，记住两个硬指标：
- 元素数量 且每个元素处理逻辑 （如简单加法、字符串 length()），一律用顺序流；
- 若业务强制要求“统一走 parallel 流”，可在入口加轻量判断：
if (list.size() - 不要试图通过
System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "1")来“优化”小任务——这等于废掉并行能力，还污染全局配置。
真遇到竞争，优先换操作方式而非加锁
例如需要统计频次：
- ❌ 错误：用
parallelStream().forEach(i -> map.merge(i, 1, Integer::sum))—— HashMap 非线程安全，多线程写必然竞争； - ✅ 正确：改用
parallelStream().collect(Collectors.groupingByConcurrent(i -> i, Collectors.summingInt(i -> 1)))，底层使用 ConcurrentHashMap，无显式锁，吞吐更高。
