Java Stream并行收集器保持结果顺序的设计

我在把一批带有序号的业务记录改成并行 Stream 后，最先遇到的误解是“线程执行顺序变了，结果一定也乱了”。实际要分开看：处理完成顺序可以乱，非并发 Collector 的合并结果仍可以保持源的遇到顺序。如果改用 groupingByConcurrent、toConcurrentMap 或自定义并发容器，就必须接受并发写入不承诺到达顺序；业务若仍要稳定展示，应该保留源序号，最后显式排序。

先分清三种顺序

ArrayList、数组和大多数顺序 Stream 都有 encounter order。线程拿到分片后，某个分片可能先算完，但这只是处理完成顺序；终端收集时，普通List Collector可以把左侧分片放在右侧分片之前，恢复源顺序。真正需要警惕的是调用 unordered()，或选择明确声明 UNORDERED 的收集器，这会告诉运行时顺序不再是结果契约。

需要保序时优先使用合并型Collector

下面的写法把耗时映射放到并行阶段，收集仍交给标准List Collector。它不要求多个线程同时写同一个ArrayList，而是先产生若干局部容器，再由框架合并，因此不需要给共享List额外加锁。

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

// 并行计算每个位置，再由非并发Collector按遇到顺序合并结果
List result = IntStream.range(0, source.size())
        .parallel()
        .mapToObj(index -> {
            String value = source.get(index);
            // 昂贵转换发生在并行分支；不要在这里修改共享集合
            return normalize(value);
        })
        .collect(Collectors.toList()); // 结果List保持源索引顺序

这段代码的边界是：source 在计算期间不能被其他线程修改，normalize 也不应依赖未同步的共享可变状态。若只是按键分组，Collectors.groupingBy 的合并成本可能比串行更明显，但它的取舍仍是“合并换保序”，不能直接换成 groupingByConcurrent 后再假定每组List有源顺序。

并发收集为什么会丢掉到达顺序

Oracle 对 Collector 的定义很明确：CONCURRENT表示同一个结果容器可以被多个线程累加，UNORDERED表示收集操作不承诺保留输入遇到顺序。当并行流、并发收集器和无序条件同时满足时，运行时可以走 concurrent reduction；多个线程写入共享容器的先后不再代表源数据顺序。

既要并行吞吐又要稳定输出

当并发收集确实值得采用，而前端或下游接口又要求固定顺序时，可以把位置当作数据的一部分。先并行计算 Indexed，并发阶段只负责生成结果；输出边界再按 sourceIndex 排序。这样“计算完成先后”和“展示顺序”被明确隔离。

record Indexed(int sourceIndex, T value) {}

// 先保留源位置，避免把线程完成顺序误当成业务顺序
List> indexed = IntStream.range(0, source.size())
        .parallel()
        .mapToObj(index -> new Indexed(index, normalize(source.get(index))))
        .collect(Collectors.toList());

// 在交付给调用方前恢复稳定顺序；比较器只看源位置
List ordered = indexed.stream()
        .sorted(java.util.Comparator.comparingInt(Indexed::sourceIndex))
        .map(Indexed::value)
        .toList();

如果只需要固定位置，先用普通 toList 已经足够；带序号方案主要用于结果需要跨线程汇聚、分批落盘或经过并发Map的场景。不要为了“看起来并行”给每个小任务都套 parallel，任务粒度太小、排序和线程调度开销反而会抵消收益。

常见问题

parallelStream的结果一定乱序吗？

不一定。对有遇到顺序的源使用非并发、非无序的收集方式，框架可以在合并局部结果时恢复顺序；只有在业务放弃顺序或收集器明确无序时，才不要依赖它。

把ArrayList改成ConcurrentLinkedQueue就能保序吗？

不能。线程安全只解决并发访问问题，不会把线程的写入先后变成源数据顺序；需要稳定顺序时，使用合并型Collector或显式序号排序。

什么时候选择groupingByConcurrent？

当结果只要求按键聚合，不要求键内元素按源顺序排列，并且分组写入的吞吐收益能覆盖额外调度成本时再选择它。

判断标准可以压缩成一句话：顺序是接口契约就保留遇到顺序或携带序号，顺序不是契约才使用 unordered 和并发 Collector 换取更直接的共享写入。