Select,poll,epoll的区别

发表于

在多路复用的IO的模型中，存在三种机制，分别是select，poll和epoll.为了便于理解，可以使用简单的伪代码来表示一个原始的IO的读写：

1
2
3
4
5
6
7
8
9
10
while(true)  
{  
     for(Stream i: streamArr)  
     {  
          if(i.isNotReady()){
               continue;
          }
          doSomething();
     }  
}

select

时间复杂度O(n),它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。 具体的伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
while(true)  
{  
     getSelectReadyStream();//此处是同步方法，如果有准备好的数据才会向下走。
     for(Stream i: streamArr)  
     {  
          if(i.isNotReady()){
               continue;
          }
          doSomething();
     }  
}

select的缺点：

（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大

（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大

（3）select支持的文件描述符数量太小了，默认是1024

poll

时间复杂度O(n),poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态， 但是它没有最大连接数的限制，原因是它是基于链表来存储的.而select是基于set的数据结构。

epoll

时间复杂度O(1),epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)） ，具体的伪代码如下： 

1
2
3
4
5
6
7
8
9
while(true)  
{  
     streamArr=getEpollReadyStream();//此处是同步方法，如果有准备好的数据才会向下走。
     for(Stream i: streamArr)  
     {  
          //此处返回的数据都是已经准备好的数据
          doSomething();
     }  
}

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。
而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。

虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合.

而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善

select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。