java 如何选择java nio vs io？

how to choose java nio vs io?

提问by jiafu

As we had known, If we want to use traditional IO to construct server, it must block somewhere, so we had to use loop or one thread one socket mode, So nio seem it is better choice. So I want know if the nio is better choice forever?

众所周知，如果我们要使用传统的IO来构建服务器，它必须在某处阻塞，所以我们不得不使用循环或单线程一套接字模式，所以nio似乎是更好的选择。所以我想知道nio是否永远是更好的选择？

采纳答案by Peter Lawrey

IMHO, Blocking IO is generally the simplest to use, and unless you have a specific requirement which demands more from your system, you should stick with simplest option.

恕我直言，阻塞 IO 通常是最容易使用的，除非您有特定要求对系统有更多要求，否则您应该坚持使用最简单的选项。

The next simplest option is blocking NIO, which I often prefer if I want something more efficiency or control than IO. It is still relatively simple but allows you to use ByteBuffers. e.g. ByteBuffers support little endian.

下一个最简单的选项是阻塞 NIO，如果我想要比 IO 更高的效率或控制力，我通常更喜欢它。它仍然相对简单，但允许您使用 ByteBuffers。例如 ByteBuffers 支持小端。

A common option is to use non-blocking NIO with Selectors. Much of the complexity this introduces can be handled by frameworks such as Netty or Mina. I suggest you use such a library if you neednon-blocking IO e.g. because you have thousands of concurrent connections per server. IMHO You have thousands of connections, you should consider having more servers unless what each connection does is pretty trivial. AFAIK google go for more servers rather thousands of users per server.

一个常见的选择是将非阻塞 NIO 与选择器一起使用。这引入的大部分复杂性可以由 Netty 或 Mina 等框架处理。如果您需要非阻塞 IO，我建议您使用这样的库，例如因为每个服务器有数千个并发连接。恕我直言，您有数千个连接，您应该考虑拥有更多服务器，除非每个连接的作用都非常微不足道。AFAIK google 需要更多的服务器，而不是每台服务器有数千个用户。

The more extreme option is to use NIO2. This is even more complex and lengthy it write than non-blocking NIO. I don't know of any frameworks which support this well. i.e. it is actually faster when you do. AFAIK It appears this is worth using if you have Infiniband (which is what it was designed to support) but perhaps not worth using if you have Ethernet.

更极端的选择是使用 NIO2。这比非阻塞 NIO 更复杂和更冗长。我不知道有什么框架可以很好地支持这一点。即当你这样做时它实际上更快。AFAIK 如果您有 Infiniband（这是它旨在支持的内容），这似乎值得使用，但如果您有以太网，则可能不值得使用。

回答by Marko Topolnik

If you want non-blocking IO, NIO is not the better choice—it's the onlychoice in Java. Keep in mind that people still use the old IO regularly because it is way simpler to code against. NIO API is quite raw and is more of an enabling low-level technology than a client-side API. I suggest using NIO through an API that provides a simpler interface to the problems you want to solve using non-blocking IO.

如果您想要非阻塞 IO，NIO 不是更好的选择——它是Java 中的唯一选择。请记住，人们仍然经常使用旧的 IO，因为它更易于编码。NIO API 非常原始，与其说是客户端 API，不如说是一种支持底层技术。我建议通过 API 使用 NIO，该 API 为您要使用非阻塞 IO 解决的问题提供更简单的接口。

回答by user3629892

A little late, but personally, I use NIO even for the regular "everyday" file handling. So, I use things like:

有点晚了，但就我个人而言，即使是常规的“日常”文件处理，我也使用 NIO。所以，我使用类似的东西：

 1. if(Files.notExists(path)) { } 
 2. Files.createDirectory(path);
 3. Files.newInputStream(path) targetPath.resolve("somefile.txt");
 4. Files.newBufferedWriter(path, charset);
 5. DirectoryStream<Path> directoryStream = Files.newDirectoryStream(path);

and it works fine for me. I prefer Path instead of the old File because of methods like relativize or resolveSibling.

它对我来说很好用。我更喜欢 Path 而不是旧的 File，因为像 relativize 或 resolveSibling 这样的方法。

Doesn't strike me as more complicated than IO.

我觉得并不比 IO 更复杂。

回答by Nico de Wet

You would only use NIO if you can justify the inevitable complexity that it introduces. If you do not have any guidance in terms of the expected load, and also in terms of whether your product / project has the resources to maintain the relevant code, then your should err on the side of caution and use IO.

只有当你能证明它引入的不可避免的复杂性是合理的时，你才会使用 NIO。如果您在预期负载方面以及您的产品/项目是否具有维护相关代码的资源方面没有任何指导，那么您应该谨慎使用 IO。

To give my answer some weight, I have just spent three months maintaining and bug fixing an integration layer where raw Java NIO (i.e. no overarching framework was used) was used. The design was based, in essence, on client threads adding messages to a queue and a small number of worker threads performing their NIO magic and then passing replies back to client threads in an event-based manner. In retrospect, I cannot justify the original decision to use NIO, since it became a distraction that ate significant amounts of time that should have been spent on higher level business logic.

为了给我的答案一些权重，我刚刚花了三个月的时间来维护和修复使用原始 Java NIO（即未使用总体框架）的集成层。该设计本质上是基于客户端线程将消息添加到队列和少量工作线程执行它们的 NIO 魔法，然后以基于事件的方式将回复传递回客户端线程。回想起来，我无法证明使用 NIO 的最初决定是正确的，因为它成为一种分心，占用了本应花在更高级别的业务逻辑上的大量时间。

回答by Max

You can use any of this, unless you are going to create "super fast" server.

您可以使用其中任何一个，除非您要创建“超快”服务器。

Of course a good approach here is to use nio, since it's new and modern way to write multi-client servers for high throughput tasks.

当然，这里的一个好方法是使用 nio，因为它是为高吞吐量任务编写多客户端服务器的新的现代方法。

回答by Imar

Some advantages of the NIO.2 API over the legacy java.io.File class for working with files:

在处理文件方面，NIO.2 API 相对于旧的 java.io.File 类的一些优点：

• Supports file system–dependent attributes.
• Allows you to traverse a directory tree directly.
• Supports symbolic links.

• 支持文件系统相关的属性。
• 允许您直接遍历目录树。
• 支持符号链接。

For specific use cases and more details, you can see thisarticle

具体用例和更多细节，可以看这篇文章

回答by Andrea Bori

Traditional IO is easy and simplified code, NIO is more complicated but more flexible. In my case i prefer use IO for smallstreaming and NIO for largestreaming but nio is really more complex

传统 IO 是简单和简化的代码，NIO 更复杂但更灵活。就我而言，我更喜欢将 IO 用于小型流媒体，将 NIO 用于大型流媒体，但 nio 确实更复杂

with NIO i have to create an entire package to manage it instead io package that i directly use snippet

使用 NIO 我必须创建一个完整的包来管理它而不是我直接使用代码段的io 包