您观察到的是预期的行为——当然它非常糟糕。存在已知的解决方案和最佳实践来防范它，这很好。在这个答案中，我想花一些时间来简短、详细地解释这个问题——阅读愉快！
简短回答：“不要阻塞路由基础设施！”，始终使用专用调度程序来阻塞操作！
观察到症状的原因：问题是您使用context.dispatcher 作为阻塞期货执行的调度程序。路由基础设施使用同一个调度程序（简单来说只是“一堆线程”）来实际处理传入的请求——因此，如果您阻塞所有可用线程，最终会导致路由基础设施匮乏。 （有待讨论和基准测试的事情是，如果 Akka HTTP 可以避免这种情况，我会将其添加到我的研究待办事项列表中。
必须特别小心地处理阻塞，以免影响同一调度程序的其他用户（这就是为什么我们如此简单地将执行分离到不同的用户），如 Akka 文档部分所述：Blocking needs careful management。
我想在这里提请注意的另一件事是，应该尽可能避免阻塞 API - 如果您的长时间运行的操作不是真正的一个操作，而是一系列操作，您可以将它们分离到不同的参与者或排序的未来。无论如何，只是想指出——如果可能的话，避免这种阻塞调用，但如果你必须——那么下面解释了如何正确处理这些调用。
深入分析及解决方案：
现在我们知道了问题所在，从概念上讲，让我们看看上面代码中到底有什么问题，以及这个问题的正确解决方案是怎样的：
颜色 = 线程状态：
- 绿松石 – 睡觉
- 橙色 - 等待中
- 绿色 - 可运行
现在让我们研究 3 段代码以及它们如何影响调度程序和应用程序的性能。为了强制执行此行为，应用程序已置于以下负载下：
- [a] 继续请求 GET 请求（请参阅上面最初问题中的代码），它不会在那里阻塞
- [b] 然后在一段时间后触发 2000 个 POST 请求，这将导致 5 秒阻塞，然后返回未来
1) [bad] 错误代码上的调度程序行为：
// BAD! (due to the blocking in Future):
implicit val defaultDispatcher = system.dispatcher
val routes: Route = post {
complete {
Future { // uses defaultDispatcher
Thread.sleep(5000) // will block on the default dispatcher,
System.currentTimeMillis().toString // starving the routing infra
}
}
}
所以我们将我们的应用程序暴露给 [a] 负载，您可以看到已经有许多 akka.actor.default-dispatcher 线程 - 它们正在处理请求 - 小的绿色 sn-p 和橙色表示其他线程实际上在那里闲置。
然后我们启动 [b] 加载，这会导致这些线程阻塞 - 您可以看到早期线程“default-dispatcher-2,3,4”在之前空闲后进入阻塞状态。我们还观察到池在增长——新线程在“default-dispatcher-18,19,20,21...”启动，但它们立即进入睡眠状态（！）——我们在这里浪费了宝贵的资源！
此类启动线程的数量取决于默认调度程序配置，但可能不会超过 50 左右。由于我们刚刚触发了 2k 阻塞操作，我们使整个线程池处于饥饿状态——阻塞操作占主导地位，以至于路由基础设施没有线程可用于处理其他请求——非常糟糕！
让我们做点什么（顺便说一句，这是 Akka 的最佳实践——始终隔离阻塞行为，如下所示）：
2) [good!]调度程序行为良好的结构化代码/调度程序：
在您的application.conf 中配置此调度程序，专门用于阻止行为：
my-blocking-dispatcher {
type = Dispatcher
executor = "thread-pool-executor"
thread-pool-executor {
// in Akka previous to 2.4.2:
core-pool-size-min = 16
core-pool-size-max = 16
max-pool-size-min = 16
max-pool-size-max = 16
// or in Akka 2.4.2+
fixed-pool-size = 16
}
throughput = 100
}
您应该阅读Akka Dispatchers 文档中的更多内容，以了解此处的各种选项。重点是我们选择了一个ThreadPoolExecutor，它对阻塞操作保持可用的线程有一个硬性限制。大小设置取决于您的应用执行的操作以及您的服务器有多少内核。
接下来我们需要使用它，而不是默认的：
// GOOD (due to the blocking in Future):
implicit val blockingDispatcher = system.dispatchers.lookup("my-blocking-dispatcher")
val routes: Route = post {
complete {
Future { // uses the good "blocking dispatcher" that we configured,
// instead of the default dispatcher – the blocking is isolated.
Thread.sleep(5000)
System.currentTimeMillis().toString
}
}
}
我们使用相同的负载对应用施加压力，首先是一些正常请求，然后我们添加阻塞请求。这就是线程池在这种情况下的行为方式：
所以最初正常请求很容易由默认调度程序处理，您可以在那里看到几条绿线 - 那是实际执行（我并没有真正将服务器置于重负载下，所以它大部分是空闲的）。
现在，当我们开始发出阻塞操作时，my-blocking-dispatcher-* 会启动，并启动最多配置的线程数。它处理那里的所有睡眠。此外，在这些线程上没有任何事情发生一段时间后，它会关闭它们。如果我们用另一堆阻塞来攻击服务器，池将启动新线程来处理它们的 sleep()-ing，但与此同时——我们不会浪费我们宝贵的线程在“只是呆在那里并且什么都不做”。
使用此设置时，正常 GET 请求的吞吐量不会受到影响，它们仍然可以在（仍然相当免费的）默认调度程序上愉快地提供服务。
这是处理反应式应用程序中任何类型阻塞的推荐方法。它通常被称为“屏蔽”（或“隔离”）应用程序的不良行为部分，在这种情况下，不良行为是休眠/阻塞。
3) [workaround-ish] 正确应用blocking 时的调度程序行为：
在这个例子中，我们使用scaladoc for scala.concurrent.blocking 方法，它可以在遇到阻塞操作时提供帮助。它通常会导致更多线程被启动以在阻塞操作中存活。
// OK, default dispatcher but we'll use `blocking`
implicit val dispatcher = system.dispatcher
val routes: Route = post {
complete {
Future { // uses the default dispatcher (it's a Fork-Join Pool)
blocking { // will cause much more threads to be spun-up, avoiding starvation somewhat,
// but at the cost of exploding the number of threads (which eventually
// may also lead to starvation problems, but on a different layer)
Thread.sleep(5000)
System.currentTimeMillis().toString
}
}
}
}
应用程序的行为如下：
您会注意到创建了 很多 新线程，这是因为阻塞提示“哦，这将是阻塞的，所以我们需要更多线程”。这导致我们被阻塞的总时间比 1) 示例中的要小，但是在阻塞操作完成后我们有数百个线程什么都不做......当然，它们最终会被关闭（FJP 会这样做)，但在一段时间内，我们将有大量（不受控制的）线程在运行，与 2) 解决方案相比，我们确切地知道有多少线程专门用于阻塞行为。
总结：永远不要阻塞默认调度器:-)
最佳实践是使用 2) 中显示的模式，为可用的阻塞操作提供一个调度程序，并在那里执行它们。
讨论的 Akka HTTP 版本：2.0.1
使用的分析器：很多人私下问我这个答案，我用什么分析器来可视化上面图片中的线程状态，所以在这里添加这个信息：我使用了YourKit是一个很棒的商业分析器（OSS 免费），尽管您可以使用免费的VisualVM from OpenJDK 获得相同的结果。