传统java io_NIO性能改进与Java中的传统IO相比

NIO vs IO是一个非常有趣的话题。

根据我的经验，两者是两种不同工作的两种不同的工具。我听说IO被称为“每客户端线程”，NIO被称为“所有客户端程序的一个线程”，我发现这些名称虽然不够准确，但足够准确。

正如我所看到的，NIO和IO的真正问题在于可扩展性。

NIO网络层将(应该？)使用单个线程来处理选择器并将读/写/接受作业分派给其他线程。这使得线程处理选择器(“选择器线程”)只能做到这一点。当客户处理很多(注意实际数量不足)的情况下，这样可以有更快的响应。现在，NIO开始分崩离析的时候是服务器读取/写入/接受Selector Thread不断工作的时候。任何额外的工作，通过这个和服务器开始滞后。此外，由于所有读/写/接受作业都由选择器线程处理，所以向混音添加其他CPU将不会提高性能。

IO网络层可能会采用每个插座1个线程的方式，包括监听套接字。所以线程数与客户端数成正比。在适量的客户身上，这种方式效果很好。使用这种方法支付的成本是线程成本的形式。如果您有2000个客户端连接到服务器…您至少有2001个线程。即使在一个四芯片的每芯片机器中，只有24个处理节点(如果您计算超线程，则为48个)来处理这些2001线程。实例化所有这些线程花费cpu时间和RAM，但即使您使用线程池，您仍然必须支付CPU上下文切换的成本，因为它们从线程移动到线程。这可能会在高服务器负载下变得非常难看，如果编码不正确，可以使整个机器停止工作。在这方面，将CPU添加到机器将在这种情况下提高性能。

现在所有这一切都很好，但是是抽象的，因为我的描述中没有数字来帮助决定与IO或NIO做决定。这是因为还有更多的变数需要考虑：

>客户的生活时间？短还是长？

>预期每位客户的数据量？许多小块或几块巨大的块？

>预计同时连接多少客户？

>你使用什么操作系统，你使用什么JVM？两者都是线程和轮询成本。

只是一些想法的食物。要回答哪个问题更快，NIO或IO：两者都不是:)