Stream.reduce总是保持平行无序流的顺序

Question

我已经讨论了前面的几个问题，比如java stream中的遭遇顺序保存、Brian Goetz的回答，以及javadoc for stream。reduce（）和java。util。流包javadoc，但我仍然无法理解以下内容：

以这段代码为例：

  public static void main(String... args) {
    final String[] alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".split("");
    System.out.println("Alphabet: ".concat(Arrays.toString(alphabet)));
    System.out.println(new HashSet<>(Arrays.asList(alphabet))
          .parallelStream()
          .unordered()
          .peek(System.out::println)
          .reduce("", (a,b) -> a + b, (a,b) -> a + b));
  }

为什么减少总是保持遭遇顺序？

• 到目前为止，经过几十次运行，产量是相同的

Answer 1

TLDR:。reduce（）并不总是保持顺序，它的结果基于流拆分器的特性。

分离器

流的相遇顺序取决于流拆分器（前面提到的答案都没有）。

基于源流有不同的分裂器。您可以从这些集合的源代码中获得分裂器的类型。

HashSet-

ArrayDeque命令

ArrayList=有序

树集-

logicbig.com-订购logicbig.com-有状态vs无状态

此外，您可以应用. unorder（）中间流操作，该操作指定流中的以下操作不应依赖于排序。

受拆分器和使用影响的流操作（大部分是有状态的）。unordered（）方法包括：

• 。findFirst（）
• 。限制（）
• 。跳过（）
• 。独特的

这些操作将根据流及其拆分器的顺序属性给出不同的结果。

。peek（）方法不考虑排序，如果流并行执行，它将始终以无序方式打印/接收元素。

.减少（）

现在是终端。reduce（）方法。中间操作。unordered（）对拆分器的类型没有任何影响（正如@Eugene提到的）。但需要注意的是，它仍然和源拆分器中的一样。如果订购了源拆分器，则返回结果。如果源是的无序结果，则reduce（）将被排序。reduce（）将是无序的。

您正在使用新的HashSet

哈希集。reduce（）-无序

"A","B","C","D","E","F" -> "ABCDEF"
"a","b","c","1","2","3","A","B","C" -> "a1Ab2Bc3C"
"Apple","Orange","Banana","Mango" -> "AppleMangoOrangeBanana"

TreeSet。reduce（）-已排序

"A","B","C","D","E","F" -> "ABCDEF"
"a","b","c","1","2","3","A","B","C" -> "123ABCabc"
"Apple","Orange","Banana","Mango" -> "AppleBananaMangoOrange"

减少排序

"A","B","C","D","E","F" -> "ABCDEF"
"a","b","c","1","2","3","A","B","C" -> "abc123ABC"
"Apple","Orange","Banana","Mango" -> "AppleOrangeBananaMango"

您可以看到测试。reduce（）仅对字母表源流进行操作可能会导致错误结论。

答案是。reduce（）并不总是保持顺序，它的结果基于流拆分器的特性。

Answer 2

为了帮助解释这一点，我将把这个字符串的范围缩小到ABCD。

并行流会把字符串分成两部分：AB和CD，当我们后面去组合这些的时候，AB端的结果会是传入函数的第一个参数，而CD端的结果会是传入函数的第二个参数，这是不管这两者到底哪个先完成的。

无序运算符会影响流上的一些操作，比如一个限制操作，它不影响一个简单的减少。

Answer 3

首先，unordered并不意味着真正的洗牌；它所做的一切都为流管道设置了一个标志——以后可以利用这个标志。

源元素的洗牌可能比流管道上的操作本身更昂贵，因此实现可能选择不这样做（就像在本例中一样）。

目前（测试和查看源代码）的jdk-8和jdk-9-减少没有考虑到这一点。请注意，这在未来的构建或发布中很可能会改变。

另外，当你说unordered——你实际上是说你不关心这个顺序，返回相同结果的流并不违反这个规则。

例如，请注意这个问题/答案，它解释了findFirst例如（只是另一个终端操作）改变为在java-9中考虑无序，而不是java-8。