Stream 并行化前先判断什么：数据规模、拆分与副作用

把 stream() 改成 parallelStream() 之前，先回答六个问题：数据是否足够大、每个元素的计算是否足够重、数据源能否均衡拆分、流水线是否包含昂贵的状态型操作、结果是否受顺序约束、lambda 与归约是否没有共享副作用。只要其中一项不成立，并行流就可能更慢，甚至产生不稳定结果。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/package-summary.html

第一道门：先保留顺序流基线

Stream 的并行模式不是另一个算法。Oracle 文档说明，整个流水线在终止操作执行时采用最近一次设置的顺序或并行模式；除明确允许非确定性的操作外，两种模式不应改变计算结果。优化前先把顺序版保留下来，固定输入、业务断言和顺序要求。

static long sequentialScore(List orders) {
    return orders.stream()
            // 只读取订单状态，不修改来源集合
            .filter(Order::paid)
            // 每个元素独立计算积分
            .mapToLong(Order::score)
            .sum();
}

static long parallelScore(List orders) {
    return orders.parallelStream()
            // 并行版保持相同过滤与映射语义
            .filter(Order::paid)
            .mapToLong(Order::score)
            .sum();
}

这里的终止操作是数值求和，映射函数不修改外部状态，适合作为候选。若两种方法对相同输入不能稳定返回相同结果，应先修正语义，不进入性能比较。

第二道门：数据规模必须和单元素成本一起看

没有一个对所有程序都成立的“超过多少条就并行”阈值。判断依据是总有效工作量，而不是元素数量本身。十万个简单整数加法可能不值得拆分；几千个独立、计算较重的变换反而可能有收益。

可以把成本理解为：

并行流更适合独立的 CPU 密集计算。把阻塞 I/O 直接塞进 parallelStream()，会把连接池容量、下游限流和线程等待混在同一个优化里，通常应改用明确的并发控制方案。

第三道门：数据源是否容易均衡拆分

Stream 的底层由 Spliterator 驱动。官方文档指出，高质量 Spliterator 会提供均衡且大小已知的拆分、准确的大小估算和可利用的特征；从未知大小 Iterator 构造的 Spliterator 往往只能提供较差的并行性能。

static void printSplitFacts(List orders) {
    Spliterator source = orders.spliterator();

    // 估算剩余元素数量，已知大小的数据源更容易规划拆分
    System.out.println("estimateSize=" + source.estimateSize());

    // 尝试拆出一部分，只用于诊断来源的拆分能力
    Spliterator left = source.trySplit();
    System.out.println("splitAvailable=" + (left != null));

    // 检查是否报告 SIZED 与 SUBSIZED 特征
    int required = Spliterator.SIZED | Spliterator.SUBSIZED;
    System.out.println("sizedSubSized=" + source.hasCharacteristics(required));
}

ArrayList、数组和数值范围通常比未知大小的迭代器更容易拆分。即便 trySplit() 返回非空，也要看分片是否均衡：若一个分片很大、其余分片很小，部分工作线程会提前空闲。

第四道门：状态型操作和顺序约束会放大成本

map、filter 这类无状态操作可以逐元素独立处理；sorted、distinct 等状态型操作可能需要观察大量甚至全部输入。官方文档明确提醒，并行流水线中的状态型中间操作可能需要多次遍历或缓冲大量数据。

遭遇顺序也会限制并行优化。例如有序流的 limit() 必须确保拿到“前 N 个”元素，可能需要额外协调和缓冲。如果业务不关心顺序，可在确认语义允许后使用 unordered()；它不是通用加速开关，只是解除不需要的顺序约束。

Set uniqueCodes = orders.parallelStream()
        // 业务不要求保持订单原始顺序时才解除顺序约束
        .unordered()
        .map(Order::code)
        // 使用标准归约收集，不手动修改共享集合
        .collect(Collectors.toSet());

第五道门：共享副作用要先移除

Stream 的行为参数必须无干扰，而且通常应无状态。若 lambda 修改来源集合、共享 ArrayList、计数器或缓存，顺序版可能“看起来能用”，并行版则会暴露数据竞争。给共享结构加锁虽然能保证部分安全，却可能让锁竞争吞掉并行收益。

static List unsafeNames(List orders) {
    List names = new ArrayList();
    orders.parallelStream()
            .filter(Order::paid)
            // 错误：多个线程同时修改非线程安全列表
            .forEach(order -> names.add(order.customerName()));
    return names;
}

static List safeNames(List orders) {
    return orders.parallelStream()
            .filter(Order::paid)
            .map(Order::customerName)
            // 正确：把可变累积交给 Collector 管理
            .toList();
}

副作用还存在可见性和执行顺序问题。即使最终结果保持 encounter order，也不能推断单个 mapper 在哪个线程、以什么先后顺序执行。调试日志可以使用，但不能用日志顺序证明业务顺序。

第六道门：归约必须允许任意拆分后再合并

reduce 能安全并行的前提，是 identity 真的是单位元，combiner 满足结合性，并且 accumulator 与 combiner 兼容。并行执行会在多个分片上形成部分结果，再把它们合并；如果不同分组方式产生不同答案，结果就不可靠。

static long totalScore(List orders) {
    return orders.parallelStream().reduce(
            0L,
            // 把当前订单合入分片的部分结果
            (partial, order) -> partial + order.score(),
            // 合并两个分片结果，数值加法满足结合性
            Long::sum
    );
}

字符串减法、依赖调用顺序的更新、把 identity 写成非中性初值，都会破坏这种契约。浮点加法还可能因分组方式不同产生舍入差异；如果业务要求逐位一致，应保留顺序算法或采用明确的数值策略。

最后才做性能对照

通过前五道门后，再用相同数据分布比较顺序版和并行版。基准至少要预热，并避免把数据构造、日志输出、网络等待和一次性类加载误算成 Stream 本身的成本。需要稳定微基准时，可使用 OpenJDK JMH；业务决策仍应回到目标部署环境，用真实数据大小和并发负载复查。

基准工具：https://openjdk.org/projects/code-tools/jmh/

@State(Scope.Thread)
public class StreamBenchmark {
    private List orders;

    @Setup
    public void setup() {
        // 在基准方法外准备固定输入，避免混入构造成本
        orders = TestOrders.fixedSample(100_000);
    }

    @Benchmark
    public long sequential() {
        // 顺序流作为稳定基线
        return sequentialScore(orders);
    }

    @Benchmark
    public long parallel() {
        // 并行流复用同一批输入与同一业务逻辑
        return parallelScore(orders);
    }
}

不要只看平均吞吐。还要观察尾延迟、CPU 利用率、分配与 GC、同进程其他任务是否受影响，以及并发请求下是否出现资源争用。单任务更快但整个服务吞吐下降，也不是有效优化。

并行化决策速查表

常见问题

数据超过一万条就应该用 parallelStream 吗？

不应该用固定条数判断。还要看每个元素的成本、来源拆分质量、合并成本、顺序约束和部署环境。

ArrayList 一定适合并行流吗？

它通常容易按索引拆分，但这只解决来源问题。若操作太轻、包含共享副作用或归约昂贵，仍可能没有收益。

给共享 List 加 synchronized 就安全吗？

可以避免部分数据竞争，但锁竞争可能抵消并行收益，顺序语义也未必满足。优先使用 toList()、collect() 或 reduce()。

unordered 会让结果随机吗？

它解除 encounter order 约束，并不自动随机数据。只有在业务不依赖原始顺序、后续操作也允许无序语义时才使用。

并行 Stream 的正确顺序是：先证明流水线可拆分、无共享副作用且归约可合并，再测量是否值得并行。把 parallel() 当成最后一个经过证据支持的开关，而不是优化的起点。