select epoll

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

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

也许在细节方面不是特别恰当，但是总的来说，比较形象地说出了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慢了（就像我们常常说快排比插入排序快，但是在特定情况下这并不成立）。

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在大数据、高并发、集群等一些名词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。

本文便来介绍epoll的实现机制，并附带讲解一下select和poll。通过对比其不同的实现机制，真正理解为何epoll能实现高并发。

select()和poll() IO多路复用模型

select的缺点：

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE    1024)
2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

因此，该epoll上场了。

epoll IO多路复用模型实现机制

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

下面来看看Linux内核具体的epoll机制实现思路。

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

[cpp]  view plain  copy

1. struct eventpoll{  
2.     ....  
3.     /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/  
4.     struct rb_root  rbr;  
5.     /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/  
6.     struct list_head rdlist;  
7.     ....  
8. };  

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

[cpp]  view plain  copy

1. struct epitem{  
2.     struct rb_node  rbn;//红黑树节点  
3.     struct list_head    rdllink;//双向链表节点  
4.     struct epoll_filefd  ffd;  //事件句柄信息  
5.     struct eventpoll *ep;    //指向其所属的eventpoll对象  
6.     struct epoll_event event; //期待发生的事件类型  
7. }  

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

epoll数据结构示意图

从上面的讲解可知：通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。

OK，讲解完了Epoll的机理，我们便能很容易掌握epoll的用法了。一句话描述就是：三步曲。

第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。

第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。

第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。

最后，附上一个epoll编程实例。(作者为sparkliang)

[cpp]  view plain  copy

1. //     
2. // a simple echo server using epoll in linux    
3. //     
4. // 2009-11-05    
5. // 2013-03-22:修改了几个问题，1是/n格式问题，2是去掉了原代码不小心加上的ET模式;  
6. // 本来只是简单的示意程序，决定还是加上 recv/send时的buffer偏移  
7. // by sparkling    
8. //     
9. #include <sys/socket.h>    
10. #include <sys/epoll.h>    
11. #include <netinet/in.h>    
12. #include <arpa/inet.h>    
13. #include <fcntl.h>    
14. #include <unistd.h>    
15. #include <stdio.h>    
16. #include <errno.h>    
17. #include <iostream>    
18. using namespace std;    
19. #define MAX_EVENTS 500    
20. struct myevent_s    
21. {    
22.     int fd;    
23.     void (*call_back)(int fd, int events, void *arg);    
24.     int events;    
25.     void *arg;    
26.     int status; // 1: in epoll wait list, 0 not in    
27.     char buff[128]; // recv data buffer    
28.     int len, s_offset;    
29.     long last_active; // last active time    
30. };    
31. // set event    
32. void EventSet(myevent_s *ev, int fd, void (*call_back)(int, int, void*), void *arg)    
33. {    
34.     ev->fd = fd;    
35.     ev->call_back = call_back;    
36.     ev->events = 0;    
37.     ev->arg = arg;    
38.     ev->status = 0;  
39.     bzero(ev->buff, sizeof(ev->buff));  
40.     ev->s_offset = 0;    
41.     ev->len = 0;  
42.     ev->last_active = time(NULL);    
43. }    
44. // add/mod an event to epoll    
45. void EventAdd(int epollFd, int events, myevent_s *ev)    
46. {    
47.     struct epoll_event epv = {0, {0}};    
48.     int op;    
49.     epv.data.ptr = ev;    
50.     epv.events = ev->events = events;    
51.     if(ev->status == 1){    
52.         op = EPOLL_CTL_MOD;    
53.     }    
54.     else{    
55.         op = EPOLL_CTL_ADD;    
56.         ev->status = 1;    
57.     }    
58.     if(epoll_ctl(epollFd, op, ev->fd, &epv) < 0)    
59.         printf("Event Add failed[fd=%d], evnets[%d]\n", ev->fd, events);    
60.     else    
61.         printf("Event Add OK[fd=%d], op=%d, evnets[%0X]\n", ev->fd, op, events);    
62. }    
63. // delete an event from epoll    
64. void EventDel(int epollFd, myevent_s *ev)    
65. {    
66.     struct epoll_event epv = {0, {0}};    
67.     if(ev->status != 1) return;    
68.     epv.data.ptr = ev;    
69.     ev->status = 0;  
70.     epoll_ctl(epollFd, EPOLL_CTL_DEL, ev->fd, &epv);    
71. }    
72. int g_epollFd;    
73. myevent_s g_Events[MAX_EVENTS+1]; // g_Events[MAX_EVENTS] is used by listen fd    
74. void RecvData(int fd, int events, void *arg);    
75. void SendData(int fd, int events, void *arg);    
76. // accept new connections from clients    
77. void AcceptConn(int fd, int events, void *arg)    
78. {    
79.     struct sockaddr_in sin;    
80.     socklen_t len = sizeof(struct sockaddr_in);    
81.     int nfd, i;    
82.     // accept    
83.     if((nfd = accept(fd, (struct sockaddr*)&sin, &len)) == -1)    
84.     {    
85.         if(errno != EAGAIN && errno != EINTR)    
86.         {    
87.         }  
88.         printf("%s: accept, %d", __func__, errno);    
89.         return;    
90.     }    
91.     do    
92.     {    
93.         for(i = 0; i < MAX_EVENTS; i++)    
94.         {    
95.             if(g_Events[i].status == 0)    
96.             {    
97.                 break;    
98.             }    
99.         }    
100.         if(i == MAX_EVENTS)    
101.         {    
102.             printf("%s:max connection limit[%d].", __func__, MAX_EVENTS);    
103.             break;    
104.         }    
105.         // set nonblocking  
106.         int iret = 0;  
107.         if((iret = fcntl(nfd, F_SETFL, O_NONBLOCK)) < 0)  
108.         {  
109.             printf("%s: fcntl nonblocking failed:%d", __func__, iret);  
110.             break;  
111.         }  
112.         // add a read event for receive data    
113.         EventSet(&g_Events[i], nfd, RecvData, &g_Events[i]);    
114.         EventAdd(g_epollFd, EPOLLIN, &g_Events[i]);    
115.     }while(0);    
116.     printf("new conn[%s:%d][time:%d], pos[%d]\n", inet_ntoa(sin.sin_addr),  
117.             ntohs(sin.sin_port), g_Events[i].last_active, i);    
118. }    
119. // receive data    
120. void RecvData(int fd, int events, void *arg)    
121. {    
122.     struct myevent_s *ev = (struct myevent_s*)arg;    
123.     int len;    
124.     // receive data  
125.     len = recv(fd, ev->buff+ev->len, sizeof(ev->buff)-1-ev->len, 0);      
126.     EventDel(g_epollFd, ev);  
127.     if(len > 0)  
128.     {  
129.         ev->len += len;  
130.         ev->buff[len] = '\0';    
131.         printf("C[%d]:%s\n", fd, ev->buff);    
132.         // change to send event    
133.         EventSet(ev, fd, SendData, ev);    
134.         EventAdd(g_epollFd, EPOLLOUT, ev);    
135.     }    
136.     else if(len == 0)    
137.     {    
138.         close(ev->fd);    
139.         printf("[fd=%d] pos[%d], closed gracefully.\n", fd, ev-g_Events);    
140.     }    
141.     else    
142.     {    
143.         close(ev->fd);    
144.         printf("recv[fd=%d] error[%d]:%s\n", fd, errno, strerror(errno));    
145.     }    
146. }    
147. // send data    
148. void SendData(int fd, int events, void *arg)    
149. {    
150.     struct myevent_s *ev = (struct myevent_s*)arg;    
151.     int len;    
152.     // send data    
153.     len = send(fd, ev->buff + ev->s_offset, ev->len - ev->s_offset, 0);  
154.     if(len > 0)    
155.     {  
156.         printf("send[fd=%d], [%d<->%d]%s\n", fd, len, ev->len, ev->buff);  
157.         ev->s_offset += len;  
158.         if(ev->s_offset == ev->len)  
159.         {  
160.             // change to receive event  
161.             EventDel(g_epollFd, ev);    
162.             EventSet(ev, fd, RecvData, ev);    
163.             EventAdd(g_epollFd, EPOLLIN, ev);    
164.         }  
165.     }    
166.     else    
167.     {    
168.         close(ev->fd);    
169.         EventDel(g_epollFd, ev);    
170.         printf("send[fd=%d] error[%d]\n", fd, errno);    
171.     }    
172. }    
173. void InitListenSocket(int epollFd, short port)    
174. {    
175.     int listenFd = socket(AF_INET, SOCK_STREAM, 0);    
176.     fcntl(listenFd, F_SETFL, O_NONBLOCK); // set non-blocking    
177.     printf("server listen fd=%d\n", listenFd);    
178.     EventSet(&g_Events[MAX_EVENTS], listenFd, AcceptConn, &g_Events[MAX_EVENTS]);    
179.     // add listen socket    
180.     EventAdd(epollFd, EPOLLIN, &g_Events[MAX_EVENTS]);    
181.     // bind & listen    
182.     sockaddr_in sin;    
183.     bzero(&sin, sizeof(sin));    
184.     sin.sin_family = AF_INET;    
185.     sin.sin_addr.s_addr = INADDR_ANY;    
186.     sin.sin_port = htons(port);    
187.     bind(listenFd, (const sockaddr*)&sin, sizeof(sin));    
188.     listen(listenFd, 5);    
189. }    
190. int main(int argc, char **argv)    
191. {    
192.     unsigned short port = 12345; // default port    
193.     if(argc == 2){    
194.         port = atoi(argv[1]);    
195.     }    
196.     // create epoll    
197.     g_epollFd = epoll_create(MAX_EVENTS);    
198.     if(g_epollFd <= 0) printf("create epoll failed.%d\n", g_epollFd);    
199.     // create & bind listen socket, and add to epoll, set non-blocking    
200.     InitListenSocket(g_epollFd, port);    
201.     // event loop    
202.     struct epoll_event events[MAX_EVENTS];    
203.     printf("server running:port[%d]\n", port);    
204.     int checkPos = 0;    
205.     while(1){    
206.         // a simple timeout check here, every time 100, better to use a mini-heap, and add timer event    
207.         long now = time(NULL);    
208.         for(int i = 0; i < 100; i++, checkPos++) // doesn't check listen fd    
209.         {    
210.             if(checkPos == MAX_EVENTS) checkPos = 0; // recycle    
211.             if(g_Events[checkPos].status != 1) continue;    
212.             long duration = now - g_Events[checkPos].last_active;    
213.             if(duration >= 60) // 60s timeout    
214.             {    
215.                 close(g_Events[checkPos].fd);    
216.                 printf("[fd=%d] timeout[%d--%d].\n", g_Events[checkPos].fd, g_Events[checkPos].last_active, now);    
217.                 EventDel(g_epollFd, &g_Events[checkPos]);    
218.             }    
219.         }    
220.         // wait for events to happen    
221.         int fds = epoll_wait(g_epollFd, events, MAX_EVENTS, 1000);    
222.         if(fds < 0){    
223.             printf("epoll_wait error, exit\n");    
224.             break;    
225.         }    
226.         for(int i = 0; i < fds; i++){    
227.             myevent_s *ev = (struct myevent_s*)events[i].data.ptr;    
228.             if((events[i].events&EPOLLIN)&&(ev->events&EPOLLIN)) // read event    
229.             {    
230.                 ev->call_back(ev->fd, events[i].events, ev->arg);    
231.             }    
232.             if((events[i].events&EPOLLOUT)&&(ev->events&EPOLLOUT)) // write event    
233.             {    
234.                 ev->call_back(ev->fd, events[i].events, ev->arg);    
235.             }    
236.         }    
237.     }    
238.     // free resource    
239.     return 0;    
240. }   

POSIX

同步IO、异步IO、阻塞IO、非阻塞IO，这几个词常见于各种各样的与网络相关的文章之中，往往不同上下文中它们的意思是不一样的，以致于我在很长一段时间对此感到困惑，所以想写一篇文章整理一下。

POSIX(可移植操作系统接口)把同步IO操作定义为导致进程阻塞直到IO完成的操作，反之则是异步IO

按POSIX的描述似乎把同步和阻塞划等号，异步和非阻塞划等号，但是为什么有的人说同步IO不等于阻塞IO呢？先来说说几种常见的IO模型吧。

IO模型

这里统一使用Linux下的系统调用recv作为例子，它用于从套接字上接收一个消息，因为是一个系统调用，所以调用时会从用户进程空间切换到内核空间运行一段时间再切换回来。默认情况下recv会等到网络数据到达并且复制到用户进程空间或者发生错误时返回，而第4个参数flags可以让它马上返回。

• 阻塞IO模型

使用recv的默认参数一直等数据直到拷贝到用户空间，这段时间内进程始终阻塞。A同学用杯子装水，打开水龙头装满水然后离开。这一过程就可以看成是使用了阻塞IO模型，因为如果水龙头没有水，他也要等到有水并装满杯子才能离开去做别的事情。很显然，这种IO模型是同步的。

• 非阻塞IO模型

改变flags，让recv不管有没有获取到数据都返回，如果没有数据那么一段时间后再调用recv看看，如此循环。B同学也用杯子装水，打开水龙头后发现没有水，它离开了，过一会他又拿着杯子来看看……在中间离开的这些时间里，B同学离开了装水现场(回到用户进程空间)，可以做他自己的事情。这就是非阻塞IO模型。但是它只有是检查无数据的时候是非阻塞的，在数据到达的时候依然要等待复制数据到用户空间(等着水将水杯装满)，因此它还是同步IO。

• IO复用模型

这里在调用recv前先调用select或者poll，这2个系统调用都可以在内核准备好数据(网络数据到达内核)时告知用户进程，这个时候再调用recv一定是有数据的。因此这一过程中它是阻塞于select或poll，而没有阻塞于recv，有人将非阻塞IO定义成在读写操作时没有阻塞于系统调用的IO操作(不包括数据从内核复制到用户空间时的阻塞，因为这相对于网络IO来说确实很短暂)，如果按这样理解，这种IO模型也能称之为非阻塞IO模型，但是按POSIX来看，它也是同步IO，那么也和楼上一样称之为同步非阻塞IO吧。

这种IO模型比较特别，分个段。因为它能同时监听多个文件描述符(fd)。这个时候C同学来装水，发现有一排水龙头，舍管阿姨告诉他这些水龙头都还没有水，等有水了告诉他。于是等啊等(select调用中)，过了一会阿姨告诉他有水了，但不知道是哪个水龙头有水，自己看吧。于是C同学一个个打开，往杯子里装水(recv)。这里再顺便说说鼎鼎大名的epoll(高性能的代名词啊)，epoll也属于IO复用模型，主要区别在于舍管阿姨会告诉C同学哪几个水龙头有水了，不需要一个个打开看(当然还有其它区别)。

• 信号驱动IO模型

通过调用sigaction注册信号函数，等内核数据准备好的时候系统中断当前程序，执行信号函数(在这里面调用recv)。D同学让舍管阿姨等有水的时候通知他(注册信号函数)，没多久D同学得知有水了，跑去装水。是不是很像异步IO？很遗憾，它还是同步IO(省不了装水的时间啊)。

• 异步IO模型

调用aio_read，让内核等数据准备好，并且复制到用户进程空间后执行事先指定好的函数。E同学让舍管阿姨将杯子装满水后通知他。整个过程E同学都可以做别的事情(没有recv)，这才是真正的异步IO。

总结

IO分两阶段：

1.数据准备阶段
2.内核空间复制回用户进程缓冲区阶段

一般来讲：阻塞IO模型、非阻塞IO模型、IO复用模型(select/poll/epoll)、信号驱动IO模型都属于同步IO，因为阶段2是阻塞的(尽管时间很短)。只有异步IO模型是符合POSIX异步IO操作含义的，不管在阶段1还是阶段2都可以干别的事。