multithreading - 为什么 Scala 使用 ForkJoinPool 来支持其默认的 ExecutionContext？

Question

在 Scala 中，您可以使用全局 ExecutionContext如果您不需要通过导入 scala.concurrent.ExecutionContext.Implicits.global 来定义自己的.

我的问题是为什么ForkJoinPool为这个执行程序选择了而不是 ThreadPoolExecutor .

我的理解是 fork-join 框架在递归分解问题方面非常出色。您应该编写将任务分成两半的代码，这样一半可以在线程内执行，另一半可以由另一个线程执行。这似乎是一种非常特殊的编程模型，而不是通常适用于在各种可能的应用程序中处理一般异步任务的执行的模型。

那么为什么是 ForkJoinPool为大多数人可能会使用的默认执行上下文选择？即使您不使用完整的 fork-join 范例，工作窃取设计是否会提高性能？

Answer 1

我不能代表scala 设计师，但是scala 的惯用用法Future s 通常涉及创建许多非常小的、短期的任务(例如，每个 map 调用都会创建一个新任务)，因此工作窃取设计是合适的。

如果您关心这些精确的细节，您可能更喜欢使用 scalaz-concurrent 的 Future ，它使用蹦床来避免为每个 map 创建额外的任务step 并使执行上下文显式(并且 AIUI 默认为 ThreadPoolExecutor )。