为什么epoll比select和poll更高效

  

常见的面试问题之一就是为什么epoll比select和poll高效？本篇就来总结一下它们三者之间的区别~~

一、select、poll、epoll三者的特点及区别

（1）select系统调用

select创建了3个文件描述符集（fd_set）并拷贝到内核中，分别监听读、写、异常动作。select可以监听的文件描述符受到单个进程所能打开的fd的限制，默认为1024.采用轮询方式，遍历所有的fd，最后返回一个文件描述符是否就绪的mask掩码，并根据mask掩码给fd_set赋值。将之前的fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判断。应用程序索引就绪文件描述符的时间复杂度是O(n).再次调用select时，需要将新的fd_set监听文件描述符拷贝传入进内核。select只能工作在相对较低下的LT模式

（2）poll系统调用

将struct pollfd结构体数组拷贝到内核中进行监听。poll采用链表poll_list来进行文件描述符的存储，因此poll可以监听的文件描述符数为系统可以打开的最大文件描述符数（65535）。采用轮询方式，查询每个fd的状态，如果就绪，内核就修改fd对应的revents的值，而events成员保持不变，因此下次调用poll时，应用程序无需重置pollfd类型的事件集参数。将之前传入的struct pollfd结构体数组拷贝传出到用户态，并返回就绪文件描述符的总个数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判读。应用程序索引就绪文件描述符的时间复杂度是O(n).poll只能工作在相对较低下的LT模式。

（3）epoll系统调用

执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符)，监听的文件描述符数为系统可以打开的最大文件描述符数（65535）。接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核，内核会在红黑树上添加相应的结点，并注册回调函数ep_poll_callback()，内核在检测到某文件描述符可读/可写时就调用回调函数callback,该回调函数将文件描述符放入就绪链表rdllist中。epoll_wait()函数只需要观察rdllist中有无就绪的文件描述符即可，内核将就绪的文件描述符事件复制到传入的poll_event结构体数组中返回给用户空间，所以用户只用遍历依次处理即可，即应用程序索引就绪文件描述符的时间复杂度是O（1）。这里返回的文件描述符是通过mmap让内核和用户空间共享同一块内存传递的，减少了不必要的拷贝。再次调用epoll系统调用，不用重建红黑树，直接沿用已经存在的即可。epoll支持ET模式，当内核将该事件通知给用户后，用户必须立即处理，这样就减少了可读、可写和异常事件被触发的次数。

二、为什么epoll比select和poll更高效？

（1）减少了用户态和内核态之间文件描述符的拷贝

select创建了3个文件描述符集（fd_set）并拷贝到内核中，分别监听读、写、异常事件。内核分配相关数据结构（fd_set_bits），内核在检测到有就绪事件后，就修改用户传进来的fd_set的值以告知用户有就绪的文件描述符。将文件描述符fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。内核删除和文件描述符相关的数据结构，由于内核修改了用户传进来的fd_set文件描述符集，下次调用select前必须要重置fd_set，然后重新传给内核，内核在重新拷贝一份，重新分配数据结构。

poll系统调用将struct pollfd结构体数组拷贝到内核中进行监听，内核分配相关数据结构poll_list,用来存储监听的文件描述符，然后调用所有fd对应的poll(将current挂到各个fd对应的设备等待队列上)，内核在检测到有就绪事件后，就修改fd对应的revents的值用来告知用户有就绪的文件描述符，而events成员保持不变，因此下次调用poll时，应用程序无需重置pollfd类型的事件集参数。将之前传入的struct pollfd结构体数组拷贝传出到用户态，并返回就绪文件描述符的总个数。内核删除和文件描述符相关的数据结构，下次调用poll需要将struct pollfd重新传给内核，内核在重新拷贝一份，重新分配数据结构。

执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符)，接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核，内核会在红黑树上添加相应的结点，内核将就绪的文件描述符事件复制到传入的poll_event结构体数组中返回给用户空间，系统调用在返回时采用mmap共享存储区，需要拷贝的次数大大减少。由于epoll创建的有关文件描述符的数据结构本身就存在于内核态中。下一次调用epoll系统调用时，不需要再次拷贝用户空间所要监听的文件描述符，也不需要重新构建红黑树和就绪链表等相关数据结构，直接沿用已经存在的数据结构。

（2）减少了对就绪文件描述符的遍历

select和poll采用轮询的方式来检查文件描述符是否处于就绪状态。并且内核修改用户传进来的fd_set和pollfd结构体的成员的revents值以告知用户有文件描述符就绪，但是用户并不知道有哪些文件描述符处于就绪态，需要遍历查找就绪文件描述符，因此，应用程序索引就绪文件描述符的时间复杂度为O（n）.

而epoll采用回调机制。在调用epoll_ctl时，已经将用户感兴趣的事件传给了内核，内核会维持一个内核事件表，记录用户感兴趣的事件，就绪事件发生时，驱动设备调用回调函数ep_poll_callback()将就绪的fd挂到rdllist上。用户调用epoll_wait时，将rdllist上就绪的文件描述符发送给用户。此时发送给用户的都是就绪的fd。因此，应用程序索引就绪文件描述符的时间复杂度为O（1）。

（3）select和poll只支持LT模式，而epoll支持高效的ET模式，并且epoll还支持EPOLLONESHOT事件。

LT模式（电平触发）：LT模式是默认的工作模式，当检测到文件描述符上有事件发生并将此事件通知给应用程序，应用程序可以不立即处理该事件，下次调用会再次响应应用程序并通知此事件。

ET模式（边沿触发）：当检测到文件描述符上有事件发生并将此事件通知给应用程序，应用程序必须立即处理该事件，如果没处理或者没处理完，下次调用不会再响应应用程序并通知此事件。

ET模式很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高，epoll工作在ET模式的时候，必须使用非阻塞的套接字，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

即使使用ET模式，一个socket上的某个事件还是可能被触发多次，这在并发程序中就会引发一个问题。比如一个线程在读取完某个socket上的数据开始处理这些数据的时候，而在数据的处理过程中这个socket上又有新数据可读，这时另一个线程被唤醒来处理新数据，于是就出现了两个线程同时操作一个socket的局面。因此需要使用epoll的EPOLLONESHOT事件实现。对于注册了EPOLLONESHOT事件的文件描述符，操作系统最多触发其上的一个读、写或异常事件，且只触发一次。当一个线程在处理socket时，其它线程是不可能有机会操作该socket的。注册了EPOLLONESHOT事件的socket一旦被某个线程处理完，该线程就应该立即重置这个socket上的EPOLLONESHOT事件，以确保这个socket下次可读时，其EPOLLIN事件可被触发，进而让其它线程有机会处理这个socket。使用EPOLLONESHOT事件能进一步减少可读、可写和异常事件的被触发的次数。

三、无论哪种情况下，epoll都比select和poll高效吗？

epoll适用于连接较多，活动数量较少的情况。 
(1)epoll为了实现返回就绪的文件描述符，维护了一个红黑树和好多个等待队列，内核开销很大。如果此时监听了很少的文件描述符，底层的开销会得不偿失；

(2)epoll中注册了回调函数，当有事件发生时，服务器设备驱动调用回调函数将就绪的fd挂在rdllist上，如果有很多的活动，同一时间需要调用的回调函数数量太多，服务器压力太大。

select和poll适用于连接较少的情况。 
当select和poll上监听的fd数量较少，内核通知用户现在有就绪事件发生，应用程序判断当前是哪个fd就绪所消耗的时间复杂度就会大大减小。

终于把这个大骨头啃完了→_→*