java - Akka 如何从 ForkJoinPool 中获益？

Question

Akka docs声明默认调度程序是一个 fork-join-executor，因为它“在大多数情况下提供出色的性能”。
我想知道这是为什么？

来自 ForkJoinPool

A ForkJoinPool differs from other kinds of ExecutorService mainly by virtue of employing work-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist). This enables (1) efficient processing when most tasks spawn other subtasks (as do most ForkJoinTasks), as well as (2) when many small tasks are submitted to the pool from external clients. Especially when setting asyncMode to true in constructors, ForkJoinPools may also be (3) appropriate for use with event-style tasks that are never joined.

起初，我猜想 Akka 不是情况 (1) 的示例，因为我无法弄清楚 Akka 是如何 fork 任务的，我的意思是，在许多任务中可以 fork 的任务是什么？
我将每条消息视为一个独立的任务，这就是为什么我认为 Akka 类似于情况 (2)，其中消息是许多小任务(通过 ! 和 ?)提交到 ForkJoinPool。

下一个问题虽然与 akka 不严格相关，但为什么没有使用 fork 和 join(ForkJoinPool 的主要功能，允许工作窃取)的用例仍然可以从 ForkJoinPool 中受益吗？
来自 Scalability of Fork Join Pool

We noticed that the number of context switches was abnormal, above 70000 per second.
That must be the problem, but what is causing it? Viktor came up with the qualified guess that it must be the task queue of the thread pool executor, since that is shared and the locks in the LinkedBlockingQueue could potentially generate the context switches when there is contention.

但是，如果Akka确实没有使用ForkJoinTasks，那么外部客户端提交的所有任务都会在共享队列中排队，所以竞争应该和中的一样线程池执行器.

所以，我的问题是:

1. Akka 使用 ForkJoinTasks(案例 (1))或与案例 (2) 相关？
2. 如果外部客户端提交的所有任务都将被推送到共享队列并且不会发生工作窃取，为什么 ForkJoinPool 在情况 (2) 中是有益的？
3. “具有从未加入的事件式任务”(案例 3)的示例是什么？

---

更新

正确答案来自 johanandren，但我想添加一些亮点。

• Akka 不使用 fork 和 join 功能，因为 AFAIK 与 Actor 模型，或者至少我们如何实现它，没有真正的用例(来自 johanandren 的评论)。< br/> 所以我对 Akka 不是案例 (1) 的实例的理解是正确的。
• 在我原来的回答中我说所有外部客户端提交的任务都会在共享队列中排队。
  这是正确的，但仅适用于 FJP 的先前版本 (jdk7)。 在jdk8中single submission queue被许多“提交队列”所取代。 This answer很好地解释了这一点:

  Now, before (IIRC) JDK 7u12, ForkJoinPool had a single global submission queue. When worker threads ran out of local tasks, as well the tasks to steal, they got there and tried to see if external work is available. In this design, there is no advantage against a regular, say, ThreadPoolExecutor backed by ArrayBlockingQueue. [...]
  Now, the external submission goes into one of the submission queues. Then, workers that have no work to munch on, can first look into the submission queue associated with a particular worker, and then wander around looking into the submission queues of others. One can call that "work stealing" too.

因此，这可以在未使用 fork join 的情况下实现工作窃取。作为Doug Lea says

Substantially better throughput when lots of clients submit lots of tasks. (I've measured up to 60X speedups on micro-benchmarks). The idea is to treat external submitters in a similar way as workers -- using randomized queuing and stealing. (This required a big internal refactoring to disassociate work queues and workers.) This also greatly improves throughput when all tasks are async and submitted to the pool rather than forked, which becomes a reasonable way to structure actor frameworks, as well as many plain services that you might otherwise use ThreadPoolExecutor for.

• 关于 FJP 的另一个值得一提的奇点来自 this comment

  4% is indeed not much for FJP. There's still a trade-off you do with FJP which you need to be aware of: FJP keeps threads spinning for a while to be able to handle just-in-time arriving work faster. This ensures good latency in many cases. Especially if your pool is overprovisioned, however, the trade-off is a bit of latency against more power consumption in almost-idle situations.

Answer 1

Akka 中的 FJP 使用 asyncMode = true 运行，因此第一个问题是 - 让外部客户端提交短期/小型异步工作负载。每个提交的工作负载要么分派(dispatch)一个 actor 来处理其收件箱中的一条或几条消息，但它也用于执行 Scala Future 操作。

当非ForkJoinTask 计划在 FJP 上运行时，它会适应 FJP 并像 ForkJoinTask 一样入队。没有一个任务排队的提交(在早期版本中，也许是 JDK7)，有很多，以避免争用，空闲线程可以从其他队列中挑选(窃取)任务，如果是的话空。

请注意，默认情况下，我们当前在 Java 8 FJP 的 fork 版本上运行，因为我们看到 Java 9 FJP 出现时吞吐量显着下降(它包含相当多的更改)。这是 issue #21910 discussing that如果你感兴趣。此外，如果您想对不同的池进行基准测试，您可以在此处找到一些 *Pool 基准:https://github.com/akka/akka/tree/master/akka-bench-jmh/src/main/scala/akka/actor