为什么人们总是认为epoll 效率比select高！！！！！！

　　今天看公司代码时，发现代码里面使用的事清一色的代码使用epoll，

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

select原理概述

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

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

epoll原理概述

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

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

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

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

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

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

select缺点:

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

epoll的提升：

1. 本身没有最大并发连接的限制，仅受系统中进程能打开的最大文件数目限制；
2. 效率提升：只有活跃的socket才会主动的去调用callback函数；
3. 省去不必要的内存拷贝：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复用模型 要根据业务需求来选择，技术只有合适的技术-----------------------

终于找到这张神图了