我总是选择第一个。但是我这样做的方式略有不同。我不使用该
blocking功能。（实际上我还没有考虑过。）相反，我向Future提供了一个自定义执行上下文，该上下文包装了同步阻塞调用。所以基本上看起来像这样：
val ecForBlockingMemcachedStuff = ExecutionContext.fromExecutorService(Executors.newFixedThreadPool(100)) // whatever number you think is appropriate// i create a separate ec for each blocking client/resource/api i useFuture { cache.get(key) //synchronous blocking call}(ecForBlockingMemcachedStuff) // or mark the execution context implicit. I like to mention it explicitly.因此，所有 阻塞调用都将使用专用的执行上下文（= Threadpool） 。因此，它与负责非阻塞内容的主要执行上下文分离。
Typesafe提供的Play / Akka在线培训视频中也介绍了这种方法。第4课中有一个有关如何处理阻止呼叫的视频。 Nilanjan Raychaudhuri
（希望我拼写正确）对此做了解释，他是Scala书籍的著名作者。
更新：
我在Twitter上与Nilanjan进行了讨论。他解释了使用方法
blocking和习惯之间的区别
ExecutionContext是什么。该
blocking功能只是创建一个特殊的
ExecutionContext。它提供了一个幼稚的方法来解决您需要多少个线程的问题。每当池中所有其他现有线程都忙时，它将每次生成一个新线程。因此，它实际上是一个
不受控制的 ExecutionContext。它可能会创建很多线程，并导致 出现诸如内存不足错误之类的问题
。因此，使用自定义执行上下文的解决方案实际上更好，因为它使此问题显而易见。Nilanjan还补充说，如果此池因请求而过载，则需要考虑断路。
TLDR：是的，阻止通话很糟糕。 使用自定义/专用的ExecutionContext阻止调用。 同时考虑断路。
