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

Question

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

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

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

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

Answer 1

我不能代表Scala设计师说话，但是scala Future的惯用用法通常涉及创建很多非常小的，短暂的任务（例如，每次map调用都会创建一个新任务），因此窃取工作的设计是合适的。

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