Java 并行流为什么不一定更快：ForkJoinPool 基线与压测边界

线上批处理有一段纯计算逻辑，换成 parallelStream() 后耗时没有下降，反而在小批次请求上更抖，这并不奇怪。并行流的收益来自足够大的可拆分任务和可用的 CPU，而不是来自“多开几条线程”本身。把基线、任务粒度和共享资源拆开测，才能知道这次改动到底值不值得。

先用同一份输入测出串行基线，再把数据量、并行度、CPU 占用和尾延迟一起记录；只有在任务足够重、拆分成本可接受且不会挤占公共线程池时，并行流才适合进入生产代码。

先把串行基线测出来

很多人踩过的常见误区是只跑一次并行版本，然后把结果和开发机上随手执行的串行版本直接比快慢。JIT 预热、缓存命中、垃圾回收和输入遍历顺序都会让这类比对出来的数字完全失真。做实验先把输入固定，连续执行多轮，丢掉前几轮的预热数据，同时记录耗时的中位数与 P95 分位值。

下面的示例故意把计时结果放在返回值里，避免把日志输出的开销混进热路径。真实项目可以直接对接 JMH 做正式基准测试；文章里的微型实验只用来观察趋势，不能替代正规的性能校验流程。

record BenchResult(long elapsedNanos, long checksum) {}

static BenchResult measure(List values, boolean parallel) {
    long begin = java.time.Instant.now().toEpochMilli();
    long checksum = (parallel ? values.parallelStream() : values.stream())
            .mapToLong(value -> expensiveTransform(value))
            .sum();
    long elapsed = java.time.Instant.now().toEpochMilli() - begin;
    return new BenchResult(elapsed * 1_000_000L, checksum);
}

测试时必须核对 checksum 一致。结果不一致，通常是累加器、缓存或 lambda 外部状态存在并发安全问题；这时不该继续讨论“快了多少”。

并行流实际把任务交给了谁

Java 文档把串行与并行视为同一条流流水线的两种执行模式。集合调用 parallelStream() 只是打开并行模式，后续操作仍然受数据源拆分能力、每个元素的计算量和终结操作影响。

没有显式指定执行池时，相关任务通常会进入 ForkJoinPool.commonPool()。这个公共池并不只服务当前方法：应用里的其他 Fork/Join 任务也可能使用它。开发机上看到的加速，到了 Web 服务里可能变成线程竞争。

图里体现的核心逻辑不是开的线程越多性能越好，而是要看单元素任务本身是否足够“重”。如果每个元素只做一次简单字段读取，拆分、调度和结果合并的成本可能已经超过计算本身的开销，并行反而更慢。

三个变量决定结果：粒度、数据源和共享资源

任务粒度太小，调度成本会反超

一万条简单整数相加的场景，几乎完全不值得用并行；如果是一万条需要复杂解析或者压缩计算的记录，并行才有发挥空间。可以先把单元素计算逻辑封装成稳定的纯函数，再逐步扩大输入批次观察耗时变化曲线，不要一开始就拿真实接口的混合逻辑直接压测。

数据源不容易拆分，线程也救不了它

数组和支持随机访问的集合通常很容易做均匀切片，链表、慢速迭代器或者读取时需要加锁的数据源就完全不一样。即便最终套上了并行流的语法，拆分器拿不到均匀的任务区间，部分线程会提前空闲，最后剩下的合并成本反而拖慢整体速度。

共享状态会把“并行”变成排队

在流操作里向普通 ArrayList 追加、修改共享缓存，或者把每个元素都写进同一把锁保护的对象，都会改变测量结果。优先使用无副作用的 map/reduce，让终结操作负责合并；如果必须写外部资源，先重新评估是否应该使用批量接口。

一组可复现的压测对比

可以用三组输入做第一轮效果校验：小批次 1 万条、中批次 10 万条、大批次 100 万条；每组分别运行串行和并行版本，全程用相同的校验和确认运算结果完全一致。示例环境为 8 个逻辑处理器，复杂计算函数只做纯 CPU 运算，不访问网络和数据库资源。

这组数字不是通用的性能承诺值，重点是比对的思路。如果把公共池同时交给 HTTP 回调、缓存刷新和这段批处理逻辑共用，业务全链路压测里的 P95 耗时可能比单独压测的结果差很多。把 CPU 利用率、公共池活跃线程数、GC 暂停和请求尾延迟放在同一张观测表里统计，才有足够的决策依据。

什么时候应该停在串行版本

有三种场景我会直接保留串行实现：单批次数据量很小且调用非常频繁；每个元素的处理逻辑包含阻塞 I/O；并行流会和核心业务请求共用公共池。尤其是阻塞 I/O 场景，Fork/Join 框架的线程补偿机制也不能替代正确的异步线程模型，Oracle 官方文档也明确提醒，阻塞 I/O 或者未托管同步的场景下，框架不会自动补足可用线程。

如果确实需要独立的并发边界，先把批处理逻辑从请求处理线程里剥离出来，再选择自带可观测能力、支持优雅关闭的专用执行器，或者改成消息队列批量消费的模式。不要为了绕开公共池的限制，直接把并行流嵌套到另一个并发池里运行；嵌套之后的依赖关系非常乱，很难排查谁在等待谁。

常见问题

并行流默认会使用多少个线程？

它通常参与 ForkJoinPool.commonPool()，并行度受运行环境和公共池配置影响。不要把某台机器上的线程数当成固定契约，部署到容器或共享服务后应重新测量。

把 stream() 改成 parallelStream() 就能提速吗？

不能。数据量大小、拆分方式、单元素计算量、合并成本和共享资源占用情况都会改变最终结果。先测好串行的基线耗时，并用校验和确认两种实现做的是完全相同的运算逻辑。

为什么本地并行更快，线上反而变慢？

线上环境通常有更多任务共享公共池，还会叠加 CPU 配额限制、GC 波动、请求尾延迟和其他锁竞争开销。把真实业务的混合负载加入压测流程，重点观察 P95/P99 分位耗时，通常比继续调大并行度更有实际价值。

把压测结果变成上线规则

最终可以把结论沉淀成团队内的统一规则：只有当输入规模超过预先测得的性能阈值、计算函数没有外部副作用、串行和并行结果校验和一致，并且混合负载下尾延迟没有恶化时，才允许使用并行流。阈值可以放进基准测试或者回归脚本里，JDK 版本升级、机器规格变化之后再重新跑一遍校验，避免“曾经在某台机器上跑通过”的经验变成长期的线上隐患。