Netty 权威指南：I-O- 多路复用技术，java 技术点总结

1.支持一一个进程打开的 socket 描述符( FD)不受限制(仅受限于操作系统的最大文件句柄数)。

select 最大的缺陷就是单个进程所打开的 FD 是有一定限制的，它由FD_ SETSIZE设置，默认值是 1024。 对于那些需要支持上万个 TCP 连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核，不过这会带来网络效率的下降。我们也可以通过选择多进程的方案(传统的 Apache 方案)解决这个问题，不过虽然在 Linux 上创建进程的代价比较小，但仍旧是不可忽视的。另外，进程间的数据交换非常麻烦，对于 Java 来说，由于没有共享内存，需要通过Socket通信或者其他方式进行数据同步，这带来了额外的性能损耗，增

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

加了程序复杂度，所以也不是一种完美的解决方案。值得庆幸的是，epoll 并没有这个限制，它所支持的FD上限是操作系统的最大文件句柄数，这个数字远远大于 1024。例如，在 1GB 内存的机器，上大约是 10 万个句柄左右，具体的值可以通过cat./proc/sys/fs/file-max察看，通常情况下这个值跟系统的内存关系比较大。

2.I/O 效率不会随着 FD 数目的增加而线性下降。

传统select/poll的另一个致命弱点，就是当你拥有一个很大的socket集合时，由于网络延时或者链路空闲，任一时刻只有少部分的socket是“活跃”的，但是select/poll 每次调用都会线性扫描全部的集合，导致效率呈现线性下降。epoll不存在这个问题，它只会对“活跃”的socket进行操作一这是因为在内核实现中，epoll是根据每个 fd 上面的callback函数实现的。那么，只有“活跃”的socket才会去主动调用callback函数，其他 idle 状态的socket则不会。在这点上，epoll 实现了一个伪 AIO。针对epoll 和select性能对比的benchmark测试表明：如果所有的socket都处于活跃态一例如一一个高速 LAN 环境，epoll并不比select/poll效率高太多；相反，如果过多使用epoll_ctl，效率相比还有稍微地降低。但是一旦使用idleconnections模拟 WAN 环境，epoll 的效率就远在select/poll之上了。

3.使用 mmap 加速内核与用户空间的消息传递。

无论是select、poll还是epoll都需要内核把 FD 消息通知给用户空间，如何避免不必要的内存复制就显得非常重要，epoll是通过内核和用户空间mmap同一块内存来实现的。

4.epoll 的 API 更加简单。

包括创建一个epoll描述符、添加监听事件、阻塞等待所监听的事件发生、关闭epoll描述符等。

值得说明的是，用来克服select/poll缺点的方法不只有 epoll, epoll 只是一种 Linux 的实现方案。在freeBSD下有kqueue，而dev/poll是最古老的 Solaris 的方案，使用难度依次递增。kqueue 是 freebsd 的宠儿，它实际上是一个功能相当丰富的 kernel 事件队列，它不仅仅是select/poll的升级，而且可以处理 signal、目录结构变化、进程等多种事件。kqueue 是边缘触发的。/dev/poll 是 Solaris 的产物，是这一系列高性能 API 中最早出现的。Kernel 提供了一个特殊的设备文件/dev/poll，应用程序打开这个文件得到操作fd_ set 的句柄，通过写入pollfd来修改它，一个特殊的ioctl调用用来替换 select。不过由于出现的年代比较早，所以/dev/poll的接口实现比较原始。

从 BIO 到 NIO 是 Java 通信类库迈出的一小步，但却对 Java 在高性能通信领域的发展起到了关键性的推动作用。随着基于 NIO 的各类 NIO 框架的发展，以及基于 NIO 的 Web 服务器的发展，Java 在很多领域取代了 C 和 C++，成为企业服务端应用开发的首选语言。