select poll 与epoll模型的总结

select()和poll() IO多路复用模型

select优点：
1.一次可以等待多个文件描述符，减少了平均等待时间
2.客户越来越多时，减轻了进程调度的压力（相较于多进程多线程服务器）
select缺点：
1.能监听的文件描述符有上限，这个上限是由fd_set决定的。
2.它返回的只是就绪事件的个数，要判断是那个事件满足，需要遍历文件描述符。
3.select监听的集合是输入输出参数，每次监听都需要重新初始化。
4.每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
5.内核采用轮询（遍历fd集合）的方式来检测就绪事件，这个开销在fd很多时也很大
6.select和poll都只能工作在低效的LT（水平触发）模式
poll优点：
1.poll监听的文件描述符没有最大数量的限制
2.poll对于select来说包含了一个pollfd结构，pollfd结构包含了要监视的event和发生的revent，而不像select那样使用输入输出的传递方式。所以不需要每次监听都初始化
poll缺点：
1.数量过大以后其效率也会线性下降。
2.poll和select一样也是返回就绪事件的个数，需要遍历文件描述符来判断是那个事件已经就绪，当数量很大时，开销也就很大。
3.select和poll都只能工作在低效的LT（水平触发）模式
4.每次调用poll，都需要把pollfd数组从用户态拷贝到内核态，这个开销在fd很多时会很大
5.内核采用轮询（遍历pollfd数组）的方式来检测就绪事件，这个开销在fd很多时也很大

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

因此，该epoll上场了。

epoll IO多路复用模型实现机制

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？红黑树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

下面来看看linux内核具体的epoll机制实现思路。

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

[cpp]  view plain  copy

1. struct eventpoll{  
2.     ....  
3.     /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/  
4.     struct rb_root  rbr;  
5.     /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/  
6.     struct list_head rdlist;  
7.     ....  
8. };  

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

[cpp]  view plain  copy

1. struct epitem{  
2.     struct rb_node  rbn;//红黑树节点  
3.     struct list_head    rdllink;//双向链表节点  
4.     struct epoll_filefd  ffd;  //事件句柄信息  
5.     struct eventpoll *ep;    //指向其所属的eventpoll对象  
6.     struct epoll_event event; //期待发生的事件类型  
7. }  

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

epoll数据结构示意图

从上面的讲解可知：通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。

OK，讲解完了Epoll的机理，我们便能很容易掌握epoll的用法了。一句话描述就是：三步曲。

第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。

第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。

第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。

epoll优点：
1.epoll维护的描述符数目不受到限制，而且性能不会随着描述符数目的增加而下降。(不需要遍历整个文件描述符)
2.epoll先通过epoll_ctl注册一个描述符到内核中，并一直维护着而不像poll每次操作都将所有要监控的描述符传递给内核
3.在描述符读写就绪时，通过回掉函数将自己加入就绪队列中，之后epoll_wait返回该就绪队列,所以用户不需要遍历整个文件描述符判断哪些事件就绪。性能提升。
4.支持ET高效模式。

poll和select适用于关心描述符个数多的应用程序。其中epoll对于每次只有很少描述符就绪很有优势（采用回调机制监测描述符就绪）。