Scala和第三方Java库中Akka的最佳做法

Question

我需要在Scala / Akka代码中使用memcached Java
API
。该API为您提供同步和异步方法。异步的返回java.util.concurrent.Future。这里有一个关于在Scala中处理JavaFutures的问题，如何在AkkaFuture中包装java.util.concurrent.Future？。但是，就我而言，我有两种选择：

1. 使用同步API并在以后包装阻塞代码并标记阻塞：

        Future {
      blocking {
        cache.get(key) //synchronous blocking call
      } 
    }

1. 使用异步Java API，并在Java Future上每隔n ms轮询一次，以检查future是否完成（如以上链接的问题中的上述答案之一所述）。

哪一个更好？我倾向于第一种选择，因为轮询会极大地影响响应时间。不应该blocking { }阻止阻止整个池吗？

Answer 1

我总是选择第一个。但是我这样做的方式略有不同。我不使用该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 use

Future {
    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阻止调用。 同时考虑断路。