线程池和 Fork/Join 的最终目标是相似的: 两者都希望最大限度地利用可用的 CPU 能量以实现最大吞吐量。最大吞吐量意味着应该在较长的时间内完成尽可能多的任务。要做到这一点需要什么？(对于下面的内容，我们假设并不缺少计算任务: 总是有足够的事情可以做，以达到100% 的 CPU 利用率。另外，在超线程的情况下，我使用“ CPU”等效于内核或虚拟内核)。

1. 至少需要有尽可能多的线程在运行，因为运行较少的线程会使核心不能使用。
2. 在最大限度上，运行的线程数量必须和可用 CPU 数量一样多，因为运行更多的线程会给调度程序带来额外的负载，调度程序会将 CPU 分配给不同的线程，这会导致一些 CPU 时间流向调度程序，而不是我们的计算任务。

因此，我们发现，为了获得最大的吞吐量，我们需要拥有与 CPU 完全相同的线程数量。在 Oracle 的模糊示例中，您可以选择一个固定大小的线程池，其线程数量等于可用 CPU 的数量，也可以使用一个线程池。没用的，你说得对！

那么线程池什么时候会出问题呢？也就是说，如果一个线程阻塞 ，因为您的线程正在等待另一个任务完成。假设以下例子:

class AbcAlgorithm implements Runnable {
public void run() {
Future<StepAResult> aFuture = threadPool.submit(new ATask());
StepBResult bResult = stepB();
StepAResult aResult = aFuture.get();
stepC(aResult, bResult);
}
}

我们在这里看到的是一个由三个步骤 A、 B 和 C 组成的算法。A 和 B 可以彼此独立执行，但是步骤 C 需要步骤 A 和 B 的结果。这个算法所做的是将任务 A 提交到线程池并直接执行任务 b。之后，线程将等待任务 A 完成，并继续执行步骤 C。如果 A 和 B 是同时完成的，那么一切都很好。但如果 A 花的时间比 B 长呢？这可能是因为任务 A 的性质决定了它，但也可能是因为没有 任务 A 的线程在开始时可用，任务 A 需要等待。(如果只有一个 CPU 可用，因此线程池只有一个线程，这甚至会导致死锁，但目前这还不是重点)。重点是刚刚执行任务 B 阻碍了整个线程的线程。因为我们有相同数量的线程作为 CPU 和一个线程被阻塞，这意味着 一个 CPU 空闲。

Fork/Join 解决了这个问题: 在 Fork/Join 框架中，你可以编写如下相同的算法:

class AbcAlgorithm implements Runnable {
public void run() {
ATask aTask = new ATask());
aTask.fork();
StepBResult bResult = stepB();
StepAResult aResult = aTask.join();
stepC(aResult, bResult);
}
}

看起来一样，不是吗？然而线索是 aTask.join 不会阻止。相反，这里是 偷工作发挥作用的地方: 该线程将寻找过去分叉的其他任务，并将继续这些任务。首先，它检查自己分叉的任务是否已经开始处理。因此，如果 A 还没有被另一个线程启动，它将接着执行 A，否则它将检查其他线程的队列并窃取它们的工作。一旦另一个线程的另一个任务完成，它将检查 A 现在是否已经完成。如果是上面的算法可以调用 stepC。否则，它将寻找另一个任务来窃取。这就是 Fork/join 池可以实现100% 的 CPU 利用率，即使在遇到阻塞操作时也是如此。

然而，这里有一个陷阱: 工作盗窃只有在 ForkJoinTask的 join呼叫时才可能发生。不能对外部阻塞操作(如等待另一个线程或等待 I/O 操作)执行此操作。那么，等待 I/O 完成是一个常见的任务，这又是怎么回事呢？在这种情况下，如果我们可以添加一个额外的线程到 Fork/Join 池，它将在阻塞操作完成后立即停止，这将是第二个最好的选择。如果我们使用 ManagedBlocker，ForkJoinPool实际上可以做到这一点。

斐波那契数

在 用于递归任务的 JavaDoc中有一个使用 Fork/Join 计算斐波那契数的例子:

public static int fib(int n) {
if (n <= 1) {
return n;
}
return fib(n - 1) + fib(n - 2);
}

正如在 JavaDocs 中解释的那样，这是计算 fibonacci 数的一种相当垃圾的方法，因为这种算法具有 O (2 ^ n)的复杂性，而简单的方法是可能的。然而，这个算法非常简单，容易理解，所以我们坚持使用它。假设我们希望使用 Fork/Join 来加快速度。一个幼稚的实现应该是这样的:

class Fibonacci extends RecursiveTask<Long> {
private final long n;


Fibonacci(long n) {
this.n = n;
}


public Long compute() {
if (n <= 1) {
return n;
}
Fibonacci f1 = new Fibonacci(n - 1);
f1.fork();
Fibonacci f2 = new Fibonacci(n - 2);
return f2.compute() + f1.join();
}
}

Task 分解的步骤太短了，因此执行起来会很糟糕，但是您可以看到框架通常是如何工作得非常好的: 两个汇总可以单独计算，但是我们需要两个汇总来构建最终结果。所以一半是在另一个线程中完成的。对线程池进行同样的操作，而不会出现死锁(可能，但远没有那么简单)。

为了完整起见: 如果你真的想用这种递归方法计算斐波那契数，这里有一个优化版本:

class FibonacciBigSubtasks extends RecursiveTask<Long> {
private final long n;


FibonacciBigSubtasks(long n) {
this.n = n;
}


public Long compute() {
return fib(n);
}


private long fib(long n) {
if (n <= 1) {
return 1;
}
if (n > 10 && getSurplusQueuedTaskCount() < 2) {
final FibonacciBigSubtasks f1 = new FibonacciBigSubtasks(n - 1);
final FibonacciBigSubtasks f2 = new FibonacciBigSubtasks(n - 2);
f1.fork();
return f2.compute() + f1.join();
} else {
return fib(n - 1) + fib(n - 2);
}
}
}

这使得子任务变得更小，因为它们只有在 n > 10 && getSurplusQueuedTaskCount() < 2为 true 时才会被拆分，这意味着有100多个方法调用要做(n > 10) ，并且没有非常多的 man 任务已经在等待(getSurplusQueuedTaskCount() < 2)。

在我的计算机上(4核(计算超线程时为8核) ，Intel (R) Core (TM) i7-2720QM CPU@2.20 GHz) ，使用传统方法需要64秒，使用 Fork/Join 方法只需要18秒，这是一个相当明显的增益，尽管在理论上可能性不大。

摘要

• 是的，在您的示例中，Fork/Join 与传统的线程池相比没有优势。
• 当涉及到阻塞时，Fork/Join 可以极大地提高性能
• Fork/Join 避免了一些死锁问题

我想为那些没有太多时间阅读长答案的人补充一个简短的答案。这个比较来自《应用阿卡模式:

您决定是使用 fork-join-execute 还是使用 线程池执行器在很大程度上取决于 这个调度程序将被阻塞 活动线程的最大数量，而线程池执行器给出 一个固定数量的线程。如果线程被阻塞，则 Fork-join-Execator 将创建更多内容，而线程池执行器将创建更多内容 对于阻塞操作，通常最好使用 线程池执行器，因为它防止您的线程计数从 爆炸。更多的“反应性”操作在一个 叉连接执行器叉连接执行器。