皮皮网

1.epoll机制:epoll_create、源码epoll_ctl、分析epoll_wait、源码close
2.图文并茂讲解epoll原理，分析彻底弄懂epoll机制
3.Linux 五种 IO 模式及 select、源码poll、分析手游源码二次开发教程下载epoll 详解（附样例代码）
4.C++通讯架构学习：epoll介绍及原理详解
5.Handler消息机制（一）：Linux的源码epoll机制
6.「Linux」——select和epoll详解

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句柄进行事件控制，系统jsp源码免费包括注册、修改或删除监听事件。参数`epfd`为`epoll_create`的返回值，`op`表示要执行的操作类型（如注册事件、修改事件、删除事件），`fd`为关联的文件描述符，而`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网络编程在事件处理效率和灵活性上有了显著提升，为开发者提供了更高效、更可靠的事件处理方式。

图文并茂讲解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 五种 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可能更为适用。

C++通讯架构学习：epoll介绍及原理详解

       Epoll技术在I/O多路复用中起到关键作用，尤其在支撑高并发连接方面表现出色。它与kqueue技术相似，能够管理上万至数百万的并发连接。

       在服务器程序中，利用多进程或多线程处理连接，每个进程或线程对应一个连接。将Epoll技术融入项目中，构建小demo较为简单，但要将其应用到实际商业环境，难度会显著增加。

       Epoll的实现基于红黑树和双向链表。epoll_create函数创建一个eventpoll结构对象，由系统保存。epoll_ctl函数用于将socket及其相关事件添加到epoll对象中，以便监视socket数据交换，当有数据时系统通知。操作包括添加、删除和修改事件。

       epoll_wait函数阻塞等待事件发生，返回已就绪的读写事件集合。双向链表记录所有准备好事件的socket，实际事件数量即返回结果。epitem结构设计巧妙，既作为红黑树节点，又作为双向链表节点，方便内核操作。

       Epoll技术的运用能有效提升服务器性能和处理并发能力，是Linux服务器开发和架构师不可或缺的技术之一。

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

「Linux」——select和epoll详解

       系统提供select函数来实现多路复用输入/输出模型。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模型。