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

Question

29

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

我的问题是为什么选择ForkJoinPool作为执行程序，而不是ThreadPoolExecutor。

我理解fork-join框架非常擅长递归地分解问题。您应该编写将任务分成两半的代码，以便一半可以在线程中执行，另一半可以由另一个线程执行。这似乎是一种非常特定的编程模型，而不是通常适用于处理广泛异步任务执行的一般性应用程序之一。

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

- Rag

https://dev59.com/AWsz5IYBdhLWcg3wZm7Q#7927009 - ka4eli

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- lmm · Accepted Answer

我不了解scala设计者的想法，但是scala Future 的惯用方法通常涉及创建大量非常小的、短暂的任务 (例如每个map调用都会创建一个新任务)，因此工作窃取设计是合适的。

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