一、关于select,poll,epoll

三种IO模型，都属于多路IO就绪通知，提供了对大量文件描述符就绪检查的高性能方案，只不过实现方式有所不同：

select原理概述：

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

1. （1）从用户空间拷贝fd_set到内核空间；
2. （2）注册回调函数__pollwait；
3. （3）遍历所有fd，对全部指定设备做一次poll（这里的poll是一个文件操作，它有两个参数，一个是文件fd本身，一个是当设备尚未就绪时调用的回调函数__pollwait，这个函数把设备自己特有的等待队列传给内核，让内核把当前的进程挂载到其中）；
4. （4）当设备就绪时，设备就会唤醒在自己特有等待队列中的【所有】节点，于是当前进程就获取到了完成的信号。poll文件操作返回的是一组标准的掩码，其中的各个位指示当前的不同的就绪状态（全0为没有任何事件触发），根据mask可对fd_set赋值；
5. （5）如果所有设备返回的掩码都没有显示任何的事件触发，就去掉回调函数的函数指针，进入有限时的睡眠状态，再恢复和不断做poll，再作有限时的睡眠，直到其中一个设备有事件触发为止。
6. 只要有事件触发，系统调用返回，将fd_set从内核空间拷贝到用户空间，回到用户态，用户就可以对相关的fd作进一步的读或者写操作了。
7. 一个select()系统调用来监视包含多个文件描述符的数组，当select返回，该数组中就绪的文件描述符便会被内核修改标志位。
8. select的 跨平台 做的很好，几乎每个平台都支持。
9. select缺点有以下四点：
10. （1）单个进程能够监视的文件描述符的数量存在最大限制
11. （2）select()所维护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长
12. （3）同时每次调用select都需要在内核遍历传递进来所有的fd,这个开销在fd很多时很大。
13. （4）由于网络响应时间的延迟使得大量TCP连接处于非活跃状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会造成一定的开销
14. poll：
15. poll跟select的实现很相似，唯一解决的问题是poll 采用pollfd的结构体指针实现，没有最大文件描述符数量的限制

16. epoll原理概述

17. 调用epoll_create时，做了以下事情：
18. 内核帮我们在epoll文件系统里建了个file结点；
19. 在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket；
20. 建立一个list链表，用于存储准备就绪的事件。
21. 调用epoll_ctl时，做了以下事情：
22. 把socket放到epoll文件系统里file对象对应的红黑树上；
23. 给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。
24. 调用epoll_wait时，做了以下事情：
25. 观察list链表里有没有数据。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已。
26. epoll优点
27. (1)支持一个进程打开大数目的socket描述符(FD)
28. select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你
29. 一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，
30. 二是可以选择多进程的解决方案(传统的Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。
31. epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
32. (2)IO效率不随FD数目增加而线性下降
33. 传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。
34. 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之上了。
35. (3)使用mmap加速内核与用户空间的消息传递
36. 这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工mmap这一步的。
37. (4)内核微调
38. 这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小--- 通过echoXXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。
39. （5）epoll的除了提供select/poll 那种IO事件的电平触发（LevelTriggered）外，还提供了边沿触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。
40. epoll的缺点：
41. 缺点要相对来说  拿目前常见几个网络模型 select IOCP对比来说缺点有以下几个:
    1. 相对select来说, epoll的跨平台性不够用 只能工作在linux下, 而select可以在windows linux  apple上使用, 还有手机端android iOS之类的都可以.android虽然是linux的内核 但早期版本同样不支持epoll的.
    2. 相对select来说 还是用起来还是复杂了一些, 不过和IOCP比起来 增加了一点点的复杂度却基本上达到了IOCP的并发量和性能, 而复杂度远远小于IOCP.

3. 相对IOCP来说 对多核/多线程的支持不够好,  性能也因此在性能要求比较苛刻的情况下不如IOCP.

1. 如果在并发量低，socket都比较活跃的情况下，select就不见得比epoll慢了