Java Fork/Join与多核世界中的多线程

Question

无法理解为什么Fork-Join在多核利用方面更好。

举例说明（仅为理论）：

我有一个Web服务endpoint数组：[E1、E2、E3、E4]

假设每个endpoint都返回一个数字。

然后我必须总结总数并返回结果。

记住这个简单的故事。

我有两个选择：

1. ExecutorService修复了4个线程池，并并行跨越这4个调用

假设我有4个核。

有了Executor service，就可以创建4个JVM线程，而且完全由操作系统在同一个核心或多个核心上调度它们。

如果它们安排在同一个核心上，那么我们就存在核心利用不足的问题。

如果他们被安排在不同的核心上，那么我们笑了！

我想知道的是，在使用多核时会出现一些不确定性。

Fork Join是如何解决这个问题的？它是否会在内部向操作系统传递某种神奇的指令以使用多核？

如果我上面的例子与Fork-Join和Executors之间的比较无关，那么Fork-Join如何声称它比传统的多线程更有效地利用内核呢。

Answer 1

Fork/join是更高级别的抽象。通常，如果您使用更高级别的库来解决问题，那么您将使用更少的新代码行来解决问题。这总是一件好事。

不过，高级通常意味着更专业。分叉/连接可能适合也可能不适合你的问题。如果它不合适，那么你可能会浪费很多精力，试图让它合适会弄得一团糟。

如果它确实合适，而你不使用它，那么很可能你会重新发明一些轮子。这从来不是一件好事。

Answer 2

只有当任务可以递归地细分为较小的任务时，Fork/Join才比简单的ExecutorSavice更快。在这种情况下，Fork/Join可以使用工作窃取来确保所有CPU都得到最佳使用。

在你的情况下，它并没有更快。

编辑：除了窃取工作外，任务的调度也可以更快。正如维基百科所说：

分叉连接编程中使用的轻量级线程通常会有自己的调度程序（通常是窃取工作的调度程序），将它们映射到底层线程池。这个调度程序可能比功能齐全的抢占式操作系统调度程序简单得多：通用线程调度程序必须处理锁的阻塞，但在分叉连接范式中，线程仅在连接点阻塞。