并行flatMap总是顺序的

Question

假设我有以下代码：

 Collections.singletonList(10)
            .parallelStream() // .stream() - nothing changes
            .flatMap(x -> Stream.iterate(0, i -> i + 1)
                    .limit(x)
                    .parallel()
                    .peek(m -> {
                        System.out.println(Thread.currentThread().getName());
                    }))
            .collect(Collectors.toSet());

输出是相同的线程名称，因此这里没有任何好处parallel-我的意思是，只有一个线程可以完成所有工作。

里面flatMap是这段代码：

result.sequential().forEach(downstream);

我知道sequential如果“外部”流是并行的（可能会阻塞），则强制该属性，“外部”将不得不等待“
flatMap”完成，反之亦然（因为使用了相同的公共池），但是为什么 总是 强迫那个？

那是在以后的版本中 可能会 更改的事情之一吗？

Answer 1

有两个不同方面。

首先，只有一个流水线是顺序的或并行的。在内流处选择顺序还是并行无关紧要。请注意，downstream您在引用的代码片段中看到的使用者代表整个后续流管道，因此在您的代码中（以结尾）.collect(Collectors.toSet());，该使用者最终会将结果元素添加到Set不是线程安全的单个实例中。因此，与单个使用者并行处理内部流将破坏整个操作。

如果外部流被拆分，则引用的代码可能会与添加到不同集合的不同使用者同时调用。这些调用中的每个调用都会处理外部流的不同元素，以映射到不同的内部流实例。由于您的外部流仅包含一个元素，因此无法拆分。

这已经实现了，这也是为什么flatMap（）之后的filter（）在Java流中“不完全”惰性的原因？问题，如forEach内部流所称，它将把所有元素传递给下游使用者。如该答案所示，支持懒惰和子流拆分的替代实现是可能的。但这是实现它的根本不同的方法。Stream实现的当前设计主要根据使用者组成来工作，因此最后，源拆分器（以及从中拆分的源拆分器）Consumer在tryAdvance或中接收代表整个流管道的forEachRemaining。相比之下，链接答案的解决方案确实进行了分隔器组合，从而产生了新的Spliterator委托给源分割器。我以为，这两种方法都有优势，而且我不确定在相反方向工作时OpenJDK实现会损失多少。