与Java中的传统IO相比，NIO性能有所提高

我看到许多文章/博客说，与传统的JavaIO相比，JavaNIO是一个更好的解决方案

---

但是今天我的一个同事给我看了这个博客。我想知道Java社区是否有人做过这种与Java NIO性能相关的基准测试。

您引用的文章已经三年了。它使用Java1.4.2（4）

从那时起，Java5、6和现在的7都被淘汰了

JVM内部以及类库中的巨大变化使得与1.4.2的基准测试相关的一切变得无关紧要

如果您开始挖掘，还将注意到java.io和java.nio之间的区别并不十分清楚。许多java.io调用现在解析为java.nio类

但是，无论何时您想要提高性能，解决方案都不是只做一件事。唯一确定的方法是尝试不同的技术并测量它们，因为对我的应用程序来说速度快的东西对你的应用程序来说未必如此，反之亦然。对于某些应用程序，NIO可能会慢一些。或者它可能是性能问题的解决方案。很可能两者兼而有之。

a比B快。通常是一种非常简单的观点，有时是完全错误的

NIO不是自动比普通IO快

使用NIO，某些操作可能会更快，并且使用NIO可以更轻松地扩展到多个网络连接（因为每个连接不需要一个线程）

---

但是NIO并不是一个神奇的“让事情变得更快”的开关，它需要应用于所有事情。

另外，好吧，Java IO被重写为在幕后使用NIO（NIO有更多的功能）。正如拉维尼奥所说，微基准只是个坏主意，特别是当它们很旧的时候。

Java IO会遇到一些构造和类。你不能在这样一般的水平上进行比较。具体来说，NIO使用内存映射文件进行读取——理论上，这比简单的

BufferedInputStream

文件读取要快一些。然而，如果您比较像

RandomAccess

文件读取这样的内容，那么NIO内存映射文件将快得多

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

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

在我看来，NIO和IO的真正问题在于可伸缩性

NIO网络层将（应该？）使用单个线程来处理选择器，并将读/写/接受作业分派给其他线程。这允许处理选择器的线程（“选择器线程”）只执行该操作。这使得在处理大量（请注意，缺少实际数量）客户时，响应速度更快。现在，NIO开始崩溃的地方是当服务器获得如此多的读/写/接受，以至于选择器线程一直在工作时。超过此值的任何其他作业都会导致服务器开始延迟。此外，由于所有读/写/接受作业都由选择器线程处理，因此向混合中添加额外的CPU不会提高性能

IO网络层可能采用每个套接字1个线程的方法，包括侦听套接字。因此线程的数量与客户端的数量成正比。在客户机数量适中的情况下，这种方法非常有效。使用这种方法所付出的代价是线程的代价。如果您有2000个客户端连接到服务器。。。您至少有2001个线程。即使是在一个四芯片，每个芯片6核的机器中，也只有24个处理节点（如果算上超线程，则为48个）来处理这些线程。实例化所有这些线程需要花费cpu时间和ram，但即使使用线程池，在cpu上下文从一个线程切换到另一个线程时，您仍然需要支付cpu上下文切换的费用。在服务器负载较高时，这可能会变得非常糟糕，如果编码不正确，可能会使整个机器停止运行。从好的方面来说，在这种情况下，向机器添加CPU将提高性能

现在所有这些都是好的，但都是抽象的，因为在我的描述中没有数字可以帮助我们做出选择IO还是NIO的决定。这是因为有更多的变量需要考虑：

• 客户的生命周期？短的还是长的
• 每个客户端预期的数据量？很多小块还是很少大块
• 究竟需要同时连接多少个客户端
• 您使用的是什么操作系统和JVM？这两个因素都会影响线程和轮询成本

---

只是一些值得思考的东西。要回答哪个更快的问题，NIO或IO:Both和note:）

这篇文章的问题是它比较了阻塞IO和非阻塞NIO。在我自己的测试中，比较阻塞IO和阻塞NIO（更像是一对一），NIO的速度要快30%

但是，除非您的应用程序像代理服务器一样微不足道，否则它就不太重要。应用程序的作用要重要得多。IO和NIO都经过了多达10000个连接的测试

---

如果您想要超快的IO，可以将异步IO（Java 7+）与Infiniband一起使用（价格不便宜，但延迟较低）

没有内在的原因说明一种IO比另一种更快

---

每个线程一个连接模型目前面临的问题是，Java线程有很大的内存开销——线程堆栈被预先分配到一个固定的（大的）大小。这可以而且应该得到解决；然后我们可以廉价地创建数十万个线程。

使用NIO并不是因为它速度更快，而是因为它具有更好的可伸缩性，尤其是有大量的客户端

IO（阻塞IO/St