epoll比select和poll高效的缘由

咱们经过比较select、poll和epoll处理I/O的过程来剖析其中的缘由：
1. 用户态将文件描述符传入内核的方式：
select：建立3个文件描述符集并拷贝到内核中,分别监听读、写、异常动做。这里受到单个进程能够打开的fd数量限制,默认是1024。 
poll：将传入的struct pollfd结构体数组拷贝到内核中进行监听。 
epoll：执行epoll_create会在内核的高速cache区中创建一颗红黑树以及就绪链表(该链表存储已经就绪的文件描述符)。接着用户执行的epoll_ctl函数添加文件描述符会在红黑树上增长相应的结点。

2. 内核态检测文件描述符是否可读可写的方式：
select：采用轮询方式,遍历全部fd,最后返回一个描述符读写操做是否就绪的mask掩码,根据这个掩码给fd_set赋值。 
poll：一样采用轮询方式,查询每一个fd的状态,若是就绪则在等待队列中加入一项并继续遍历。 
epoll：采用回调机制。在执行epoll_ctl的add操做时,不只将文件描述符放到红黑树上,并且也注册了回调函数,内核在检测到某文件描述符可读/可写时会调用回调函数,该回调函数将文件描述符放在就绪链表中。

3. 如何找到就绪的文件描述符并传递给用户态：
select：将以前传入的fd_set拷贝传出到用户态并返回就绪的文件描述符总数。用户态并不知道是哪些文件描述符处于就绪态,须要遍从来判断。 
poll：将以前传入的fd数组拷贝传出用户态并返回就绪的文件描述符总数。用户态并不知道是哪些文件描述符处于就绪态,须要遍从来判断。 
epoll：epoll_wait只用观察就绪链表中有无数据便可,最后将链表的数据返回给数组并返回就绪的数量。内核将就绪的文件描述符放在传入的数组中,因此只用遍历依次处理便可。这里返回的文件描述符是经过mmap让内核和用户空间共享同一块内存实现传递的,减小了没必要要的拷贝。

4. 继续从新监听时如何重复以上步骤：
select：将新的监听文件描述符集合拷贝传入内核中,继续以上步骤。 
poll：将新的struct pollfd结构体数组拷贝传入内核中,继续以上步骤。 
epoll：无需从新构建红黑树,直接沿用已存在的便可。

经过以上步骤咱们能够发现如下几点：
select和poll的动做基本一致,只是poll采用链表来进行文件描述符的存储,而select采用fd标注位来存放,因此select会受到最大链接数的限制,而poll不会。
select、poll、epoll虽然都会返回就绪的文件描述符数量。可是select和poll并不会明确指出是哪些文件描述符就绪,而epoll会。形成的区别就是,系统调用返回后,调用select和poll的程序须要遍历监听的整个文件描述符找到是谁处于就绪,而epoll则直接处理就好了。
select、poll都须要将有关文件描述符的数据结构拷贝进内核,最后再拷贝出来。而epoll建立的有关文件描述符的数据结构自己就存于内核态中,系统调用返回时也采用mmap共享存储区,须要拷贝的次数大大减小。
select、poll采用轮询的方式来检查文件描述符是否处于就绪态,而epoll采用回调机制。形成的结果就是,随着fd的增长,select和poll的效率会线性下降,而epoll不会受到太大影响,除非活跃的socket不少。
最后总结一下,epoll比select和poll高效的缘由主要有两点： 
1. 减小了用户态和内核态之间的文件描述符拷贝 
2. 减小了对就绪文件描述符的遍历
--------------------- 
做者：Move_now 
来源：CSDN 
原文：https://blog.csdn.net/Move_now/article/details/71773965 
版权声明：本文为博主原创文章，转载请附上博文连接！