客户端 NIO 真的很重要吗？答案

【问题标题】：Does the client side NIO really matter?客户端 NIO 真的很重要吗？
【发布时间】：2012-08-31 02:59:40
【问题描述】：

据我所知，蔚来可以帮助服务器，处理很多请求。因为 NIO 不是每个请求模型使用一个线程。

但是客户端是创建与服务器的连接的，通常没有那么多连接，客户端完全可以处理。

我看到一些客户端库使用 NIO，但我不太确定。那么为什么客户端的蔚来兄弟，有没有性能提升呢？

【问题讨论】：

【解决方案1】：

没有很好的理由在客户端使用 NIO，除非您可能正在编写具有数百或数千个出站连接的网络爬虫之类的东西。

可以说，在服务器上用户也没有太多理由。 select() 模型是为替代方案分叉进程的时代设计的。现在我们有了线程，整个模型没有实际意义。

【讨论】：

“select() 模型是为替代方案派生进程的时代设计的。现在我们有了线程，整个模型没有实际意义，恕我直言。”这是一个相当强烈的声明。事件提供了一种不同的范式（有些人认为这种范式更自然），而且线程的开销虽然单独很小，但在相当低的数量之后会变得太多。
@Corbin 你说'一个相当低的数字'，我说'数百或数千'。我在这里没有看到任何分歧。
当您考虑调度开销和内存开销时，我认为数百个会更接近。线程现在绝对比以前更可行，但我认为将事件驱动系统视为没有实际意义的做法并不准确。这在很大程度上是将苹果与橙子进行比较，但想象一下线程网络服务器与事件驱动的网络服务器（无论是select 还是其他机制）。您认为哪个会更好地扩展？
在可扩展性方面，每个客户端线程的方法是完全不负责任的。 JVM 线程调度程序并非旨在成为 I/O 就绪通知系统，并且不会为超过几十个客户端提供良好的性能。我认为，如果您计划将服务器扩展到超过 50-100 个客户端并且性能至关重要，那么 NIO 是唯一的选择。它难以使用的事实并不能成为服务器需要适当可伸缩性的借口。 Linux 上的 Selector 实现甚至使用了 epoll 库以实现惊人的性能，从而相对轻松地支持 10,000 多个客户端。