为什么人们总是认为epoll 效率比select高！！！！！！-CFANZ编程社区

　　今天看公司代码时，发现代码里面都是使用epoll，有的备注 epoll 效率比poll 高！！！

　　所以就得说一说了；宏观看一看epoll 和select的实现：

select原理概述

调用select时，会发生以下事情：

从用户空间拷贝fd_set到内核空间；
注册回调函数__pollwait；
遍历所有fd，对全部指定设备做一次poll（这里的poll是一个文件操作，它有两个参数，一个是文件fd本身，一个是当设备尚未就绪时调用的回调函数__pollwait，这个函数把设备自己特有的等待队列传给内核，让内核把当前的进程挂载到其中）；
当设备就绪时，设备就会唤醒在自己特有等待队列中的【所有】节点，于是当前进程就获取到了完成的信号。poll文件操作返回的是一组标准的掩码，其中的各个位指示当前的不同的就绪状态（全0为没有任何事件触发），根据mask可对fd_set赋值；
如果所有设备返回的掩码都没有显示任何的事件触发，就去掉回调函数的函数指针，进入有限时的睡眠状态，再恢复和不断做poll，再作有限时的睡眠，直到其中一个设备有事件触发为止。
只要有事件触发，系统调用返回，将fd_set从内核空间拷贝到用户空间，回到用户态，用户就可以对相关的fd作进一步的读或者写操作了。

epoll原理概述

调用epoll_create时，做了以下事情：

内核帮我们在epoll文件系统里建了个file结点；
在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket；
建立一个list链表，用于存储准备就绪的事件。

调用epoll_ctl时，做了以下事情：

把socket放到epoll文件系统里file对象对应的红黑树上；
给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。

调用epoll_wait时，做了以下事情：

观察list链表里有没有数据。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已。

select缺点:

最大并发数限制：使用32个整数的32位，即32*32=1024来标识fd，虽然可修改，但是有以下第二点的瓶颈；
效率低：每次都会线性扫描整个fd_set，集合越大速度越慢；
内核/用户空间内存拷贝问题。

epoll的提升：

本身没有最大并发连接的限制，仅受系统中进程能打开的最大文件数目限制；
效率提升：只有活跃的socket才会主动的去调用callback函数；
省去不必要的内存拷贝：epoll通过内核与用户空间mmap同一块内存实现。

　　假设现在有1024个fd ； select 和epoll 都同时维护他，假设这些fd 都是活跃的，这种情况下，select一次扫描可以扫描1024个fd，空闲的fd很少，

但是epoll 就有可能不一样了， epoll 是先注册等待回调，有可能出现1024次回调；

　　这样的情况下，要是说epoll 效率比select 高-----这就不好说了！！！！！！！！

　　如果select 和epoll 同时维护1024个fd ，但是每次只有一个fd有事件，这种情况下 select 每次都会扫描所有的fd，对比于epoll 每次只有一个fd 回调。 select 做了很多无用功，此时应该epoll的效率高吧！！

　　或者在短连接多的时候，一个连接使用epoll 会触发epoll_ctrl_add/del 两次系统调用，但是select 只有一次扫描，此时也许select 效率性能更高。

高并发，且任一时间只有少数socket是活跃的。如果在并发量低，socket都比较活跃的情况下，select就不见得比epoll慢了

　　所以 I/O复用模型要根据业务需求来选择，技术只有合适的技术-----------------------

终于找到这张神图了

https://libevent.org/

The benchmark measures how long it takes to serve one hundred active connections that chain writes to new connections until thousand writes and reads have happened. It exercises the event loop several times.