流中间操作排序

Question

是否可以保证在使用流时，中间操作将按程序顺序执行？ 我怀疑是这种情况，或者它会导致非常微妙的错误，但我找不到明确的答案。

例：

List<String> list = Arrays.asList("a", "b", "c");
List<String> modified = list.parallelStream()
        .map(s -> s + "-" + s)                 //"a-a", "b-b", "c-c"
        .filter(s -> !s.equals("b-b"))         //"a-a", "c-c"
        .map(s -> s.substring(2))              //"a", "c"
        .collect(toList());

这保证总是返回["a", "c"]或["c", "a"]吗？ （如果最后一个映射操作在第一个映射操作之前执行，则可能抛出异常 - 类似地，如果在第二个映射操作之后执行过滤器，则“b”将保留在最终列表中）

Answer 1

关于原始问题中嵌入的排序实际上有几个问题。

Holger的答案涵盖了管道中流操作的顺序。 对于特定的流元素 ，管道操作必须按程序中的描述执行，因为通常，类型必须匹配，并且因为它以任何其他方式执行它是没有意义的。 从原始示例开始，流库无法对操作进行重新排序，就像它们已被写入一样，

List<String> modified = list.parallelStream()
    .filter(s -> !s.equals("b-b")) // these two operations are swapped
    .map(s -> s + "-" + s)         // compared to the original example
    .map(s -> s.substring(2))
    .collect(toList());

因为那时结果将是[a，b，c]。 这不会发生。

最初的问题是答案是[c，a]而不是[a，c]。 这实际上是关于不同类型的排序的问题，我们将其称为遭遇顺序 。 java.util.stream包文档中提到了这个概念。 不幸的是，在我所知道的任何地方都没有明确定义。 简而言之，它涉及流内元素的相对定位（与执行顺序相反）以及该定位是否具有任何语义。

例如，考虑源自HashSet和ArrayList的流。 基于HashSet的流没有定义的遭遇顺序，换句话说，它是无序的。 如果你将一堆元素放入一个HashSet然后迭代它们，它们会以某种顺序出现，这可能与你放入它们的顺序无关。

但是，基于List的流确实具有已定义的遭遇顺序。 在原始示例中，列表是[a，b，c]，并且显然“a”在“b”之前出现在“c”之前。 这种定位通常由从源到输出的流操作保留。

让我修改原始示例以显示遭遇订单的重要性。 我所做的就是改变原始列表中字符串的顺序：

List<String> list = Arrays.asList("c", "b", "a");
List<String> modified = list.parallelStream()
    .map(s -> s + "-" + s)                 //"c-c", "b-b", "a-a"
    .filter(s -> !s.equals("b-b"))         //"c-c", "a-a"
    .map(s -> s.substring(2))              //"c", "a"
    .collect(toList());

正如我们所料，输出为[c，a]。 现在让我们在一组而不是一个列表上运行流：

List<String> list = Arrays.asList("c", "b", "a");
Set<String> set = new HashSet<>(list);
List<String> modified = set.parallelStream()
    .map(s -> s + "-" + s)
    .filter(s -> !s.equals("b-b"))
    .map(s -> s.substring(2))
    .collect(toList());

这次，结果是[a，c]。 管道操作 （映射，过滤器，映射）没有改变顺序，但由于集合中元素的遭遇顺序未定义，结果以某种顺序结束在目标列表中，该顺序恰好与先前结果不同。

（我不得不改变原始列表中值的顺序，因为碰巧HashSet的迭代顺序与元素的哈希码有关，这里给出的简单字符串示例都有连续的哈希码。）

还有另一种可能考虑的“排序”，即不同元素之间的管道操作的相对执行顺序。 对于并行流，这是完全不确定的。 观察这种情况的一种方法是在管道操作中改变对象。 （为了安全地做到这一点，被突变的对象当然必须是线程安全的，依赖于任何这样的副作用的排序是不明智的。）这是一个例子：

List<Integer> list1 = Collections.synchronizedList(new ArrayList<>());
List<Integer> list2 =
    IntStream.range(0, 10)
        .parallel()
        .boxed()
        .peek(i -> list1.add(i))
        .collect(toList());
System.out.println(list1);
System.out.println(list2);

在我的系统上，输出是：

[5, 6, 2, 3, 4, 8, 9, 7, 0, 1]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

源的遭遇顺序保留在list2的输出中，但list1的顺序通常是不同的。 实际上， list1元素的排序因运行而异，而list2中元素的顺序始终相同。

总之，这里显示了三种不同的排序：

• 某些特定元素的管道操作顺序;
• 流的遭遇顺序，和
• 不同元素上管道操作的执行顺序。

他们都是截然不同的。

Answer 2

您的问题出现了，因为您正在从一种类型映射到同一类型。 如果您考虑正在执行的正式操作，很明显无法更改指定操作的顺序：

• 您将Stream<A>项目映射到任意类型B从而创建Stream<B>
• 在第一个映射的结果上应用Filter<B>
• 将过滤后的Stream<B>映射到任意类型C创建Stream<C>
• 您将类型C的项目收集到List<C>

查看这些正式步骤，应该清楚的是，由于类型兼容性要求，无法更改这些步骤的顺序。

事实上，在您的特殊情况下，所有三种类型都恰好是String并不会改变Stream的工作原理。 请记住，用于类型参数的实际类型将被删除，并且在运行时不存在。

Stream实现可以强制执行有用的操作，例如，一次执行sorted和distinct ，但这要求在相同的项目和Comparator上请求两个操作。 或者简单地说，内部优化不得改变所请求操作的语义。