Netty权威指南之I/O多路复用技术

2019独角兽企业重金招聘Python工程师标准>>>

    目前支持I/O多了复用的系统调用有select、pselect、poll、epoll，在linux网络编程中，很长一段时间都使用select做轮询和网络事件通知，然而select的一些固有缺陷导致了他的应用受到了很大的限制，最终linux不得不在新的内核中寻找select的替代方案，最终选择了epoll。epoll与select的原理比较类似，为了克服select的缺点，epoll做了很多重大改进：

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

    select的最大缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024。对于那些需要支持上万个TCP连接的大型服务器来说显然太少了。epoll并没有这个限制，它所支持的FD上线是操作系统的最大文件句柄数，远超过1024。

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

    传统的select/poll另一个致命的弱点是当你拥有一个很到的socket集合，由于网络延迟或者链路空闲，任一时刻只有少部分的socket是活跃的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。epoll不存在这个问题，它只是对活跃的socket进行操作，这是因为在内核的实现中epoll是根据每个fd上面的callback函数实现的，那么只有活跃的socket才会主动的去调用callback函数，其他idle状态的socket则不会。

• 3，使用mmap加速内核与用户控件的消息传递。

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

• 4，epoll的API更加简单。

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

    值得说明的是，用来克服select/poll缺点的方法不只有epoll，epoll只是一种linux的实现方案。在freeBSD下有kqueue，而dev/poll是最古老的的Solaris的方案，使用难度依次递增。

转载于:https://my.oschina.net/stefanzhlg/blog/377920