select poll epoll 区别

在前面几天，我们分别写了基于select ， poll，  epoll三种简单的服务器(没看过的读者可以先去看看)，然而，此时会不会有人问，既然是实现同一种功能，为什么要用不用的函数呢？

首先，来看看select

select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低。

select() 对于超时值提供了更好的精度：微秒，而poll是毫秒.

接下来是 poll

poll() 不要求开发者计算最大文件描述符加一的大小。
poll() 在应付大数目的文件描述符的时候速度更快，因为对于select()来说内核需要检查大量描述符对应的fd_set 中的每一个比特位，比较费时。
select 可以监控的文件描述符数目是固定的，相对来说也较少（1024或2048），如果需要监控数值比较大的文件描述符，就算所监控的描述符很少，如果分布的很稀疏也会效率很低，对于poll() 函数来说，就可以创建特定大小的数组来保存监控的描述符，而不受文件描述符值大小的影响，而且poll()可以监控的文件数目远大于select。
对于select来说，所监控的fd_set在select返回之后会发生变化，所以在下一次进入select()之前都需要重新初始化需要监控的fd_set，poll() 函数将监控的输入和输出事件分开，允许被监控的文件数组被复用而不需要重新初始化。
select() 函数的超时参数在返回时也是未定义的，考虑到可移植性，每次在超时之后在下一次进入到select之前都需要重新设置超时参数。

对于poll来说需要将用户传入的 pollfd 数组拷贝到内核空间，因为拷贝操作和数组长度相关，时间上这是一个O（n）操作，当事件发生，poll返回将获得的数据传送到用户空间并执行释放内存和剥离等待队列等善后工作，向用户空间拷贝数据与剥离等待队列等操作的的时间复杂度同样是O（n）

在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一 个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知。


epoll的优点主要是一下几个方面：
1. 监视的描述符数量不受限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。select的最大缺点就是进程打开的fd是有数量限制的。这对 于连接数量比较大的服务器来说根本不能满足。虽然也可以选择多进程的解决方案( Apache就是这样实现的)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也 不是一种完美的方案。


2. IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。

3.支持电平触发和边沿触发（只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发）两种方式，理论上边缘触发的性能要更高一些，但是代码实现相当复杂。


4.mmap加速内核与用户空间的信息传递。epoll是通过内核于用户空间mmap同一块内存，避免了无畏的内存拷贝。

select、poll、epoll_wait性能对比
select、poll的内部实现机制相似，性能差别主要在于向内核传递参数以及对fdset的位操作上，另外，select存在描述符数的硬限制，不能处理很大的描述符集合。这里主要考察poll与epoll在不同大小描述符集合的情况下性能的差异。


测试程序会统计在不同的文件描述符集合的情况下，1s内poll与epoll调用的次数。统计结果如下，从结果可以看出，对poll而言，每秒钟内的系统调用数目虽集合增大而很快降低，而epoll基本保持不变，具有很好的扩展性。