ForkJoinPool源代码有一个不错的部分，称为“实施概述”，请阅读以获取最终真相。以下说明是我对JDK 8u40的理解。
从第一天开始，
ForkJoinPool每个工作线程都有一个工作队列（我们称它们为“工作队列”）。分叉的任务被推入本地工作线程队列，准备再次由工作线程弹出并执行-
换句话说，从工作线程角度看，它看起来像是一个堆栈。当工作人员耗尽其工作人员队列时，它将四处走动，并尝试从其他工作人员队列中窃取任务。那就是 “偷工作”
。
现在，在（IIRC）JDK 7u12之前，
ForkJoinPool只有一个全局 提交队列
。当工作线程用尽本地任务以及要偷的任务时，他们到达那里并尝试查看是否有外部工作可用。在这个设计中，有对有规律的，比如，没有优势
ThreadPoolExecutor的支持
ArrayBlockingQueue。
此后发生了很大变化。在确定此提交队列是严重的性能瓶颈之后，Doug
Lea等人。划分提交队列。事后看来，这是一个显而易见的主意：您可以重用大多数可用于工作队列的机制。您甚至可以为每个工作线程松散地分配这些提交队列。现在，外部提交进入提交队列之一。然后，没有工作需要上班的工作人员可以先查看与特定工作人员相关联的提交队列，然后四处逛逛以查看其他人的提交队列。人们也可以称其
为 “偷工作”。
我已经看到许多工作负载从中受益。
ForkJoinPool甚至对于普通的非递归任务而言，这种特殊的设计优势早已为人所认识。许多在concurrency-
interest
@上的用户要求一个简单的，可以偷工减料的执行
ForkJoinPool器。这就是为什么我们
Executors.newWorkStealingPool()要从JDK
8开始的原因之一-当前委托给
ForkJoinPool，但是愿意提供更简单的实现。
