非递归任务的Java ForkJoinPool，偷工减料行得通吗？

Question

我想通过以下方法将＜code＞Runnable＜code＞任务提交到ForkJoinPool：

forkJoinPool.submit(Runnable task)

注意，我使用JDK 7。

在引擎盖下，它们被转换为ForkJoinTask对象。我知道ForkJoinPool在任务递归地分成较小的任务时是有效的。

问题:

如果没有递归，工作窃取在ForkJoinPool中仍然有效吗？

在这种情况下值得吗？

更新1:任务小，可以不平衡。即使对于严格相等的任务，如上下文切换、线程调度、暂停、页面丢失等。成为导致不平衡的障碍。

更新2：Doug Lea在并发JSR-166兴趣小组中写道，对此给出了提示：

当所有任务都是异步的并提交到池而不是分叉时，这也大大提高了吞吐量，这成为构建执行组件框架以及许多可能使用ThreadPoolExecutor的普通服务的合理方法。

我认为，当涉及到相当小的CPU密集型任务时，ForkJoinPool是要走的路，这要归功于这种优化。重点是这些任务已经很小，不需要递归分解。偷工是有效的，不管是大任务还是小任务——任务可以被另一个自由工人从繁忙工人的Deque尾巴上抓取。

更新3：ForkJoinPool的可扩展性-乒乓球Akka团队的基准测试显示了巨大的结果。

尽管如此，要更有效地应用ForkJoinPool，需要进行性能调优。

Answer 1

ForkJoinpool源代码有一个很好的部分，称为“实现概述”，阅读以获得终极真理。下面的解释是我对JDK 8u40的理解。

从第一天起，< code>ForkJoinPool就为每个工作线程准备了一个工作队列(让我们称之为“工作队列”)。分叉的任务被推入本地工作队列，准备好被工作线程再次弹出并执行——换句话说，从工作线程的角度看，它就像一个堆栈。当一个工作者耗尽它的工作者队列时，它会四处寻找并试图从其他工作者队列中窃取任务。那就是“偷工减料”。

现在，在（IIRC）JDK 7u12之前，ForkJoinPool有一个单一的全局提交队列。当工作线程用完本地任务以及要窃取的任务时，它们会到达那里并尝试查看外部工作是否可用。在这种设计中，与常规的＜code＞ThreadPoolExecutor

在那之后，它发生了重大变化。在这个提交队列被确定为严重的性能瓶颈后，Doug Lea等人。也对提交队列进行了条带化。事后看来，这是一个显而易见的想法：您可以重用大多数可用于工作队列的机制。您甚至可以松散地将这些提交队列分配给每个工作线程。现在，外部提交进入其中一个提交队列。然后，没有工作可供咀嚼的工作人员可以首先查看与特定工作人员相关的提交队列，然后四处走动查看其他人的提交队列。人们也可以称之为“工作窃取”。

我已经看到许多工作负载从中受益。即使对于普通的非递归任务，ForkJoinPool的这种特殊设计优势在很久以前就被认识到了。conmonce-interest@的许多用户要求一个没有所有ForkJoinpool奥秘的简单工作窃取执行程序。这就是为什么我们在JDK 8中有Executors.newWorkStealingPool（）的原因之一——目前委托给ForkJoinpool，但为了提供更简单的实现而开放。