select、poll和epoll的比较

一、select机制

　　在linux下网络通信中，经常用到select机制，这是一种异步通信的实现方式，select中提供一fd_set的数据结果，实际上是一个long类型的数组， 每一个数组元素都能与一打开的文件句柄建立联系，通常这个句柄并不局限于网络通信中的socket句柄，还包括其他文件、命名管道或设备句柄等。当程序中调用select()时，由内核根据IO状态修改fd_set的内容，由此来通知执select()的进程哪一Socket或文件可读或者可写。

　　select的本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

　　1、单个进程可监视的fd数量受到了限制，在32位机器上，他所能管理的fd数量最大为1024。

　　2、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。

　　3、对socket进行扫描时是线性扫描，当socket文件描述符数量变多时，大量的时间是被白白浪费掉的。

二、poll机制

　　poll是Linux中的字符设备驱动中有一个函数，Linux 2.5.44版本后已经被epoll所取代。poll机制是用在某些Unix系统中，使用poll()函数用于执行与select()函数同等功能的函数。

　　poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

　　相比于select机制，poll机制采用链表来进行文件描述符的存储，因此它并没有最大连接数的限制，但同样存在一些缺点：

　　1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。

　　2、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

三、epoll机制

　　epoll是Linux内核为处理大批量的句柄而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

　　epoll会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合，另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的电平触发（Level Triggered）外，还提供了边沿触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

　　相比于poll机制，epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次。在fd的数组在用户态和内核地址空间之间复制的问题上，epoll使用mmap减少复制开销。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

四、select、poll与epoll的比较

　　1、支持一个进程所能管理的最大连接数

　　2、文件描述符剧增后带来的IO效率问题

　　3、消息传递的方式

　　综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点，epoll的性能最好。但是考虑到在连接数少并且连接都十分活跃的情况下，select和poll的性能可能会比epoll更好，毕竟epoll的通知机制需要很多函数回调。