ThreadPoolExecutor与ForkJoinPool：窃取子任务

Question

从java文档，

ForkJoinPool不同于其他类型的ExecutorService，主要是因为它采用了工作窃取：池中的所有线程都试图查找并执行其他活动任务创建的子任务（如果不存在，则最终阻塞等待工作）。

当大多数任务产生其他子任务时（就像大多数ForkJoinTasks一样），这可以实现高效处理。当在构造函数中将asyncMode设置为true时，ForkJoinPools也可能适合用于从未加入的事件样式任务。

在阅读了下面的ForkJoinPool示例之后，和ThreadPoolExecutor不同，我并没有看到设置队列大小的参数。我不知道ForkJoinPool是如何偷窃的。

//creating the ThreadPoolExecutor

ThreadPoolExecutor executorPool = new ThreadPoolExecutor(2, 10, 60, TimeUnit.SECONDS, 
new ArrayBlockingQueue<Runnable>(3000), threadFactory, rejectionHandler);

假设我创建了ThreadPoolExecutor，其中包含10个线程，并提交了3000个可调用任务。这些线程如何共享子任务的执行负载？

对于相同的用例，ForkJoin池的行为如何不同？

Answer 1

在ForkJoinPool中，有两种队列—一种是提交任务时基本使用的队列，另一种是特定于线程的队列（即每个线程一个）。从ForkJoinTask中，您可以调用新任务（通常是问题的一部分）。

这些新任务不是提供给池队列，而是提供给特定于线程的队列。因此，它们优先于池1，就像您在同一个任务中完成了所有工作一样。此外，调用器任务似乎被阻止以完成子任务。

实际上，“阻塞时间”用于消耗子任务。当其中一个线程被工作淹没时，让其他线程“游手好闲”将是愚蠢的。所以，“偷工减料”就发生了。

超越。为了提高效率，“偷工减料”将任务从相反的界限中抽取。这大大减少了队列写入的争用。

总是在效率上，最好只将问题拆分为两个子任务，让子任务一次又一次地拆分。即使您知道问题也必须直接拆分为N部分。这是因为“工作窃取”需要并发写入共享资源，因此限制其激活和争用！

Answer 2

如果您预先有3000个任务，并且它们不会产生其他任务，那么两者的行为不会有很大不同：对于10个线程，一次将运行10个任务，直到它们全部完成。

ForkJoinPool设计用于一个或几个任务开始，但这些任务知道如何将自己拆分为子任务的情况。在这种情况下，ForkJoinPool进行了优化，以允许任务检查处理线程的可用性，并适当地将其拆分。