并行流是否能在不同的操作下工作得很好？

Question

我在读关于无国籍状态的文章时，在Doc中看到了这句话：

如果流操作的行为参数是有状态的，则流管道结果可能是不确定的或不正确的。有状态的lambda（或实现适当功能接口的其他对象）的结果取决于流管道执行过程中可能改变的任何状态。

现在，如果我有一个字符串列表(strlist)，然后尝试使用并行流以以下方式从其中删除重复的字符串：

List<String> resultOne = strList.parallelStream().distinct().collect(Collectors.toList());

List<String> result2 = strList.parallelStream().map(String::toLowerCase)
                       .distinct().collect(Collectors.toList());

这段代码是否有问题，因为并行流会分割输入，并且在一个块中的distinct不一定意味着在整个输入中的distinct？

distince是一个有状态操作，在有状态中间操作的情况下，并行流可能需要多次传递或大量缓冲开销。此外，如果元素的排序不相关，则distinct可以更有效地实现。根据单据：

对于有序流，不同元素的选择是稳定的（对于重复的元素，在遇到顺序中首先出现的元素被保留。）对于无序流，不作稳定性保证。

但是，在有序流并行运行的情况下，distinct可能是不稳定的--意味着在重复的情况下，它将保留一个任意的元素，而不一定像distinct所期望的那样保留第一个元素。

从链接：

在内部，distinct（）操作保留了一个包含前面已经看到的元素的集合，但它隐藏在操作内部，我们无法从应用程序代码中获取它。

因此，在并行流的情况下，它可能会消耗整个流或使用CHM（类似于concurrenthashMap.newkeyset())。对于有序的，很可能使用linkedhashset或类似的结构。

Answer 1

粗略指出doc的相关部分（重点，我的）：

中间操作进一步分为无状态和有状态操作。无状态操作（如filter和map）在处理新元素时不会保留以前看到的元素的状态--每个元素都可以独立于对其他元素的操作进行处理。当处理新元素时，诸如distinct和sorted的有状态操作可以合并来自先前看到的元素的状态

有状态操作可能需要在生成结果之前处理整个输入。例如，在看到流的所有元素之前，无法从对流的排序中产生任何结果。因此，在并行计算下，一些包含有状态中间操作的流水线可能需要对数据进行多次传递，或者可能需要缓冲重要的数据。包含排他性无状态中间操作的管道可以在一次传递中处理，不管是顺序操作还是并行操作，只需最少的数据缓冲

...

对于并行流，放松排序约束有时可以实现更高效的执行。如果元素的排序不相关，则可以更有效地实现某些聚合操作，例如筛选重复项（distinct（））或分组约简（Collectors.GroupingBy（））。类似地，在本质上绑定到遇到顺序的操作（如limit（））可能需要缓冲以确保正确的顺序，从而破坏了并行性的好处。在流有遇到顺序但用户并不特别关心遇到顺序的情况下，使用unordered（）显式地解除流的顺序可能会提高某些状态操作或终端操作的并行性能。然而，大多数流管道，例如上面的“块权重之和”示例，即使在排序约束下仍然高效地并行化。

最后,

null

List<String> result2 = strList.parallelStream()
                              .unordered()
                              .map(String::toLowerCase)
                              .distinct()
                              .collect(Collectors.toList());

可惜Java中没有（可用的内置）并发哈希集（除非他们通过concurrenthashmap变得聪明），所以我只能给您留下一个不幸的可能性，即distinct是使用常规Java集以阻塞方式实现的。在这种情况下，我看不出做一个并行的distinct有什么好处。

编辑：我说得太早了。使用带有distinct的并行流可能会有一些好处。看起来distince的实现比我最初想象的更巧妙。参见@尤金的回答。