Java IO vs NIO vs Tasks队列

Question

我已经看到很多主题，它们将较旧的Java io模型与较新的Java nio模型进行了比较，前者是同步/阻塞，而后者是异步/非阻塞。因为nio是非阻塞的，所以在需要并发处理大量并发连接而不分配大量线程（由于上下文切换/内存使用而无法很好扩展）的情况下，它比java io更适合。

我在使用此参数时遇到的问题是，IO与NIO的比较总是给出每个连接使用线程的IO示例。使用Java IO的开发人员可以简单地分配有限数量的线程（线程池）来阻止IO操作（即文件读取或数据库查询）并将它们排队吗？假设我正在使用Java的ServerSocket类从头开始构建http服务器。假设我从客户端收到一个请求，该请求要求我进行数据库查询，这是由于JDBC规范而导致的阻塞操作。我是否可以简单地将数据库查询排队到ThreadPool并在池完成处理后将作业递给要运行的回调？当然，我正在分配线程来处理io-bounds请求，但是线程数是有限的。由于IO操作通常是同步的（一定程度上），

这样，您可以获得线程和异步编程的好处，而不必分配过多的线程。

我在此模型中看到的唯一弱点是，如果所有io绑定操作都被阻塞（可能是由于编程错误），则将来的排队请求将被搁置，直到它们被取消阻塞或超时。主要逻辑仍然是并发的，但IO不是。

所以，问题是：NIO是否解决了上面描述的模型无法解决的任何问题（排除了我刚刚提到的潜在弱点）？

Answer 1

当然，您可以使用池和有限数量的线程来完成此操作并处理您自己的 I/O，但您基本上会重复 NIO 为您提供的功能，但无法利用本机 API。

您的系统无法很好地处理的问题之一是有数千个套接字执行缓慢的 I/O，这是处理服务器推送、BitTorrent 客户端或可能非常繁忙的内容服务器所需的。

更传统的请求/响应系统可以很好地处理您的解决方案，但话又说回来，它们也可以很好地处理每个请求的线程，因为通常遇到的第一个瓶颈是 CPU 或内存消耗。