vert.x和生物线程

Question

最近我开始学习reactive、事件驱动和非阻塞Java框架，其中一个引起了我的注意——vert.x。

我想，同样的问题可能适用于akka（Play框架），因为他们的理念或目标之一是相同的，那就是减少线程数量，从而提高应用程序的可扩展性。

垂直。x建议它所消耗的线程数与CPU内核数相当，但它也表明，有时您必须执行阻塞操作，因此它鼓励开发人员在单独的工作线程上执行阻塞操作（垂直于vert.x的工作线程）。

这就是我要问的问题：

• 如果我应该在一个新的单独线程上执行阻塞 IO 操作，这意味着执行阻塞操作的每个用户都有一个新线程，因此线程数再次等于经典阻塞线程模型中的用户数？

一个真实的例子是 JDBC 查询 - 如果 1000 个并发用户通过 JDBC 查询 SQL 数据库，则每个用户都会为该阻塞操作生成自己的工作线程。从我的角度来看，与传统的阻塞线程模型相比，没有线程备用、改进的可扩展性或 RAM 备用。我一定错过了什么...要不？提前感谢所有的答案。

Answer 1

如前所述，您应该使用连接池，但是如果您对数据库访问而不是特定的JDBC感兴趣，您可以查看async db驱动程序，例如：

• Async MySQL/PostgreSQL

这些驱动程序依赖于netty，因此它的所有IO操作都是非阻塞的，这意味着您不需要有工作线程池。更少的线程意味着操作系统级别的上下文切换更少，从而带来更好的性能。

遗憾的是，这些驱动程序并不多（我只知道MySQL和PostgreSQL），所以如果您被迫使用其他RDBMS，您可能会倒霉。

Answer 2

vert. x建议在机器上运行线程，而不是用户。

他们所说的是，如果你有16个CPU内核可用，并且有16个准备工作的线程，那么如果你对其中一个运行阻塞操作，最多只有15个线程保持工作状态，因此只有15个CPU内核实际上在工作。

因此，为了防止有一个空闲内核，他们建议您再创建一个线程，并将阻塞任务交给它，这样16个CPU内核上仍有16个线程在工作。

阻塞线程的数量并不重要（只要它不太大…），因为它们实际上不会消耗您的CPU能力。

它与通常的阻塞模型不同，因为您隔离了您那边不需要太多资源的阻塞操作。剩下的是在您拥有的工作线程之间共享剩余的事件驱动操作。

Answer 3

在查询 SQL 数据库时生成 1000 个并发线程是没有意义的 - 仅仅因为典型的数据库无法承受这么多同时连接，典型的数量是 10-15。解决方案是组织一个特殊的线程池，其中每个线程都有一个开放的连接，并为访问数据库的任务提供服务。任务提交到公共阻塞队列，工作线程循环从该队列读取。任务是

interface DBRunnable {
  public void run(Connection conn);
}

工作线程将它们的连接传递给任务：

public void run() {
  Connection conn = DriverManager.getConnection(...);
  while (true) {
     DBRunnable task=queue.take();
     task.run(conn);
  }
}