在 scala 中使用 future 时，默认行为是使用默认的 Implicits.global 执行上下文。看来这默认为每个处理器提供一个可用线程。在更传统的线程 Web 应用程序中，当 future 执行诸如等待数据库之类的任务(而不是某些 cpu 绑定(bind)任务)时，这似乎是一个糟糕的默认值。
我希望覆盖默认上下文在生产中是相当标准的，但我发现关于这样做的文档很少，看起来它可能并不那么常见。我错过了什么吗？
最佳答案
与其将其视为覆盖默认执行上下文，不如问“我应该为不同的事情使用多个执行上下文吗？”如果这是这个问题，那么我的答案是肯定的。在我工作的地方，我们使用 Akka。在我们的应用程序中，我们使用默认的 Akka 执行上下文来实现非阻塞功能。然后，因为目前没有好的非阻塞 jdbc 驱动程序，所以我们所有的阻塞 SQL 调用都使用单独的执行上下文，其中每个连接一个线程的方法。保持主执行上下文( fork 连接池)不受阻塞会显着增加我们的吞吐量。
我认为在系统中针对不同类型的工作使用多个不同的执行上下文是完全可以的。这对我们来说效果很好。
关于scala - 我应该覆盖默认的 ExecutionContext 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16834339/