流操作应用于列表元素的顺序是什么？ [英] What is the order in which stream operations are applied to list elements?

问题描述

假设我们有一个标准的流操作方法链：

Suppose we have a standard method chain of stream operations:

Arrays.asList("a", "bc", "def").stream()
  .filter(e -> e.length() != 2)
  .map(e -> e.length())
  .forEach(e -> System.out.println(e));

JLS中是否有关于流操作应用于列表元素的顺序的保证？

Are there any guarantees in the JLS regarding the order in which stream operations are applied to the list elements?

例如，是否保证：

1. 将过滤谓词应用于在将过滤谓词应用于a？
$ b之前，不会发生bc $ b
2. 在将映射函数应用于adef $ c>？


3. 1 将在 3 之前打印？

1. Applying the filter predicate to "bc" is not going to happen before applying the filter predicate to "a"?
2. Applying the mapping function to "def" is not going to happen before applying the mapping function to "a"?
3. 1 will be printed before 3?

注意：我在这里特别谈论 stream（），不 parallelStream（）预计映射和过滤等操作将并行完成。

Note: I am talking here specifically about stream(), not parallelStream() where it is expected that operations like mapping and filtering are done in parallel.

推荐答案

您想知道的一切都可以在 java.util.stream JavaDoc 。

Everything you want to know can be found within the java.util.stream JavaDoc.

订购

流可能有也可能没有已定义的遭遇顺序。
a流是否有遭遇顺序取决于源和
中间操作。某些流源（例如List或
数组）本质上是有序的，而其他流（例如HashSet）
则不是。某些中间操作（例如sorted（））可能会在其他无序流上强制执行
遭遇订单，而其他可能
呈现无序的有序流，例如BaseStream.unordered（）。
此外，某些终端操作可能会忽略遭遇订单，例如
forEach（）。

Ordering

Streams may or may not have a defined encounter order. Whether or not a stream has an encounter order depends on the source and the intermediate operations. Certain stream sources (such as List or arrays) are intrinsically ordered, whereas others (such as HashSet) are not. Some intermediate operations, such as sorted(), may impose an encounter order on an otherwise unordered stream, and others may render an ordered stream unordered, such as BaseStream.unordered(). Further, some terminal operations may ignore encounter order, such as forEach().

如果订购了流，大多数操作受限于在
中操作其遭遇顺序中的元素; 如果流的源是包含[1,2,3]的
列表，则执行map的结果（x - > x * 2）
必须是[2,4,6]。但是，如果源没有定义遭遇
订单，那么值[2,4,6]的任何排列都将是有效的
结果。

If a stream is ordered, most operations are constrained to operate on the elements in their encounter order; if the source of a stream is a List containing [1, 2, 3], then the result of executing map(x -> x*2) must be [2, 4, 6]. However, if the source has no defined encounter order, then any permutation of the values [2, 4, 6] would be a valid result.

对于顺序流，遇到订单
的存在与否不会影响性能，只影响确定性。如果订购了一个流，
在相同的
源上重复执行相同的流管道将产生相同的结果;如果没有订购，
重复执行可能会产生不同的结果。

For sequential streams, the presence or absence of an encounter order does not affect performance, only determinism. If a stream is ordered, repeated execution of identical stream pipelines on an identical source will produce an identical result; if it is not ordered, repeated execution might produce different results.

对于并行流，放宽排序约束有时可以
实现更高效的执行。如果
元素的排序不相关，则可以更有效地实现某些聚合操作，例如
过滤重复项（distinct（））或分组减少
（Collectors.groupingBy（））。同样，
的操作本身与遇到订单相关联，例如limit（），可能需要
缓冲以确保正确排序，从而破坏
并行性的好处。如果流具有遭遇订单，但
用户并不特别关心该遭遇订单，则显式
使用无序（）对流进行解序可以提高某些并行
的性能有状态或终端操作。但是，大多数
流管道，例如上面的块的权重总和示例，
即使在订购约束下仍然可以高效并行化。

For parallel streams, relaxing the ordering constraint can sometimes enable more efficient execution. Certain aggregate operations, such as filtering duplicates (distinct()) or grouped reductions (Collectors.groupingBy()) can be implemented more efficiently if ordering of elements is not relevant. Similarly, operations that are intrinsically tied to encounter order, such as limit(), may require buffering to ensure proper ordering, undermining the benefit of parallelism. In cases where the stream has an encounter order, but the user does not particularly care about that encounter order, explicitly de-ordering the stream with unordered() may improve parallel performance for some stateful or terminal operations. However, most stream pipelines, such as the "sum of weight of blocks" example above, still parallelize efficiently even under ordering constraints.

这篇关于流操作应用于列表元素的顺序是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！