1.高并发高吞吐IO秘密武器——Epoll池化技术
2.Linux 五种 IO 模式及 select、源码poll、详解epoll 详解（附样例代码）
3.epoll机制:epoll_create、源码epoll_ctl、详解epoll_wait、源码close
4.Linux内核源码解析---EPOLL实现4之唤醒等待进程与惊群问题
5.「Linux」——select和epoll详解
6.Handler消息机制（一）：Linux的详解横版网页游戏源码epoll机制

高并发高吞吐IO秘密武器——Epoll池化技术

       epoll是Linux特有的IO复用函数，使用一组函数来完成任务，源码而不是详解单个函数。

       epoll把用户关心的源码文件描述符上的事件放在内核的一个事件表中，不需要像select、详解poll那样每次调用都要重复传入文件描述符集或事件集。源码

       epoll需要使用一个额外的详解文件描述符，来唯一标识内核中的源码时间表，由epoll_create创建。详解

       函数原型

       函数返回

       特别注意epoll_wait函数成功时返回就绪的源码文件描述符总数。select和poll返回文件描述符总数。

       以寻找已经就绪的文件描述符，举个例子如下：

       epoll_wait只需要遍历返回的文件描述符，但是poll和select需要遍历所有文件描述符

       LT水平触发模式和ET边沿触发模式

       epoll监控多个文件描述符的I/O事件。epoll支持边缘触发(edge trigger，ET)或水平触发（level trigger，LT)，通过epoll_wait等待I/O事件，如果当前没有可用的事件则阻塞调用线程。

       select和poll只支持LT工作模式，epoll的默认的工作模式是LT模式。

       水平触发：

       边沿触发：

       所以，边沿触发模式很大程度上降低了同一个epoll事件被重复触发的次数，所以效率更高。

       1. 用户态将文件描述符传入内核的方式

       2. 内核态检测文件描述符读写状态的方式

       3. 找到就绪的文件描述符并传递给用户态的方式

       4. 重复监听的处理方式

       文章福利需要C/C++ Linux服务器架构师学习资料加群（资料包括C/C++，Linux，golang技术，内核，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）

       （1）epoll_create创建epoll池

       size标识内核事件表的大小，返回的文件描述符将作用于其他所有epoll系统调用的第一个参数。

       加上异常处理，一般的写法：

       这里epollfd来唯一标识epoll池，等于-1时表示出现了异常。

       （2）在epoll池中添加fd

       epfd就是刚才创建epoll池的fd，op代表操作类型，常见三种操作类型如下：

       所以我们这里使用EPOLL_CTL_ADD在epoll池中添加注册事件：

       （3）返回就绪文件描述符

       主要通过epoll_wait来实现：

       在一段超时时间内等待一组文件描述符上的事件。如果监测到事件，就将所有就绪的事件从内核事件表(epfd参数指定)中复制到第二个参数events指向的数组中。因为events数组只用于输出epoll_wait监测到的就绪事件，而不像select、poll那样就用于传入用户注册的事件，又用于输出内核检测到的就绪事件。这样极大提高了应用程序索引就绪文件描述符的效率。

       举个例子：

       要弄懂这些问题，需要深入了解epoll背后的数据结构。

       红黑树

       Linux 内核对于 epoll 池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄 fd。红黑树是一种平衡二叉树，时间复杂度为 O(log n)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

       关于红黑树为什么可以实现高效的增删查改，就是另一个故事了，可以简单地概括如下：

       （1）每个节点或者是黑色，或者是红色。

       （2）根节点是黑色。

       （3）每个叶子节点（NIL）是黑色。 [注意：这里叶子节点，是指为空(NIL或NULL)的叶子节点！]

       （4）如果一个节点是红色的，则它的子节点必须是黑色的。

       （5）从一个节点到该节点的子孙节点的所有路径上包含相同数目的黑节点。

       双向链表

       epoll_ctl内部实现中，通过poll回调，poll 机制让上层能直接告诉底层，如果这个 fd 一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个 fd 相关的结构体放到指定队列中，并且唤醒操作系统。2020码支付源码

       poll内部挂了个钩子，设置了唤醒的回调路径。这个路径存放在哪里？放到一个特定的队列（就绪队列，ready list），这个就绪队列其实是一个双向链表。放到就绪队列中，就可以唤醒epoll啦！

       放到就绪队列中的epoll结构体的名字叫做epitem，每个注册到 epoll 池的 fd 都会对应一个。

       为什么说为网络编程而生呢？因为文件系统不能使用epoll

Linux 五种 IO 模式及 select、poll、epoll 详解（附样例代码）

       作为Web后端开发者，Linux的IO模式和Socket编程是核心内容。Socket简单来说就是IP地址和端口号的组合，用于进程间通信。本文将首先介绍IO模式的基础知识，然后深入探讨select、poll和epoll的工作原理及其优缺点，最后通过示例代码帮助理解。

       1. 基础概念：Linux区分用户空间（3G）和内核空间（1G），进程切换由内核负责，涉及上下文切换。文件描述符是程序与内核交互的桥梁，缓存I/O涉及操作系统内核缓冲区。IO模式有五种，包括阻塞与非阻塞、多路复用、同步与异步的区别。

       2. IO多路复用：select、poll和epoll都用于同时监视多个文件描述符，select和poll各有其限制，而epoll不受文件描述符数量限制，以事件驱动的方式工作，效率更高。

       3. select示例：需维护文件描述符数组，内核事件发生后用户空间遍历数组判断变化。poll与select类似，只是使用链表代替数组。

       4. epoll详解：分为边缘（ET）和水平（LT）两种模式，ET模式要求一次性收取数据，而LT模式可按需接收。epoll_wait等待事件，返回就绪事件数量或超时结果。

       5. 实际应用：epoll在高并发场景中表现优秀，如Nginx，但在连接不高的情况下，多线程配合阻塞IO可能更为适用。

epoll机制:epoll_create、epoll_ctl、epoll_wait、close

       在Linux网络编程领域，选择性调用(select)曾是处理事件触发的主要工具。然而，随着Linux内核的更新，一种新的机制——epoll机制——被引入，以替代传统的select。相较于select，epoll的最大优势在于它能避免监听文件描述符数量增长导致的效率降低。原因在于，select通过轮询处理事件，文件描述符数量越多，处理时间就越长。然而，linux/posix_types.h文件中声明的`#define__FD_SETSIZE `仅表示最多同时监听个fd，通过修改头文件并重新编译内核，这一限制虽然可以扩大，但这并非解决之道。

       epoll的接口简洁明了，仅包含三个核心函数：

       1. 创建epoll句柄：`int epfd = epoll_create(int size);`。此步骤用于生成一个epoll专用的文件描述符，用户需提供一个参数`size`，以告知内核预计监听的文件描述符的最大数量。值得注意的是，创建epoll句柄后，它会占用一个fd值，因此使用完毕后必须调用`close()`进行关闭，避免fd耗尽问题。

       2. 控制事件：`int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);`。该函数用于对epoll句柄进行事件控制，包括注册、修改或删除监听事件。参数`epfd`为`epoll_create`的返回值，`op`表示要执行的操作类型（如注册事件、修改事件、删除事件），`fd`为关联的ins下载php源码文件描述符，而`event`指向`epoll_event`结构的指针，用于向内核指示需要监听的事件类型。

       3. 等待事件触发：`int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);`。此函数用于等待事件发生，类似于select调用。它接收事件集合、最大事件数量、超时时间（以毫秒为单位，0表示立即返回，-1表示阻塞直到事件发生）作为参数，并返回实际处理事件的数量。

       在epoll中，事件注册函数主要负责注册要监听的事件类型。通过设置`epfd`为`epoll_create()`的返回值，`op`为`EPOLL_CTL_ADD`、`EPOLL_CTL_MOD`或`EPOLL_CTL_DEL`来分别注册、修改或删除事件。`fd`参数关联文件描述符，而`events`结构中的`EPOLLIN`、`EPOLLOUT`、`EPOLLPRI`、`EPOLLERR`、`EPOLLHUP`等宏用于指示事件类型，如读事件、写事件、优先读事件、错误事件、挂断事件等。

       EPOLL事件有两种模型：Edge Triggered(ET)和Level Triggered(LT)。ET模式以高速工作，适用于非阻塞socket，但错误率较高，且只支持无阻塞套接口，避免多文件描述符处理任务被饿死。LT模式则相当于快速的poll机制，支持阻塞和非阻塞socket，错误率较小，是默认工作方式。当使用ET模式时，若在事件处理后不对文件描述符进行I/O操作，内核会持续通知，直到收到新的事件。相反，LT模式在事件处理后会立即停止通知，直至文件描述符再次变为可操作状态。

       通过epoll机制的引入，Linux网络编程在事件处理效率和灵活性上有了显著提升，为开发者提供了更高效、更可靠的事件处理方式。

Linux内核源码解析---EPOLL实现4之唤醒等待进程与惊群问题

       在Linux内核源码的EPOLL实现中，第四部分着重探讨了数据到来时如何唤醒等待进程以及惊群问题。当网卡接收到数据，DMA技术将数据复制到内存RingBuffer，通过硬中断通知CPU，然后由ksoftirqd线程处理，最终数据会进入socket接收队列。虽然ksoftirqd的创建过程不在本节讨论，但核心是理解数据如何从协议层传递到socket buffer。

       在tcp_ipv4.c中，当接收到socket buffer时，会首先在连接表和监听表中寻找对应的socket。一旦找到，进入tcp_rcv_established函数，这里会检查socket是否准备好接收数据，通过调用sock_data_ready，其初始值为sock_def_readable，进而进入wake_up函数，唤醒之前挂上的wait_queue_t节点。

       在wake_up方法中，会遍历链表并回调ep_poll_callback，这个函数是epoll的核心逻辑。然而，如果epoll的设置没有启用WQ_FLAG_EXCLUSIVE，就会导致惊群效应，即唤醒所有阻塞在当前epoll的进程。这在default_wake_function函数中体现，如果没有特殊标记，进程会立即被唤醒并进入调度。

       总结来说，epoll的唤醒过程涉及socket buffer、协议层处理、链表操作以及回调函数，其中惊群问题与默认的唤醒策略密切相关。理解这些细节，有助于深入理解Linux内核中EPOLL的异步操作机制。

「Linux」——select和epoll详解

       系统提供select函数来实现多路复用输入/输出模型。疫情追踪APP源码select系统调用允许程序监视多个文件描述符的状态变化；程序会在这里等待，直到被监视的文件描述符有一个或多个发生了状态改变。

       1. select函数原型

       select的函数原型如下: #include

       2. 参数解释

       3. 参数timeout取值

       4. 返回值

       5. 监控原理

       二、select就绪条件

       1. 读就绪

       2. 写就绪

       三、select的特点

       四、select的优缺点

       1. 缺点

       2. 优点

       五、select使用实例

       使用select实现字典服务器

       tcp_select_server.hpp

       dict_server.cc这个代码和之前相同，只是把里面的server对象改成TcpSelectServer类即可。客户端和之前的客户端完全相同，无需单独开发

       poll

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

       struct pollfd{ int fd; //文件描述符short events; //对当前描述符实际就绪的事件short revents; //当前描述符实际就绪的事件}

       poll对描述符进行监控，是对最关心的描述符组织一个事件结构，填充信息：events中填充，用户关心的事件，进行监控后，若描述符就绪了整个事件，则将这个事件在revents中进行记录

       epoll

       epoll是为了处理大量的句柄而改进的poll

       一、epoll_create创建一个epoll的句柄

       二、epoll_wait

       1. 收集在epoll监控的事件中已经发送的事件

       2. epoll的优点(和select的缺点对应)

       三、epoll的使用场景

       例如，典型的一个需要处理上万个客户端的服务器，例如各种互联网APP的入口服务器，这样的服务器就很适合epoll。如果只是系统内部，服务器和服务器之间进行通信，只有少数的几个连接，这种情况下用epoll就并不合适。具体要根据需求和场景特点来决定使用哪种IO模型。

Handler消息机制（一）：Linux的epoll机制

        在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。

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

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

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

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

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

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

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

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

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

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

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

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

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

        在epoll中，源码文档调格式对于每一个事件，都会建立一个epitem结构体，如下所示：

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

        epoll结构示意图

        通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。

        events可以是以下几个宏的集合：

        EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；

        EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；

        EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；

        EPOLLERR：表示对应的文件描述符发生错误；

        EPOLLHUP： 表示对应的文件描述符被挂断；

        EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。

        EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。

        示例：

        ET(EdgeTriggered):高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)

        LT(LevelTriggered):缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！

        1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符

        \2. 这个时候从管道的另一端被写入了2KB的数据

        \3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作

        \4. 然后我们读取了1KB的数据

        \5. 调用epoll_wait(2)……

        ET工作模式：

        如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

        只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

        LT工作模式：

        LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。

        当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。

        1.减少用户态和内核态之间的文件句柄拷贝；

        2.减少对可读可写文件句柄的遍历。

        /developer/information/linux%epoll%E6%9C%BA%E5%%B6

        /s?id=&wfr=spider&for=pc

图文并茂讲解epoll原理，彻底弄懂epoll机制

       本文详尽解析epoll的工作原理，带你深入理解这个高效的并发事件处理机制。

       首先，epoll的核心在于epoll_create，通过该函数创建一个文件描述符，用于后续的事件监听。epoll_ctl则用于管理事件，事件会被存储在内核的epoll红黑树结构中。

       epoll_event结构体是事件的核心，它描述了套接字的状态和处理方式。epoll_wait则是关键函数，它负责监听套接字事件，可根据超时时间选择阻塞或非阻塞模式。

       LT模式（水平触发）和ET模式（边缘触发）是epoll的两种工作模式。LT模式下，一旦数据可用，EPOLLIN事件将持续触发，直到数据读取完毕。而ET模式下，数据从无到有仅触发一次，用户需一次性读取所有数据。

       关于epoll的阻塞性，epoll本身是阻塞的，但用户可以通过设置epoll_wait的超时参数来控制。重要的是，epoll监听套接字应设置为非阻塞，以保持高并发性能。

       epoll之所以高效，得益于红黑树的数据结构，它优化了事件的增删查改操作。同时，通过回调通知机制，当套接字有事件时，epoll直接将就绪事件放入用户可读取的队列，避免了不必要的轮询，提升了效率。

       通过实战示例，如服务端和客户端程序，我们可以更好地掌握epoll的使用。最后，对于C++ Linux后台开发的学习路径，这里有一个全面的路线大纲供你参考。

深入理解Linux的epoll机制

       在Linux系统之中有一个核心武器：epoll池，在高并发的，高吞吐的IO系统中常常见到epoll的身影。

IO多路复用

       在Go里最核心的是Goroutine，也就是所谓的协程，协程最妙的一个实现就是异步的代码长的跟同步代码一样。比如在Go中，网络IO的read，write看似都是同步代码，其实底下都是异步调用，一般流程是：

write(/*IO参数*/)请求入队等待完成后台loop程序发送网络请求唤醒业务方

       Go配合协程在网络IO上实现了异步流程的同步代码化。核心就是用epoll池来管理网络fd。

       实现形式上，后台的程序只需要1个就可以负责管理多个fd句柄，负责应对所有的业务方的IO请求。这种一对多的IO模式我们就叫做IO多路复用。

       多路是指？多个业务方（句柄）并发下来的IO。

       复用是指？复用这一个后台处理程序。

       站在IO系统设计人员的角度，业务方咱们没办法提要求，因为业务是上帝，只有你服从的份，他们要创建多个fd，那么你就需要负责这些fd的处理，并且最好还要并发起来。

       业务方没法提要求，那么只能要求后台loop程序了！

       要求什么呢？快！快！快！这就是最核心的要求，处理一定要快，要给每一个fd通道最快的感受，要让每一个fd觉得，你只在给他一个人跑腿。

       那有人又问了，那我一个IO请求（比如write）对应一个线程来处理，这样所有的IO不都并发了吗？是可以，但是有瓶颈，线程数一旦多了，性能是反倒会差的。

       这里不再对比多线程和IO多路复用实现高并发之间的区别，详细的可以去了解下nginx和redis高并发的秘密。

最朴实的实现方式？

       我不用任何其他系统调用，能否实现IO多路复用？

       可以的。那么写个for循环，每次都尝试IO一下，读/写到了就处理，读/写不到就sleep下。这样我们不就实现了1对多的IO多路复用嘛。

whileTrue:foreach句柄数组{ read/write(fd,/*参数*/)}sleep(1s)

       慢着，有个问题，上面的程序可能会被卡死在第三行，使得整个系统不得运行，为什么？

       默认情况下，我们没有加任何参数create出的句柄是阻塞类型的。我们读数据的时候，如果数据还没准备好，是会需要等待的，当我们写数据的时候，如果还没准备好，默认也会卡住等待。所以，在上面伪代码第三行是可能被直接卡死，而导致整个线程都得到不到运行。

       举个例子，现在有，，这3个句柄，现在读写都没有准备好，只要read/write(,/*参数*/)就会被卡住，但，这两个句柄都准备好了，那遍历句柄数组，，的时候就会卡死在前面，后面，则得不到运行。这不符合我们的预期，因为我们IO多路复用的loop线程是公共服务，不能因为一个fd就直接瘫痪。

       那这个问题怎么解决？

       只需要把fd都设置成非阻塞模式。这样read/write的时候，如果数据没准备好，返回EAGIN的错误即可，不会卡住线程，从而整个系统就运转起来了。比如上面句柄还未就绪，那么read/write(,/*参数*/)不会阻塞，只会报个EAGIN的错误，这种错误需要特殊处理，然后loop线程可以继续执行，的读写。

       以上就是最朴实的IO多路复用的实现了。但是好像在生产环境没见过这种IO多路复用的实现？为什么？

       因为还不够高级。for循环每次要定期sleep1s，这个会导致吞吐能力极差，因为很可能在刚好要sleep的时候，所有的fd都准备好IO数据，而这个时候却要硬生生的等待1s，可想而知。。。

       那有同学又要质疑了，那for循环里面就不sleep嘛，这样不就能及时处理了吗？

       及时是及时了，但是CPU估计要跑飞了。不加sleep，那在没有fd需要处理的时候，估计CPU都要跑到%了。这个也是无法接受的。

       纠结了，那sleep吞吐不行，不sleep浪费cpu，怎么办？

       这种情况用户态很难有所作为，只能求助内核来提供机制协助来。因为内核才能及时的管理这些通知和调度。

       我们再梳理下IO多路复用的需求和原理。IO多路复用就是1个线程处理多个fd的模式。我们的要求是：这个“1”就要尽可能的快，避免一切无效工作，要把所有的时间都用在处理句柄的IO上，不能有任何空转，sleep的时间浪费。

       有没有一种工具，我们把一箩筐的fd放到里面，只要有一个fd能够读写数据，后台loop线程就要立马唤醒，全部马力跑起来。其他时间要把cpu让出去。

       能做到吗？能，这种需求只能内核提供机制满足你。

这事Linux内核必须要给个说法？

       是的，想要不用sleep这种辣眼睛的实现，Linux内核必须出手了，毕竟IO的处理都是内核之中，数据好没好内核最清楚。

       内核一口气提供了3种工具select，poll，epoll。

       为什么有3种？

       历史不断改进，矬->较矬->卧槽、高效的演变而已。

       Linux还有其他方式可以实现IO多路复用吗？

       好像没有了！

       这3种到底是做啥的？

       这3种都能够管理fd的可读可写事件，在所有fd不可读不可写无所事事的时候，可以阻塞线程，切走cpu。fd有情况的时候，都要线程能够要能被唤醒。

       而这三种方式以epoll池的效率最高。为什么效率最高？

       其实很简单，这里不详说，其实无非就是epoll做的无用功最少，select和poll或多或少都要多余的拷贝，盲猜（遍历才知道）fd，所以效率自然就低了。

       举个例子，以select和epoll来对比举例，池子里管理了个句柄，loop线程被唤醒的时候，select都是蒙的，都不知道这个fd里谁IO准备好了。这种情况怎么办？只能遍历这个fd，一个个测试。假如只有一个句柄准备好了，那相当于做了1千多倍的无效功。

       epoll则不同，从epoll_wait醒来的时候就能精确的拿到就绪的fd数组，不需要任何测试，拿到的就是要处理的。

epoll池原理

       下面我们看一下epoll池的使用和原理。

epoll涉及的系统调用

       epoll的使用非常简单，只有下面3个系统调用。

epoll_createepollctlepollwait

       就这？是的，就这么简单。

       epollcreate负责创建一个池子，一个监控和管理句柄fd的池子；

       epollctl负责管理这个池子里的fd增、删、改；

       epollwait就是负责打盹的，让出CPU调度，但是只要有“事”，立马会从这里唤醒；

epoll高效的原理

       Linux下，epoll一直被吹爆，作为高并发IO实现的秘密武器。其中原理其实非常朴实：epoll的实现几乎没有做任何无效功。我们从使用的角度切入来一步步分析下。

       首先，epoll的第一步是创建一个池子。这个使用epoll_create来做：

       原型：

intepoll_create(intsize);

       示例：

epollfd=epoll_create();if(epollfd==-1){ perror("epoll_create");exit(EXIT_FAILURE);}

       这个池子对我们来说是黑盒，这个黑盒是用来装fd的，我们暂不纠结其中细节。我们拿到了一个epollfd，这个epollfd就能唯一代表这个epoll池。

       然后，我们就要往这个epoll池里放fd了，这就要用到epoll_ctl了

       原型：

intepoll_ctl(intepfd,intop,intfd,structepoll_event*event);

       示例：

if(epoll_ctl(epollfd,EPOLL_CTL_ADD,,&ev)==-1){ perror("epoll_ctl:listen_sock");exit(EXIT_FAILURE);}

       上面，我们就把句柄放到这个池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、删除，event结构体可以指定监听事件类型，可读、可写。

       第一个跟高效相关的问题来了，添加fd进池子也就算了，如果是修改、删除呢？怎么做到时间快？

       这里就涉及到你怎么管理fd的数据结构了。

       最常见的思路：用list，可以吗？功能上可以，但是性能上拉垮。list的结构来管理元素，时间复杂度都太高O(n)，每次要一次次遍历链表才能找到位置。池子越大，性能会越慢。

       那有简单高效的数据结构吗？

       有，红黑树。Linux内核对于epoll池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄fd。红黑树是一种平衡二叉树，时间复杂度为O(logn)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

       现在思考第二个高效的秘密：怎么才能保证数据准备好之后，立马感知呢？

       epoll_ctl这里会涉及到一点。秘密就是：回调的设置。在epoll_ctl的内部实现中，除了把句柄结构用红黑树管理，另一个核心步骤就是设置poll回调。

       思考来了：poll回调是什么？怎么设置？

       先说说file_operations->poll是什么？

       在fd篇说过，Linux设计成一切皆是文件的架构，这个不是说说而已，而是随处可见。实现一个文件系统的时候，就要实现这个文件调用，这个结构体用structfile_operations来表示。这个结构体有非常多的函数，我精简了一些，如下：

structfile_operations{ ssize_t(*read)(structfile*,char__user*,size_t,loff_t*);ssize_t(*write)(structfile*,constchar__user*,size_t,loff_t*);__poll_t(*poll)(structfile*,structpoll_table_struct*);int(*open)(structinode*,structfile*);int(*fsync)(structfile*,loff_t,loff_t,intdatasync);//....};

       你看到了read，write，open，fsync，poll等等，这些都是对文件的定制处理操作，对于文件的操作其实都是在这个框架内实现逻辑而已，比如ext2如果有对read/write做定制化，那么就会是ext2_read，ext2_write，ext4就会是ext4_read，ext4_write。在open具体“文件”的时候会赋值对应文件系统的file_operations给到file结构体。

       那我们很容易知道read是文件系统定制fd读的行为调用，write是文件系统定制fd写的行为调用，file_operations->poll呢？

       这个是定制监听事件的机制实现。通过poll机制让上层能直接告诉底层，我这个fd一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个fd相关的结构体放到指定队列中，并且唤醒操作系统。

       举个例子：网卡收发包其实走的异步流程，操作系统把数据丢到一个指定地点，网卡不断的从这个指定地点掏数据处理。请求响应通过中断回调来处理，中断一般拆分成两部分：硬中断和软中断。poll函数就是把这个软中断回来的路上再加点料，只要读写事件触发的时候，就会立马通知到上层，采用这种事件通知的形式就能把浪费的时间窗就完全消失了。

       划重点：这个poll事件回调机制则是epoll池高效最核心原理。

       划重点：epoll池管理的句柄只能是支持了file_operations->poll的文件fd。换句话说，如果一个“文件”所在的文件系统没有实现poll接口，那么就用不了epoll机制。

       第二个问题：poll怎么设置？

       在epoll_ctl下来的实现中，有一步是调用vfs_poll这个里面就会有个判断，如果fd所在的文件系统的file_operations实现了poll，那么就会直接调用，如果没有，那么就会报告响应的错误码。

staticinline__poll_tvfs_poll(structfile*file,structpoll_table_struct*pt){ if(unlikely(!file->f_op->poll))returnDEFAULT_POLLMASK;returnfile->f_op->poll(file,pt);}

       你肯定好奇poll调用里面究竟是实现了什么？

       总结概括来说：挂了个钩子，设置了唤醒的回调路径。epoll跟底层对接的回调函数是：ep_poll_callback，这个函数其实很简单，做两件事情：

       把事件就绪的fd对应的结构体放到一个特定的队列（就绪队列，readylist）；

       唤醒epoll，活来啦！

       当fd满足可读可写的时候就会经过层层回调，最终调用到这个回调函数，把对应fd的结构体放入就绪队列中，从而把epoll从epoll_wait出唤醒。

       这个对应结构体是什么？

       结构体叫做epitem，每个注册到epoll池的fd都会对应一个。

       就绪队列很高级吗？

       就绪队列就简单了，因为没有查找的需求了呀，只要是在就绪队列中的epitem，都是事件就绪的，必须处理的。所以就绪队列就是一个最简单的双指针链表。

       小结下：epoll之所以做到了高效，最关键的两点：

       内部管理fd使用了高效的红黑树结构管理，做到了增删改之后性能的优化和平衡；

       epoll池添加fd的时候，调用file_operations->poll，把这个fd就绪之后的回调路径安排好。通过事件通知的形式，做到最高效的运行；

       epoll池核心的两个数据结构：红黑树和就绪列表。红黑树是为了应对用户的增删改需求，就绪列表是fd事件就绪之后放置的特殊地点，epoll池只需要遍历这个就绪链表，就能给用户返回所有已经就绪的fd数组；

哪些fd可以用epoll来管理？

       再来思考另外一个问题：由于并不是所有的fd对应的文件系统都实现了poll接口，所以自然并不是所有的fd都可以放进epoll池，那么有哪些文件系统的file_operations实现了poll接口？

       首先说，类似ext2，ext4，xfs这种常规的文件系统是没有实现的，换句话说，这些你最常见的、真的是文件的文件系统反倒是用不了epoll机制的。

       那谁支持呢？

       最常见的就是网络套接字：socket。网络也是epoll池最常见的应用地点。Linux下万物皆文件，socket实现了一套socket_file_operations的逻辑（net/socket.c）：

staticconststructfile_operationssocket_file_ops={ .read_iter=sock_read_iter,.write_iter=sock_write_iter,.poll=sock_poll,//...};

       我们看到socket实现了poll调用，所以socketfd是天然可以放到epoll池管理的。

       还有吗？

       有的，其实Linux下还有两个很典型的fd，常常也会放到epoll池里。

       eventfd：eventfd实现非常简单，故名思义就是专门用来做事件通知用的。使用系统调用eventfd创建，这种文件fd无法传输数据，只用来传输事件，常常用于生产消费者模式的事件实现；

       timerfd：这是一种定时器fd，使用timerfd_create创建，到时间点触发可读事件；

       小结一下：

       ext2，ext4，xfs等这种真正的文件系统的fd，无法使用epoll管理；

       socketfd，eventfd，timerfd这些实现了poll调用的可以放到epoll池进行管理；

       其实，在Linux的模块划分中，eventfd，timerfd，epoll池都是文件系统的一种模块实现。

思考

       前面我们已经思考了很多知识点，有一些简单有趣的知识点，提示给读者朋友，这里只抛砖引玉。

       问题：单核CPU能实现并行吗？

       不行。

       问题：单线程能实现高并发吗？

       可以。

       问题：那并发和并行的区别是？

       一个看的是时间段内的执行情况，一个看的是时间时刻的执行情况。

       问题：单线程如何做到高并发？

       IO多路复用呗，今天讲的epoll池就是了。

       问题：单线程实现并发的有开源的例子吗？

       redis，nginx都是非常好的学习例子。当然还有我们Golang的runtime实现也尽显高并发的设计思想。

总结

       IO多路复用的原始实现很简单，就是一个1对多的服务模式，一个loop对应处理多个fd；

       IO多路复用想要做到真正的高效，必须要内核机制提供。因为IO的处理和完成是在内核，如果内核不帮忙，用户态的程序根本无法精确的抓到处理时机；

       fd记得要设置成非阻塞的哦，切记；

       epoll池通过高效的内部管理结构，并且结合操作系统提供的poll事件注册机制，实现了高效的fd事件管理，为高并发的IO处理提供了前提条件；

       epoll全名eventpoll，在Linux内核下以一个文件系统模块的形式实现，所以有人常说epoll其实本身就是文件系统也是对的；

       socketfd，eventfd，timerfd这三种”文件“fd实现了poll接口，所以网络fd，事件fd，定时器fd都可以使用epoll_ctl注册到池子里。我们最常见的就是网络fd的多路复用；

       ext2，ext4，xfs这种真正意义的文件系统反倒没有提供poll接口实现，所以不能用epoll池来管理其句柄。那文件就无法使用epoll机制了吗？不是的，有一个库叫做libaio，通过这个库我们可以间接的让文件使用epoll通知事件，以后详说，此处不表；

后记

       epoll池使用很简洁，但实现不简单。还是那句话，Linux内核帮你包圆了。

       今天并没有罗列源码实现，以很小的思考点为题展开，简单讲了一些epoll的思考，以后有机会可以分享下异步IO（aio）和epoll能产生什么火花？Golang是怎样使用epoll池的？敬请期待哦。

       原创不易，更多干货，关注：奇伢云存储