为什么Scala构建自己的ForkJoinPool而不是使用java.util.concurrent.ForkJoinPool＃commonPool？

Question

Java和Scala都引入了自己的全局ForkJoinPool，Java为java.util.concurrent.ForkJoinPool#commonPool，Scala为scala.concurrent.ExecutionContext#global。这两个似乎都打算用于相同的用例，特别是运行非阻塞并发任务（通常是隐式地）。现在，根据我的理解，如果您以错误的方式选择了互操作性依赖项，您将最终得到两个线程池做完全相同的事情，一个用于Java世界，另一个用于Scala世界。

因此，除非我缺少明显的东西，否则Scala是否有充分的理由不将Java commonPool用作其全局ExecutionContext？

Answer 1

添加到其他答案 - 除了 JVM 版本问题之外，使用 JVM 特定实现会将 Scala API 绑定到 Java 内部。即使这不是最初的目标，现在 Scala 社区希望瞄准多个后端：我们有 Scala、Scala.js、Scala Native。如果我们决定改变一些东西，并将 Scala 库与 JVM API 代码结合起来，那么它的可移植性将会毫无理由地降低——毕竟 JVM 上的 ExecutionContext 仍然在内部使用一些 Java 的线程池实现，所以这并不是说我们在重新发明轮子。