Akka 如何从 ForkJoinPool 中受益？

Question

Akka docs声明默认调度程序是 a，fork-join-executor因为它“在大多数情况下提供出色的性能”。我想知道为什么会这样？来自ForkJoinPoolForkJoinPool 与其他类型的 ExecutorService 的主要区别在于采用了工作窃取：池中的所有线程尝试查找并执行提交给池和/或由其他活动任务创建的任务（如果不存在，则最终阻塞等待工作） . 这使得(1) 当大多数任务产生其他子任务时（如大多数 ForkJoinTasks）以及(2) 当许多小任务从外部客户端提交到池时有效处理。特别是在构造函数中将 asyncMode 设置为 true 时，ForkJoinPools 也可能(3) 适用于从未加入的事件样式任务。起初，我猜 Akka 不是情况 (1) 的一个例子，因为我无法弄清楚 Akka 如何分叉任务，我的意思是，可以在许多任务中分叉的任务是什么？我将每条消息视为一个独立的任务，这就是为什么我认为 Akka 类似于案例 (2)，其中消息是许多小任务（通过 ! 和 ?）提交到ForkJoinPool.下一个问题，虽然与 akka 没有严格关系，但为什么不使用 fork 和 join（ForkJoinPool允许工作窃取的主要功能）的用例仍然可以通过 ForkJoinPool 受益？来自Fork Join Pool 的可扩展性我们注意到上下文切换次数异常，每秒超过70000次。那一定是问题所在，但是是什么原因造成的呢？Viktor 提出了一个合格的猜测，即它必须是线程池执行器的任务队列，因为它是共享的，并且 LinkedBlockingQueue 中的锁可能会在发生争用时生成上下文切换。但是，如果 Akka 确实没有使用ForkJoinTasks，那么所有外部客户端提交的任务都会在共享队列中排队，因此争用应该与 中相同ThreadPoolExecutor。所以，我的问题是：Akka 使用ForkJoinTasks(case (1)) 还是与 case (2) 有关？ForkJoinPool如果外部客户端提交的所有任务都将被推送到共享队列并且不会发生工作窃取，那么为什么在情况（2）中是有益的？“具有从未加入的事件式任务”（案例 3）的示例是什么？