如何在 Kotlin 协程中使用阻塞（I/O 绑定）API？

Question

我正在使用Ktor编写一个 Kotlin 服务器- 我的请求处理程序是使用 Kotlin 协程编写的。

我的理解是每个请求处理程序都在 Ktor 的线程池上运行，由于协程的轻量级/可挂起性质，该线程池包含的线程远少于传统的每个请求 1 线程服务器框架的池大小。伟大的！

我遇到的问题是我的应用程序仍然需要与一些阻塞资源（JDBC 数据库连接池）交互，但我的理解是，如果我只是直接从请求协程调用这些阻塞 API，我最终会遇到活性问题- 因为我最终可能会阻塞所有用于处理我的请求的线程！不是很好。

由于我对 Kotlin 和协程的世界还比较陌生，我想知道这里是否有人可以给我一些关于处理这种情况的最佳方法的提示。

---

我在其他地方看到过Dispatchers.IO几次引用。这被认为是管理这些阻塞呼叫的最佳方式吗？这方面有什么好的例子吗？

我尝试使用的 API 确实允许通过传递Executor. 理想情况下，我还可以将这些调用包装在方便、惯用的 Kotlin API 中以进行suspend事务处理。

Answer 1

你理解这一切都是正确的。在大多数情况下，您不应该在协程内阻​​塞线程。Dispatchers.IO您提到了一个例外。这是处理阻塞代码的标准方法，并且非常易于使用：

withContext(Dispatchers.IO) {
    // blocking code
}

withContext()是一个挂起函数，因此您可以将上面视为将阻塞转换为挂起的方法。然而，Dispatchers.IO它并没有真正发挥任何魔力——它只是使用更大的线程池，指定用于阻塞。我相信默认情况下它最多创建 64 个线程。

如果需要执行多个并行阻塞操作，通常最好创建自己的线程池，以免阻塞应用程序的其他组件。

如果 IO 库提供异步 API，那么通常最好使用它而不是阻塞 API。然而，在许多情况下，库通过管理自己的内部线程池进行阻塞来提供异步 API。在这种情况下，使用异步 API 和使用阻塞 APIDispatchers.IO非常相似。Dispatchers.IO可能会更好，因为它在所有 IO 操作中重复使用相同的 IO 线程，并且它可以与指定用于 CPU 计算的线程池部分共享线程 ( Dispatchers.Default)。