作者：京东批发 石向阳

在说IO多路复用模型之前，咱们先来大抵理解下Linux文件系统。在Linux零碎中，不论是你的鼠标，键盘，还是打印机，甚至于连贯到本机的socket client端，都是以文件描述符的模式存在于零碎中，诸如此类，等等等等，所以能够这么说，所有皆文件。来看一下零碎定义的文件描述符阐明：

从下面的列表能够看到，文件描述符0,1,2都曾经被零碎占用了，当系统启动的时候，这三个描述符就存在了。其中0代表规范输出，1代表规范输入，2代表谬误输入。当咱们创立新的文件描述符的时候，就会在2的根底上进行递增。能够这么说，文件描述符是为了治理被关上的文件而创立的零碎索引，他代表了文件的身份ID。对标windows的话，你能够认为和句柄相似，这样就更容易了解一些。

因为网上对linux文件这块的原理形容的文章曾经十分多了，所以这里我不再做过多的赘述，感兴趣的同学能够从Wikipedia翻阅一下。因为这块内容比较复杂，不属于本文遍及的内容，倡议读者另行自研，这里我十分举荐马士兵老师将linux文件系统这块，解说的真的十分好。

select模型

此模型是IO多路复用的最晚期应用的模型之一，距今曾经几十年了，然而当初仍旧有不少利用还在采纳此种形式，可见其长生不老。首先来看下其具体的定义（来源于man二类文档）：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);

这里解释下其具体参数：

参数一：nfds，也即maxfd，最大的文件描述符递增一。这里之所以传最大描述符，为的就是在遍历fd_set的时候，限定遍历范畴。

参数二：readfds，可读文件描述符汇合。

参数三：writefds，可写文件描述符汇合。

参数四：errorfds，异样文件描述符汇合。

参数五：timeout，超时工夫。在这段时间内没有检测到描述符被触发，则返回。

上面的宏解决，能够对fd_set汇合（精确的说是bitmap，一个描述符有变更，则会在描述符对应的索引处理1）进行操作：

FD_CLR(inr fd,fd_set* set) 用来革除形容词组set中相干fd 的位，即bitmap构造中索引值为fd的值置为0。

FD_ISSET(int fd,fd_set *set) 用来测试形容词组set中相干fd 的位是否为真，即bitmap构造中某一位是否为1。

FD_SET（int fd,fd_set*set） 用来设置形容词组set中相干fd的位，行将bitmap构造中某一位设置为1，索引值为fd。

FD_ZERO（fd_set *set） 用来革除形容词组set的全副位，行将bitmap构造全副清零。

首先来看一段服务端采纳了select模型的示例代码：

//创立server端套接字，获取文件描述符    int listenfd = socket(PF_INET,SOCK_STREAM,0);    if(listenfd < 0) return -1;    //绑定服务器    bind(listenfd,(struct sockaddr*)&address,sizeof(address));    //监听服务器    listen(listenfd,5);     struct sockaddr_in client;    socklen_t addr_len = sizeof(client);    //接管客户端连贯    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);    //读缓冲区    char buff[1024];     //读文件操作符    fd_set read_fds;      while(1)    {        memset(buff,0,sizeof(buff));        //留神：每次调用select之前都要从新设置文件描述符connfd，因为文件描述符表会在内核中被批改        FD_ZERO(&read_fds);        FD_SET(connfd,&read_fds);        //留神：select会将用户态中的文件描述符表放到内核中进行批改，内核批改结束后再返回给用户态，开销较大        ret = select(connfd+1,&read_fds,NULL,NULL,NULL);        if(ret < 0)        {            printf("Fail to select!\n");            return -1;        }        //检测文件描述符表中相干申请是否可读        if(FD_ISSET(connfd, &read_fds))        {            ret = recv(connfd,buff,sizeof(buff)-1,0);            printf("receive %d bytes from client: %s \n",ret,buff);        }    }

下面的代码我加了比拟具体的正文了，大家应该很容易看明确，说白了大略流程其实如下：

首先，创立socket套接字，创立结束后，会获取到此套接字的文件描述符。

而后，bind到指定的地址进行监听listen。这样，服务端就在特定的端口启动起来并进行监听了。

之后，利用开启accept办法来监听客户端的连贯申请。一旦有客户端连贯，则将获取到以后客户端连贯的connection文件描述符。

单方建设连贯之后，就能够进行数据互传了。须要留神的是，在循环开始的时候，务必每次都要从新设置以后connection的文件描述符，是因为文件描描述符表在内核中被批改过，如果不重置，将会导致异样的状况。

从新设置文件描述符后，就能够利用select函数从文件描述符表中，来轮询哪些文件描述符就绪了。此时零碎会将用户态的文件描述符表发送到内核态进行调整，行将准备就绪的文件描述符进行置位，而后再发送给用户态的利用中来。

用户通过FD_ISSET办法来轮询文件描述符，如果数据可读，则读取数据即可。

举个例子，假如此时连贯上来了3个客户端，connection的文件描述符别离为 4,8,12，那么其read_fds文件描述符表（bitmap构造）的大抵构造为 00010001000100000....0，因为read_fds文件描述符的长度为1024位，所以最多容许1024个连贯。

而在select的时候，波及到用户态和内核态的转换，所以整体转换形式如下：

所以，综合起来，select整体还是比拟高效和稳固的，然而出现进去的问题也不少，这些问题进一步限度了其性能施展：

  1. 文件描述符表为bitmap构造，且有长度为1024的限度。
  2. fdset无奈做到重用，每次循环必须从新创立。
  3. 频繁的用户态和内核态拷贝，性能开销较大。
  4. 须要对文件描述符表进行遍历，O(n)的轮询工夫复杂度。

poll模型

思考到select模型的几个限度，起初进行了改良，这也就是poll模型，既然是select模型的改进版，那么必定有其亮眼的中央，一起来看看吧。当然，这次咱们仍旧是先翻阅linux man二类文档，因为这是官网的文档，对其有着最为精准的定义。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

其实，从运行机制上说来，poll所做的性能和select是基本上一样的，都是期待并检测一组文件描述符就绪，而后在进行后续的IO解决工作。只不过不同的是，select中，采纳的是bitmap构造，长度限定在1024位的文件描述符表，而poll模型则采纳的是pollfd构造的数组fds，也正是因为poll模型采纳了数组构造，则不会有1024长度限度，使其可能接受更高的并发。

pollfd构造内容如下：

struct pollfd {    int   fd;         /* 文件描述符 */    short events;     /* 关怀的事件 */    short revents;    /* 理论返回的事件 */};

从下面的构造能够看出，fd很显著就是指文件描述符，也就是当客户端连贯上来后，fd会将生成的文件描述符保留到这里；而events则是指用户想关注的事件；revents则是指理论返回的事件，是由零碎内核填充并返回，如果以后的fd文件描述符有状态变动，则revents的值就会有相应的变动。

events事件列表如下：

revents事件列表如下：

从列表中能够看出，revents是蕴含events的。接下来联合示例来看一下：

//创立server端套接字，获取文件描述符    int listenfd = socket(PF_INET,SOCK_STREAM,0);    if(listenfd < 0) return -1;    //绑定服务器    bind(listenfd,(struct sockaddr*)&address,sizeof(address));    //监听服务器    listen(listenfd,5);     struct pollfd pollfds[1];    socklen_t addr_len = sizeof(client);    //接管客户端连贯    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);    //放入fd数组    pollfds[0].fd = connfd;    pollfds[0].events = POLLIN;    //读缓冲区    char buff[1024];     //读文件操作符    fd_set read_fds;      while(1)    {        memset(buff,0,sizeof(buff));        /**         ** SELECT模型专用         ** 留神：每次调用select之前都要从新设置文件描述符connfd，因为文件描述符表会在内核中被批改         ** FD_ZERO(&read_fds);         ** FD_SET(connfd,&read_fds);        ** 留神：select会将用户态中的文件描述符表放到内核中进行批改，内核批改结束后再返回给用户态，开销较大        ** ret = select(connfd+1,&read_fds,NULL,NULL,NULL);        **/        ret = poll(pollfds, 1, 1000);        if(ret < 0)        {            printf("Fail to poll!\n");            return -1;        }        /**         ** SELECT模型专用         ** 检测文件描述符表中相干申请是否可读         ** if(FD_ISSET(connfd, &read_fds))         ** {         **   ret = recv(connfd,buff,sizeof(buff)-1,0);         **   printf("receive %d bytes from client: %s \n",ret,buff);         ** }         **/        //检测文件描述符数组中相干申请        if(pollfds[0].revents & POLLIN){            pollfds[0].revents = 0;            ret = recv(connfd,buff,sizeof(buff)-1,0);            printf("receive %d bytes from client: %s \n",ret,buff);        }    }

因为源码中，我做了比拟具体的正文，同时将和select模型不一样的中央都列了进去，这里就不再具体解释了。总体说来，poll模型比select模型要好用一些，去掉了一些限度，然而依然防止不了如下的问题：

  1. 用户态和内核态仍须要频繁切换，因为revents的赋值是在内核态进行的，而后再推送到用户态，和select相似，整体开销较大。
  2. 仍须要遍历数组，工夫复杂度为O（N）。

epoll模型

如果说select模型和poll模型是晚期的产物，在性能上有诸多不尽人意之处，那么自linux 2.6之后新增的epoll模型，则彻底解决了性能问题，一举使得单机接受百万并发的课题变得极为容易。当初能够这么说，只须要一些简略的设置更改，而后配合上epoll的性能，实现单机百万并发轻而易举。同时，因为epoll整体的优化，使得之前的几个比拟消耗性能的问题不再成为羁绊，所以也成为了linux平台上进行网络通讯的首选模型。

解说之前，还是linux man文档镇楼：linux man epoll 4类文档 linux man epoll 7类文档，俩文档联合着读，会对epoll有个大略的理解。和之前提到的select和poll不同的是，此二者皆属于零碎调用函数，然而epoll则不然，他是存在于内核中的数据结构，能够通过epoll_create，epoll_ctl及epoll_wait三个函数联合来对此数据结构进行操控。

说道epoll_create函数，其作用是在内核中创立一个epoll数据结构实例，而后将返回此实例在零碎中的文件描述符。此epoll数据结构的组成其实是一个链表构造，咱们称之为interest list，外面会注册连贯上来的client的文件描述符。

其简化工作机制如下：

说道epoll_ctl函数，其作用则是对epoll实例进行增删改查操作。有些相似咱们罕用的CRUD操作。这个函数操作的对象其实就是epoll数据结构，当有新的client连贯上来的时候，他会将此client注册到epoll中的interest list中，此操作通过附加EPOLL_CTL_ADD标记来实现；当已有的client掉线或者被动下线的时候，他会将下线的client从epoll的interest list中移除，此操作通过附加EPOLL_CTL_DEL标记来实现；当有client的文件描述符有变更的时候，他会将events中的对应的文件描述符进行更新，此操作通过附加EPOLL_CTL_MOD来实现；当interest list中有client曾经筹备好了，能够进行IO操作的时候，他会将这些clients拿进去，而后放到一个新的ready list外面。

其简化工作机制如下：

说道epoll_wait函数，其作用就是扫描ready list，解决准备就绪的client IO，其返回后果即为筹备好进行IO的client的个数。通过遍历这些筹备好的client，就能够轻松进行IO解决了。

下面这三个函数是epoll操作的根本函数，然而，想要彻底了解epoll，则须要先理解这三块内容，即：inode，链表，红黑树。

在linux内核中，针对以后关上的文件，有一个open file table，外面记录的是所有关上的文件描述符信息；同时也有一个inode table，外面则记录的是底层的文件描述符信息。这里如果文件描述符B fork了文件描述符A，尽管在open file table中，咱们看新增了一个文件描述符B，然而实际上，在inode table中，A和B的底层是截然不同的。这里，将inode table中的内容了解为windows中的文件属性，会更加贴切和易懂。这样存储的益处就是，无论下层文件描述符怎么变动，因为epoll监控的数据永远是inode table的底层数据，那么我就能够始终可能监控到文件的各种变动信息，这也是epoll高效的根底。更多详细信息，请参阅这两篇文章：Nonblocking IO & The method to epoll's madness.

简化流程如下：

数据存储这块解决了，那么针对连贯上来的客户端socket，该用什么数据结构保留进来呢？这里用到了红黑树，因为客户端socket会有频繁的新增和删除操作，而红黑树这块工夫复杂度仅仅为O(logN)，还是挺高效的。有人会问为啥不必哈希表呢？当大量的连贯频繁的进行接入或者断开的时候，扩容或者其余行为将会产生不少的rehash操作，而且还要思考哈希抵触的状况。尽管查问速度确实能够达到o(1)，然而rehash或者哈希抵触是不可控的，所以基于这些考量，我认为红黑树占优一些。

客户端socket怎么治理这块解决了，接下来，当有socket有数据须要进行读写事件处理的时候，零碎会将曾经就绪的socket增加到双向链表中，而后通过epoll_wait办法检测的时候，其实查看的就是这个双向链表，因为链表中都是就绪的数据，所以防止了针对整个客户端socket列表进行遍历的状况，使得整体效率大大晋升。 整体的操作流程为：

首先，利用epoll_create在内核中创立一个epoll对象。其实这个epoll对象，就是一个能够存储客户端连贯的数据结构。

而后，客户端socket连贯上来，会通过epoll_ctl操作将后果增加到epoll对象的红黑树数据结构中。

而后，一旦有socket有事件产生，则会通过回调函数将其增加到ready list双向链表中。

最初，epoll_wait会遍历链表来解决曾经筹备好的socket，而后通过事后设置的程度触发或者边缘触发来进行数据的感知操作。

从下面的细节能够看出，因为epoll外部监控的是底层的文件描述符信息，能够将变更的描述符间接退出到ready list，无需用户将所有的描述符再进行传入。同时因为epoll_wait扫描的是曾经就绪的文件描述符，防止了很多有效的遍历查问，使得epoll的整体性能大大晋升，能够说当初只有议论linux平台的IO多路复用，epoll曾经成为了不二之选。

程度触发和边缘触发

下面说到了epoll，次要解说了client端怎么连进来，然而并未具体的解说epoll_wait怎么被唤醒的，这里我未来具体的解说一下。

程度触发，意即Level Trigger，边缘触发，意即Edge Trigger，如果单从字面意思上了解，则不太容易，然而如果将硬件设计中的程度沿，回升沿，降落沿的概念引进来，则了解起来就容易多了。比方咱们能够这样认为：

如果将上图中的方块看做是buffer的话，那么了解起来则就更加容易了，比方针对程度触发，buffer只有是始终有数据，则始终告诉；而边缘触发，则buffer容量发生变化的时候，才会告诉。尽管能够这样简略的了解，然而实际上，其细节解决局部，比图示中展示的更加精密，这里来具体的说一下。

边缘触发

针对读操作，也就是以后fd处于EPOLLIN模式下，即可读。此时意味着有新的数据到来，接收缓冲区可读，以下buffer都指接收缓冲区：

  1. buffer由空变为非空，意即有数据进来的时候，此过程会触发告诉。

  1. buffer本来有些数据，这时候又有新数据进来的时候，数据变多，此过程会触发告诉。

  1. buffer中有数据，此时用户对操作的fd注册EPOLL_CTL_MOD事件的时候，会触发告诉。

针对写操作，也就是以后fd处于EPOLLOUT模式下，即可写。此时意味着缓冲区能够写了，以下buffer都指发送缓冲区：

  1. buffer满了，这时候发送进来一些数据，数据变少，此过程会触发告诉。

  1. buffer本来有些数据，这时候又发送进来一些数据，数据变少，此过程会触发告诉。

这里就是ET这种模式触发的几种情景，能够看出，基本上都是围绕着接收缓冲区或者发送缓冲区的状态变动来进行的。

艰涩难懂？不存在的，举个栗子：

在服务端，咱们开启边缘触发模式，而后将buffer size设为10个字节，来看看具体的表现形式。

服务端开启，客户端连贯，发送单字符A到服务端，输入后果如下：

-->ET Mode: it was triggered once
get 1 bytes of content: A
-->wait to read!

能够看到，因为buffer从空到非空，边缘触发告诉产生，之后在epoll_wait处阻塞，持续期待后续事件。

这里咱们变一下，输出ABCDEFGHIJKLMNOPQ，能够看到，客户端发送的字符长度超过了服务端buffer size，那么输入后果将是怎么样的呢？

-->ET Mode: it was triggered once
get 9 bytes of content: ABCDEFGHI
get 8 bytes of content: JKLMNOPQ
-->wait to read!

能够看到，这次发送，因为发送的长度大于buffer size，所以内容被折成两段进行接管，因为用了边缘触发形式，buffer的状况是从空到非空，所以只会产生一次告诉。

程度触发

程度触发则简略多了，他蕴含了边缘触发的所有场景，简而言之如下：

当接收缓冲区不为空的时候，有数据可读，则读事件会始终触发。

当发送缓冲区未满的时候，能够持续写入数据，则写事件始终会触发。

同样的，为了使表白更清晰，咱们也来举个栗子，依照上述入输出形式来进行。

服务端开启，客户端连贯并发送单字符A，能够看到服务端输入状况如下：

-->LT Mode: it was triggered once!
get 1 bytes of content: A

这个输入后果，毋庸置疑，因为buffer中有数据，所以程度模式触发，输入了后果。

服务端开启，客户端连贯并发送ABCDEFGHIJKLMNOPQ，能够看到服务端输入状况如下：

-->LT Mode: it was triggered once!
get 9 bytes of content: ABCDEFGHI
-->LT Mode: it was triggered once!
get 8 bytes of content: JKLMNOPQ

从后果中，能够看出，因为buffer中数据读取结束后，还有未读完的数据，所以程度模式会始终触发，这也是为啥这里程度模式被触发了两次的起因。

有了这两个栗子的比对，不晓得聪慧的你，get到二者的区别了吗？

在理论开发过程中，实际上LT更易用一些，毕竟零碎帮忙咱们做了大部分校验告诉工作，之前提到的SELECT和POLL，默认采纳的也都是这个。然而须要留神的是，当有成千上万个客户端连贯上来开始进行数据发送，因为LT的个性，内核会频繁的解决告诉操作，导致其绝对于ET来说，比拟的消耗系统资源，所以，随着客户端的增多，其性能也就越差。

而边缘触发，因为监控的是FD的状态变动，所以整体的零碎告诉并没有那么频繁，高并发下整体的性能体现也要好很多。然而因为此模式下，用户须要踊跃的解决好每一笔数据，带来的保护代价也是相当大的，略微不留神就有可能出错。所以应用起来须要十分小心才行。

至于二者如何抉择，诸位就仁者见仁智者见智吧。

行文到这里，对于epoll的解说基本上结束了，大家从中是不是学到了很多干货呢？ 因为从netty钻研到linux epoll底层，其难度十分大，能够用曲高和寡来形容，所以在这块摸索的文章是比拟少的，很多货色须要本人照着man文档和源码一点一点的推敲（linux源码详见eventpoll.c等）。这里我来纠正一下搜索引擎上，说epoll高性能是因为利用mmap技术实现了用户态和内核态的内存共享，所以性能好，我后期被这个观点误导了良久，起初下来了linux源码，翻了一下，并没有在epoll中翻到mmap的技术点，所以这个观点是谬误的。这些错误观点的文章，国内不少，国外也不少，心愿大家能审慎抉择，防止被谬误带偏。

所以，epoll高性能的根本就是，其高效的文件描述符解决形式加上颇具个性边的缘触发解决模式，以极少的内核态和用户态的切换，实现了真正意义上的高并发。