并行平面映射总是顺序的

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属性如果“outer”流将是并行的（它们可能会阻塞），“outer”将不得不等待“flatmap”完成，反过来（因为使用了相同的公共池），但为什么总是强制这样做呢？

这是一个可以在以后的版本中改变的东西吗？

Answer 1

有两个不同的方面。

首先，只有一个流水线，它要么是顺序的，要么是并行的。在内部流处选择顺序或并行是无关紧要的。请注意，您在引用的代码段中看到的downdown使用者代表整个后续流管道，因此在代码中，以.collectors.toset())；结尾，这个使用者最终将把结果元素添加到一个不是线程安全的set实例中。因此与单个使用者并行处理内部流将中断整个操作。

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

实现的方式也是为什么flatMap（）之后的filter（）在Java流中“不完全”懒惰的原因？发出，因为在内部流上调用foreach，该内部流将把所有元素传递给下游使用者。如这个答案所示，支持懒惰和子流拆分的替代实现是可能的。但这是一种根本不同的实现方式。流实现的当前设计主要是通过使用者组合来工作的，因此最终，源拆分器（以及从源拆分器拆出的那些）接收一个consumer，它以TryAdvance或ForeachReflay的形式表示整个流管道。相反，链接答案的解决方案会拆分器组合，生成一个新的spliterator委托给源拆分器。我想，这两种方法都有优点，但我不确定OpenJDK实现在反过来工作时会损失多少。