为什么parallelStream 使用的是ForkJoinPool，而不是普通的线程池？

Question

参考Java 的 Fork/Join vs ExecutorService - 何时使用哪个？，一个传统的线程池通常用于处理很多独立的请求；和 aForkJoinPool用于处理连贯/递归任务，其中一个任务可能会产生另一个子任务并稍后加入。

那么，为什么默认parallelStream使用Java-8ForkJoinPool而不是传统的执行器呢？

在很多情况下，我们forEach()在stream()orparallelStream()之后使用，然后提交一个功能接口作为参数。在我看来，这些任务是独立的，不是吗？

Answer 1

一件重要的事情是 a也ForkJoinPool可以执行“正常”任务（例如Runnable，Callable），因此它不仅仅适用于递归创建的任务。

另一件事（重要的）是它ForkJoinPool有多个队列，每个工作线程一个，用于任务，而普通执行器（例如ThreadPoolExecutor）只有一个。这对他们应该运行什么类型的任务有很大影响。

普通执行器必须执行的任务越小、越多，将任务分配给工作人员的同步开销就越高。如果大多数任务都很小，那么工作人员将经常访问内部任务队列，这会导致同步开销。

这就是ForkJoinPool它的多个队列的闪光之处。每个worker只是从自己的队列中获取任务，大多数时候不需要通过阻塞来同步，如果它是空的，它可以从另一个worker那里窃取任务，但是从队列的另一端，这也很少会导致同步开销，因为工作窃取应该相当罕见。

现在这与并行流有什么关系？流框架被设计为易于使用。当您想要轻松地将某些内容拆分为许多并发任务时，应该使用并行流，其中所有任务都相当小且简单。这就是要点ForkJoinPool这就是合理选择的它可以在处理大量较小的任务时提供更好的性能，并且如果需要的话，它也可以处理较长的任务。