select epoll poll的区别

其实总体上说，三者都是用于IO多路复用的机制。

IO多路复用就是通过一种机制，可以监视多个描述符，一旦某一个描述符就绪了（读就绪or写就绪），能够通知程序进行相应的读写操作。

三者本质上都是同步IO，都是在读写事件就绪之后自己进行读写（异步是内核执行读写操作之后通知程序拿数据，将数据从内核拷贝到用户空间即可，），也就是说读写过程其实是阻塞的。

先说一下整个结论：select和poll差不多，只不过一个文件描述符集是d_set;另一个是pollfd。poll对于fd的数量没有限制。两者每次调用都需要拷贝一次fd_set（pollfd），且内核需要遍历所有的fd_set，效率很低 开销很大。
epoll通过epoll_ctl使得每一次注册新事件时拷贝一次所有的fd；epoll_wait只需要轮询一个就绪队列是否为空（因为epoll采用了回调机制，将就绪的fd插入到就绪队列中），所以不用轮询整个fd_set。

epoll其实是在内核 中维持了一个fd的列表，而select和poll是将该列表维持在用户态，然后传递到内核中。

综上，epoll更适合处理大量的fd且活跃fd不是很多的情况。

“epoll模式在操作中获得就绪的文件描述符时，返回的不是实际的文件描述符，而是一个代表就绪文件描述符的值，然后在文件描述符数组中查询对应的的文件描述符。这样避免系统调用时候在内存中数据结构复制的开销。“

三者的比较

select

1. 首先 select，其实就是有长度限制的 从用户空间拷贝fd_set到内核空间之后，遍历所有的fd（文件描述符），调用其对应的poll方法，返回一个描述读写操作是否就绪的mask掩码，根据该掩码给fd_set赋值；
2. 遍历完all fd之后若还没有返回一个可读写的mask掩码，则会调用schedule_timeout使得调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。
3. 最后把fd_set从内核空间拷贝到用户空间。

select最早于1983年出现在4.2BSD中，它通过一个select()系统调用来监视多个文件描述符的数组，当select()返回后，该数组中就绪的文件描述符便会被内核修改标志位，使得进程可以获得这些文件描述符从而进行后续的读写操作。

select其实有几个缺点：

1. 每次调用select，都要fd_set从用户态拷贝到内核态，这个开销在fd很多的时候就很大；
2. 同样的，每次调用select都需要在内核中遍历all fd，开销也很大；
3. 还有就是select支持的文件描述符数量太小了。默认是1024。

1024 why？：：select的本质是采用32个整数的32位，即3232= 1024来标识，fd值为1-1024。当fd的值超过1024限制时，就必须修改FD_SETSIZE的大小。这个时候就可以标识32max值范围的fd。

select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，事实上从现在看来，这也是它所剩不多的优点之一。

poll

然后 poll。他其实实现跟select很相似，只是描述fd集合的方式不同，poll使用的pollfd结构，（select使用的是fd_set结构）。

poll对于文件描述发（fd）的数量没有限制（select限制是1024）。

因为poll一次在内核中申请4K（一个页的大小来存放fd），尽量控制在4K以内

水平触发

另外，select()和poll()将就绪的文件描述符告诉进程后，如果进程没有对其进行IO操作，那么下次调用select()和poll()的时候将再次报告这些文件描述符，所以它们一般不会丢失就绪的消息，这种方式称为水平触发（Level Triggered）。

epoll

最后，高效的epoll。他的主要特点在于epoll提供了三个函数（poll和select都是只有一个poll函数/select函数）：epoll_create,epoll_ctl和epoll_wait。
epoll_create是创建一个epoll句柄；
epoll_ctl是注册要监听的事件类型；
epoll_wait则是等待事件的产生。

对于select中提到的三个缺点，epoll中的改进是：

1. 对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

2. 对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。

3. 对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

epoll可以同时支持水平触发和边缘触发（Edge Triggered，只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发），理论上边缘触发的性能要更高一些，但是代码实现相当复杂。

epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。

另一个本质的改进在于epoll采用基于事件的就绪通知方式。在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。
 

总结

（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

epoll比select和poll高效的原因主要有两点：

1. 减少了用户态和内核态之间的文件描述符拷贝
2. 减少了对就绪文件描述符的遍历

epoll的优点：

1. 支持一个进程打开大数目的socket描述符(FD)
   select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

2. IO效率不随FD数目增加而线性下降
   传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对**"活跃"的socket**进行操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

3. 使用mmap加速内核与用户空间的消息传递。
   这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工 mmap这一步的。

4. 内核微调
   这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小— 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构

资料：
https://blog.youkuaiyun.com/hust_dxxxd/article/details/50906149
https://blog.youkuaiyun.com/fdgyfghh/article/details/83926265