select和epoll 原理概述&优缺点比较

转自：http://blog.csdn.net/jiange_zh https://blog.csdn.net/jiange_zh/article/details/50811553

这个问题在面试跟网络编程相关的岗位的时候基本都会被问到，刚刚看到一个很好的比喻：

就像收本子的班长，以前得一个个学生地去问有没有本子，如果没有，它还得等待一段时间而后又继续问，现在好了，只走一次，如果没有本子，班长就告诉大家去那里交本子，当班长想起要取本子，就去那里看看或者等待一定时间后离开，有本子到了就叫醒他，然后取走。

也许在细节方面不是特别恰当，但是总的来说，比较形象地说出了select和epoll的区别。

下面我将简单明了地概述下两者的原理，并概况两者的优缺点。

select原理概述

调用select时，会发生以下事情：

1. 从用户空间拷贝fd_set到内核空间；
2. 注册回调函数__pollwait；
3. 遍历所有fd，对全部指定设备做一次poll（这里的poll是一个文件操作，它有两个参数，一个是文件fd本身，一个是当设备尚未就绪时调用的回调函数__pollwait，这个函数把设备自己特有的等待队列传给内核，让内核把当前的进程挂载到其中）；
4. 当设备就绪时，设备就会唤醒在自己特有等待队列中的【所有】节点，于是当前进程就获取到了完成的信号。poll文件操作返回的是一组标准的掩码，其中的各个位指示当前的不同的就绪状态（全0为没有任何事件触发），根据mask可对fd_set赋值；
5. 如果所有设备返回的掩码都没有显示任何的事件触发，就去掉回调函数的函数指针，进入有限时的睡眠状态，再恢复和不断做poll，再作有限时的睡眠，直到其中一个设备有事件触发为止。
6. 只要有事件触发，系统调用返回，将fd_set从内核空间拷贝到用户空间，回到用户态，用户就可以对相关的fd作进一步的读或者写操作了。

epoll原理概述

调用epoll_create时，做了以下事情：

1. 内核帮我们在epoll文件系统里建了个file结点；
2. 在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket；
3. 建立一个list链表，用于存储准备就绪的事件。

调用epoll_ctl时，做了以下事情：

1. 把socket放到epoll文件系统里file对象对应的红黑树上；
2. 给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。

调用epoll_wait时，做了以下事情：

观察list链表里有没有数据。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已。

总结如下：

一颗红黑树，一张准备就绪句柄链表，少量的内核cache，解决了大并发下的socket处理问题。

执行epoll_create时，创建了红黑树和就绪链表； 
执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据; 
执行epoll_wait时立刻返回准备就绪链表里的数据即可。

两种模式的区别：

LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时重复返回这个句柄，而ET模式仅在第一次返回。

两种模式的实现：

当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时我们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后，epoll_wait检查这些socket，如果是LT模式，并且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表。所以，LT模式的句柄，只要它上面还有事件，epoll_wait每次都会返回。

对比

select缺点:

1. 最大并发数限制：使用32个整数的32位，即32*32=1024来标识fd，虽然可修改，但是有以下第二点的瓶颈；
2. 效率低：每次都会线性扫描整个fd_set，集合越大速度越慢；
3. 内核/用户空间内存拷贝问题。

epoll的提升：

1. 本身没有最大并发连接的限制，仅受系统中进程能打开的最大文件数目限制；
2. 效率提升：只有活跃的socket才会主动的去调用callback函数；
3. 省去不必要的内存拷贝：epoll通过内核与用户空间mmap同一块内存实现。

当然，以上的优缺点仅仅是特定场景下的情况：高并发，且任一时间只有少数socket是活跃的。

如果在并发量低，socket都比较活跃的情况下，select就不见得比epoll慢了（就像我们常常说快排比插入排序快，但是在特定情况下这并不成立）。

select和enpoll的应用场景

zhuhttps://blog.csdn.net/D_Guco/article/details/53166722

都知道epoll相对于select模型的优点，它的速度和并发量相对于select明显的优势，但是是不是epoll就可以完全代替select呢，在得出结论之前还是先要看看他们各自的实现原理。

1 select:在网络编程中统一的操作顺序是创建socket－>绑定端口－>监听－>accept->write/read,当有客户端连接到来时,select会把该连接的文件描述符放到fd_set（一组文件描述符(fd)的集合）,然后select会循环遍历它所监测的fd_set内的所有文件描述符，当select循环遍历完所有fd_set内指定的文件描述符对应的poll函数后，如果没有一个资源可用(即没有一个文件可供操作)，则select让该进程睡眠，一直等到有资源可用为止，fd_set是一个类似于数组的数据结构，由于它每次都要遍历整个数组，所有她的效率会随着文件描述符的数量增多而明显的变慢，除此之外在每次遍历这些描述符之前，系统还需要把这些描述符集合从内核copy到用户空间，然后再copy回去，如果此时没有一个描述符有事件发生（例如：read和write）这些copy操作和便利操作都是无用功，可见slect随着连接数量的增多，效率大大降低。可见如果在高并发的场景下select并不适用，况且select默认的最大描述符为1024，如果想要更多还要做响应参数的配置。

2 epoll：说到epoll都夸赞它的效率和并发量，那么她好在哪里呢。首先调用epoll_create时内核帮我们在epoll文件系统里建了个file结点；除此之外在内核cache里建立红黑树[红黑书介绍］(http://www.cnblogs.com/v-July-v/archive/2010/12/29/1983707.html)用于存储以后epoll_ctl传来的socket，当有新的socket连接来时，先遍历红黑书中有没有这个socket存在，如果有就立即返回，没有就插入红黑数，然后给内核中断处理程序注册一个回调函数，每当有事件发生时就通过回调函数把这些文件描述符放到事先准备好的用来存储就绪事件的链表中，调用epoll_wait时，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后检查这些socket。在LT模式下，如果这些socket上确实有未处理的事件时，该句柄会再次被放回到刚刚清空的准备就绪链表，保证所有的事件都得到正确的处理。如果到timeout时间后链表中没有数据也立刻返回。因此在并发需求量高的场景中我们即使要监控数百万计的句柄，大多数一次也只返回很少量的准备就绪句柄。由此可见epoll仅需要从内核态copy少量的句柄到用户态，这样就避免了select模型中的无效便利和用户和内核之间的copy操作。

说道这里，可以看到epoll的优势非常明显，几乎没有描述符数量的限制，并发支持完美，不会随着socket的增加而降低效率，也不用在内核空间和用户空间之间做无效的copy操作。 但是是不是所有的场景都适合epoll呢？看下面的例子。

  一个游戏服务器，tcp server负责接收客户端的连接，dbserver负责处理数据信息，一个webserver负责处理服务器的web请求，gameserver负责游戏的逻辑处理，所有这些服务都和另外一个gateserver相连，gateserver负责服务器间的通信和转发（进程间通信），只要游戏服务器在服务状态，这些连接几乎不会断开（异常情况可能会断开），并且这些连接数量一般不会很多。这种情况，select还是epoll呢？很明显是select，因为每时每刻这些连接的socket都有事件发生（比如：服务期间的心跳信息，还有大型网络游戏的同步信息（一般每秒在20-30次）），最重要的是，这种场景下，并发量也不会很大。如果此时用epoll，为此所建立的文件系统，红黑书和链表对于此来说就是杀鸡用牛刀，效率反而不高。当然这里的tcp server负责大量的客户端的连接，毫无疑问epoll是首选，它接受大量的客户端连接，收到客户端的消息之后把消息转发发给select网络模型的gateserver，gateserver再转发给gameserver进行逻辑处理，最后返回给客户端就over了。因此在如果在并发量低，socket都比较活跃的情况下，select就不见得比epoll慢了(就像我们常常说快排比插入排序快，但是在特定情况下这并不成立)。