在考虑将外部流并行化之前，内部并行流会被完全并行处理吗？

Question

从这个链接中，我只部分了解到，至少在某一点上，java嵌套并行流存在问题。然而，我无法推导出以下问题的答案：

Java会先并行执行内部流，然后处理外部流吗？如果是，它是在编译时还是在运行时做出这个决定？如果在运行时，JIT是否足够聪明，能够意识到如果内部流中的元素（例如数百个）比核数（32个）多得多，那么它肯定应该使用所有32个核来处理内部流，然后再从外部流中移动下一个元素；但是，如果元素的数量很少（例如<32)，那么从“下一个”外部流的元素中“并行处理”元素也是可以的。

Answer 1

也许下面的示例程序可以说明这个问题：

java prettyprint-override">IntStream.range(0, 10).parallel().mapToObj(i -> "outer "+i)
         .map(outer -> outer+"\t"+IntStream.range(0, 10).parallel()
            .mapToObj(inner -> Thread.currentThread())
            .distinct() // using the identity of the threads
            .map(Thread::getName) // just to be paranoid, as names might not be unique
            .sorted()
            .collect(Collectors.toList()) )
         .collect(Collectors.toList())
         .forEach(System.out::println);

当然，结果会有所不同，但我机器上的输出看起来类似于这样：

outer 0 [ForkJoinPool.commonPool-worker-6]
outer 1 [ForkJoinPool.commonPool-worker-3]
outer 2 [ForkJoinPool.commonPool-worker-1]
outer 3 [ForkJoinPool.commonPool-worker-1, ForkJoinPool.commonPool-worker-4, ForkJoinPool.commonPool-worker-5]
outer 4 [ForkJoinPool.commonPool-worker-5]
outer 5 [ForkJoinPool.commonPool-worker-2, ForkJoinPool.commonPool-worker-4, ForkJoinPool.commonPool-worker-7, main]
outer 6 [main]
outer 7 [ForkJoinPool.commonPool-worker-4]
outer 8 [ForkJoinPool.commonPool-worker-2]
outer 9 [ForkJoinPool.commonPool-worker-7]

我们在这里看到的是，对于我的机器，有8个核心，7个工作线程正在为工作做出贡献，为了利用所有核心，对于公共池，调用线程也将为工作做出贡献，而不是仅仅等待完成。您可以在输出中清楚地看到main线程。

这种行为背后有一个简单的理由。当外流的处理开始时，它并不知道它将是一个“外流”。它只是一个并行流，除了处理它之外，没有办法知道这是否是一个外部流，直到其中一个函数启动另一个流操作。但是将并行处理推迟到这一点是没有意义的，因为这一点可能永远不会到来。

此外，我强烈反对你的假设，“如果内部流首先完全并行地完成，它的性能会更好[…]”。我更希望它反过来，阅读，期望一个优点，完全按照它已经实现，对于典型的用例。但是，正如上一段所解释的，没有合理的方法来实现并行处理内部流的偏好。