Java并行流map未保序及findFirst短路失效问题咨询

问题背景 #

Stream包的JavaDoc明确说明：若流的源是包含[1,2,3]的List，执行map(x -> x*2)的结果必须为[2,4,6]。但通过以下代码验证时，输出不符合预期：

Optional<String> result = Stream.of(1, 2, 3, 4).parallel().map(i -> {
    try {
        if (i == 1) {
            Thread.sleep(1000);
        }
    } catch (Exception e) {
    }
    return "" + i;
}).peek(x -> {
    System.out.println(Thread.currentThread().threadId() + " Peeking " + x);
}).findFirst();

System.out.println(result);

实际输出 #

1 Peeking 3
23 Peeking 4
21 Peeking 2
22 Peeking 1
Optional[1]

疑问点 #

• map操作后的流不应以“1”为首吗？
• 即使在parallel()前添加unordered()，结果仍为Optional[1]，为何findFirst未返回任意值反而等待1的操作完成？
• 仅移除unordered()和parallel()时，findFirst才会短路，但并行且无序时为何不短路？

按建议将peek改为map后的测试代码：

map(x -> {
    System.out.println("Remapping " + x);
    return "x"+x;
})

修改后输出 #

Remapping 2
Remapping 4
Remapping 3
Remapping 1
Optional[x1]

核心原因解析 #

1. map操作后的流顺序问题 #

要明确：并行流的中间操作执行顺序不影响最终流的"逻辑顺序"。JavaDoc里说的map结果是[2,4,6]，指的是流的逻辑顺序和源一致，不是实际执行时的物理处理顺序。

你看到peek或map的输出顺序是乱的，这只是并行线程各自处理元素的先后，不代表流的逻辑顺序。流内部始终维护着元素和源的对应关系，所以最终findFirst找的还是源里的第一个元素——也就是1，不管它是最后被处理的。

2. unordered()为何不改变findFirst的结果？ #

unordered()只是告诉流不需要维护逻辑顺序，允许更高效的并行处理，但findFirst的语义是返回流的第一个元素（逻辑顺序上的第一个），除非你用findAny()。哪怕流是无序的，findFirst依然会严格对应源的第一个元素，所以它必须等这个元素处理完成才能返回，不会随便拿一个已处理的元素凑数。

如果想让并行流中尽快返回任意已处理的元素，应该用findAny()而非findFirst()。

3. 并行流为何不短路？ #

串行流中findFirst会短路，是因为它按顺序处理，找到第一个元素就停了。但并行流不一样：

• 并行流启动时会把元素分配给多个线程同时处理，哪怕你要找的是逻辑上的第一个元素，其他线程可能已经开始处理后面的元素了，这些处理不会被中断（线程调度的开销比处理完元素更大）。
• 而且findFirst必须确保拿到的是逻辑顺序的第一个元素，所以哪怕其他元素先处理完，它也得等那个对应的元素处理完成才能返回，所以看起来没有"短路"效果。

内容的提问来源于stack exchange，提问作者Priyshrm