在阅读了有关 Tomcat NIO 连接器的信息后，我仍然不明白一件事:如果应用程序代码阻塞，nio 连接器是否有益，即它在从数据库读取、读取文件系统、调用外部 Web 时阻塞服务？
因此，例如，您有一个类似 REST 的 API，它接收请求、从数据库读取内容并返回响应。它不使用 servlet 3 async，它只是写入响应。
我没有找到 NIO 连接器使用的线程池的完整描述，但我想它有一个线程池来处理请求，所以每个请求都在它自己的线程中结束，它可以阻塞。
如果是这样，NIO 的优势是否仍然存在，或者阻塞代码削弱了 NIO 的优势(在资源利用方面)？
最佳答案
Is the nio connector beneficial if the application code is blocking...?
是，NIO 连接器是在假设您的应用程序会在某处阻塞的情况下构建的。 NIO 连接器基本上有几个套接字占位符并响应新的传入请求，直到信息开始被写回。
I didn't find a full description of the thread pools used by the NIO connector
我认为这是你困惑的开始。 Tomcat NIO 有一个选择器池，而不是线程池 ( reference )。连接器代码轮询每个选择器以查看它是否有要发送的传入或传出字节。从这个意义上说，给定请求的选择器将继续接收信息，直到有足够的信息来处理请求/响应对象，该对象弥合了同步 I/O 和异步 I/O 之间的差距 (reference)。
轮询代码的阻塞时间永远不会超过序列化一个信息包所需的时间，因此它可以自由处理新请求。唯一真正的限制是 Tomcat 可用的内存量。虽然有线程池，但实际使用的线程数远低于应用程序可以处理的连接数 (reference)。
虽然 Tomcat 连接器 (reference) 之间存在性能差异，但当 servlet 本身阻塞时，原始请求/响应时间的差异非常小。但是，当您使用非阻塞 I/O 时，Tomcat 可以处理的并发请求数的差异很大。
关于java - 具有阻塞应用程序的 Tomcat NIO 连接器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28816121/