EPOLL的ET和LT模式

合集下载

关于Epoll,你应该知道的那些细节

关于Epoll，你应该知道的那些细节Epoll，位于头文件sys/epoll.h，是Linux系统上的I/O事件通知基础设施。

epoll API为Linux系统专有，于内核2.5.44中首次引入，glibc于2.3.2版本加入支持。

其它提供类似的功能的系统，包括FreeBSD kqueue，Solaris /dev/poll等。

Epoll APIEpoll API实现了与poll类似的功能：监测多个文件描述符上是否可以执行I/O操作。

支持边缘触发ET和水平触发LT，相比poll支持监测数量更多的文件描述符。

以下API用于创建和管理epoll实例：epoll_create：创建Epoll实例，并返回Epoll实例关联的文件描述符。

（最新的epoll_create1扩展了epoll_create的功能）create_ctl：注册关注的文件描述符。

注册于同一epoll实例的一组文件描述符被称为epoll set，可以通过进程对应的/proc/[pid]/fdinfo目录查看。

epoll_wait：等待I/O事件，如果当前没有任何注册事件处于可用状态，调用线程会被阻塞。

水平触发LT与边缘触发ETEpoll事件分发接口可以使用ET和LT两种模式。

两种模式的差别描述如下。

典型场景：1 管道(pipe)读端的文件描述符(rfd)注册于Epoll实例。

2 写者(Writer)向管道(pipe)写端写2KB的数据。

3 epoll_wait调用结束，返回rfd作为就绪的文件描述符。

4 管道读者(pipe reader) 从rfd读1KB的数据。

5 下一次epoll_wait调用。

如果rfd文件描述符使用EPOLLET(边缘触发)标记加入Epoll接口，第5步对epoll_wait 的调用可能会挂住，尽管文件输入缓冲区中仍然有可用数据；与此同时，远端实体由于已经发送数据，可能正在等待回应。

其原因是边缘触发模式仅在所监控的文件描述符状态发。

epoll的LT和ET使用EPOLLONESHOT

epoll的LT和ET使⽤EPOLLONESHOTepoll有两种触发的⽅式即LT（⽔平触发）和ET（边缘触发）两种，在前者，只要存在着事件就会不断的触发，直到处理完成，⽽后者只触发⼀次相同事件或者说只在从⾮触发到触发两个状态转换的时候⼉才触发。

这会出现下⾯⼀种情况，如果是多线程在处理，⼀个SOCKET事件到来，数据开始解析，这时候这个SOCKET⼜来了同样⼀个这样的事件，⽽你的数据解析尚未完成，那么程序会⾃动调度另外⼀个线程或者进程来处理新的事件，这造成⼀个很严重的问题，不同的线程或者进程在处理同⼀个SOCKET的事件，这会使程序的健壮性⼤降低⽽编程的复杂度⼤⼤增加！！即使在ET模式下也有可能出现这种情况！！解决这种现象有两种⽅法：第⼀种⽅法是在单独的线程或进程⾥解析数据，也就是说，接收数据的线程接收到数据后⽴刻将数据转移⾄另外的线程。

第⼆种⽅法就是本⽂要提到的EPOLLONESHOT这种⽅法，可以在epoll上注册这个事件，注册这个事件后，如果在处理写成当前的SOCKET后不再重新注册相关事件，那么这个事件就不再响应了或者说触发了。

要想重新注册事件则需要调⽤epoll_ctl重置⽂件描述符上的事件，这样前⾯的socket就不会出现竞态这样就可以通过⼿动的⽅式来保证同⼀SOCKET只能被⼀个线程处理，不会跨越多个线程。

看下⾯的代码：void Eepoll::ResetOneShot(int epollfd,SOCKET fd,bool bOne){epoll_eventevent;event.data.fd= fd;event.events= EPOLLIN | EPOLLET ;if(bOne){event.events |=EPOLLONESHOT;}if(-1 == epoll_ctl(epollfd,EPOLL_CTL_MOD,fd,&event)){perror("resetoneshotepoll_ctl error!");}}这⾥有⼀个问题，在操作ET模式下的EPOLL时，对EPOLLONESHOT没有什么太⼤的注意点，但是在LT时，就有⼀些注意的了。

深入理解epoll讲解

深入理解epoll1、基本知识epoll是在2.6内核中提出的，是之前的select和poll的增强版本。

相对于select和poll 来说，epoll更加灵活，没有描述符限制。

epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

2、epoll接口epoll操作过程需要三个接口，分别如下：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片#include <sys/epoll.h>int epoll_create(int size);int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);（1）int epoll_create(int size);创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。

这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。

需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在Linux下如果查看/proc/进程id/fd/，是能够看到这个fd 的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

（2）int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

epoll原理详解及epoll反应堆模型

epoll原理详解及epoll反应堆模型⽂章⽬录⼀、epoll原理详解⼆、epoll的两种触发模式三、epoll反应堆模型设想⼀个场景：有100万⽤户同时与⼀个进程保持着TCP连接，⽽每⼀时刻只有⼏⼗个或⼏百个TCP连接是活跃的(接收TCP包)，也就是说在每⼀时刻进程只需要处理这100万连接中的⼀⼩部分连接。

那么，如何才能⾼效的处理这种场景呢？进程是否在每次询问操作系统收集有事件发⽣的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出其中有事件发⽣的⼏百个连接呢？实际上，在Linux2.4版本以前，那时的select或者poll事件驱动⽅式是这样做的。

这⾥有个⾮常明显的问题，即在某⼀时刻，进程收集有事件的连接时，其实这100万连接中的⼤部分都是没有事件发⽣的。

因此如果每次收集事件时，都把100万连接的套接字传给操作系统(这⾸先是⽤户态内存到内核态内存的⼤量复制)，⽽由操作系统内核寻找这些连接上有没有未处理的事件，将会是巨⼤的资源浪费，然后select和poll就是这样做的，因此它们最多只能处理⼏千个并发连接。

⽽epoll不这样做，它在Linux内核中申请了⼀个简易的⽂件系统，把原先的⼀个select或poll调⽤分成了3部分：1int epoll_create(int size);2int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);3int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);1. 调⽤epoll_create建⽴⼀个epoll对象(在epoll⽂件系统中给这个句柄分配资源)；2. 调⽤epoll_ctl向epoll对象中添加这100万个连接的套接字；3. 调⽤epoll_wait收集发⽣事件的连接。

epoll工作模式详解

我们目前的网络模型大都是epoll的，因为epoll模型会比select模型性能高很多，尤其在大连接数的情况下，作为后台开发人员需要理解其中的原因。

select/epoll的特点select的特点：select 选择句柄的时候，是遍历所有句柄，也就是说句柄有事件响应时，select 需要遍历所有句柄才能获取到哪些句柄有事件通知，因此效率是非常低。

但是如果连接很少的情况下，select和epoll的LT触发模式相比，性能上差别不大。

这里要多说一句，select支持的句柄数是有限制的，同时只支持1024个，这个是句柄集合限制的，如果超过这个限制，很可能导致溢出，而且非常不容易发现问题，TAF就出现过这个问题，调试了n天，才发现：）当然可以通过修改linux的socket内核调整这个参数。

epoll的特点：epoll对于句柄事件的选择不是遍历的，是事件响应的，就是句柄上事件来就马上选择出来，不需要遍历整个句柄链表，因此效率非常高，内核将句柄用红黑树保存的。

对于epoll而言还有ET和LT的区别，LT表示水平触发，ET表示边缘触发，两者在性能以及代码实现上差别也是非常大的。

epoll的LT和ET的区别LT：水平触发，效率会低于ET触发，尤其在大并发，大流量的情况下。

但是LT对代码编写要求比较低，不容易出现问题。

LT模式服务编写上的表现是：只要有数据没有被获取，内核就不断通知你，因此不用担心事件丢失的情况。

ET：边缘触发，效率非常高，在并发，大流量的情况下，会比LT少很多epoll的系统调用，因此效率高。

但是对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。

下面举一个列子来说明LT和ET的区别（都是非阻塞模式，阻塞就不说了，效率太低）：采用LT模式下，如果accept调用有返回就可以马上建立当前这个连接了，再epoll_wait 等待下次通知，和select一样。

但是对于ET而言，如果accpet调用有返回，除了建立当前这个连接外，不能马上就epoll_wait 还需要继续循环accpet，直到返回-1，且errno==EAGAIN，TAF里面的示例代码：if(ev.events & EPOLLIN){do{struct sockaddr_in stSockAddr;socklen_t iSockAddrSize = sizeof(sockaddr_in);TC_Socket cs;cs.setOwner(false);//接收连接TC_Socket s;s.init(fd, false, AF_INET);int iRetCode = s.accept(cs, (struct sockaddr *) &stSockAddr, iSockAddrSize);if (iRetCode > 0){…建立连接}else{//直到发生EAGAIN才不继续acceptif(errno == EAGAIN){break;}}}while(true);}同样，recv/send等函数，都需要到errno==EAGAIN从本质上讲：与LT相比，ET模型是通过减少系统调用来达到提高并行效率的。

epoll用法

epoll用法epoll是Linux内核提供的一种高效的I/O多路复用机制，可以监视多个文件描述符的状态，并在其中任何一个文件描述符就绪时通知应用程序进行相应的操作。

epoll在高并发网络应用中被广泛应用，它的使用方式也比较灵活，可以根据不同的需求选择不同的模式。

一、epoll概述epoll是Linux内核提供的一种高效的I/O多路复用机制，它可以监视多个文件描述符的状态，当其中任何一个文件描述符就绪时，就会通知应用程序进行相应的操作。

epoll是一种基于事件驱动的I/O模型，它可以同时处理大量的连接，而且不会因为连接数的增加而导致性能下降。

epoll的优点主要有以下几点：1. 高效：epoll采用了红黑树的数据结构，可以快速地定位就绪的文件描述符，而且不会因为连接数的增加而导致性能下降。

2. 灵活：epoll的工作模式有三种，分别是ET模式、LT模式和EPOLLONESHOT模式，可以根据不同的需求选择不同的模式。

3. 可扩展：epoll可以同时处理大量的连接，而且可以动态地增加或删除文件描述符，非常灵活。

二、epoll使用方法1. 创建epoll实例使用epoll需要先创建一个epoll实例，可以通过调用epoll_create函数来创建，该函数的原型如下：int epoll_create(int size);其中，size参数指定epoll实例中红黑树的节点个数，一般可以设置为1024。

该函数调用成功后，返回一个epoll实例的文件描述符，失败则返回-1。

2. 添加文件描述符到epoll实例使用epoll需要将要监视的文件描述符添加到epoll实例中，可以通过调用epoll_ctl函数来实现，该函数的原型如下：int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);其中，epfd参数是epoll实例的文件描述符，op参数指定要进行的操作，可以是EPOLL_CTL_ADD、EPOLL_CTL_MOD或EPOLL_CTL_DEL，fd参数是要添加、修改或删除的文件描述符，event参数是一个epoll_event结构体，用于指定要监视的事件类型，该结构体的定义如下：struct epoll_event {__uint32_t events; // 监控的事件类型epoll_data_t data; // 用户数据};events参数指定要监视的事件类型，可以是EPOLLIN、EPOLLOUT、EPOLLRDHUP、EPOLLERR等，具体含义如下：EPOLLIN：表示文件描述符可读。

探讨epoll原理（红黑树、rdlist的实现）

探讨epoll原理（红⿊树、rdlist的实现）
再谈epoll
原理
关键概念：eventpoll结构体（fd管理器）、ep_poll_callback（回调）、rdlist（双向链表）、epitem（epoll管理的结点）
每个epoll对象都有⼀个独⽴的eventpoll结构体，通过eventpoll管理存放epoll_ctl添加的事件集合，这些事件以epitem为结点挂载到红⿊树上。

添加到epoll中的事件，都会与设备驱动建⽴回调关系，当相应事件发⽣时该回调将事件对应的epitem结点加⼊
rdlist即可；
因此，当⽤户调⽤epoll_wait是指上内核只检查了rdlist是否为空，若⾮空将其拷贝到⽤户态并返回触发事件数量。

可以说：红⿊树+rdlist+回调铸就了epoll的⾼效。

为何⽀持百万并发
不⽤重复传递事件集合
epoll初始化时，内核开辟了epoll缓冲区，缓冲区内事件以epitem结点挂载到红⿊树上，通过epoll_ctl的任何操作都是O(logN)
epoll_wait调⽤仅需观察rdlist是否为空，若⾮空则拷贝rdlist到⽤户空间并返回触发事件数量，⽆需遍历
向内核中断处理注册回调，⼀旦关⼼的事件触发，回调⾃动将socket对应的epitem添加到rdlist中
ET和LT，来⾃电⼦的概念
ET边沿触发：⽆论事件是否处理完毕，仅触发⼀次
LT⽔平触发：只要事件没有处理完毕，每⼀次epoll_wait都触发该事件。

Linux网络编程的5种IO模型：多路复用（select、poll、epoll）

Linux⽹络编程的5种IO模型：多路复⽤（select、poll、epoll）背景我们在上⼀讲中，对于其中的阻塞/⾮阻塞IO 进⾏了说明。

这⼀讲我们来看多路复⽤机制。

IO复⽤模型 ( I/O multiplexing )所谓I/O多路复⽤机制，就是说通过⼀种机制，可以监视多个描述符，⼀旦某个描述符就绪（⼀般是读就绪或者写就绪），能够通知程序进⾏相应的读写操作。

这种机制的使⽤需要额外的功能来配合： select、poll、epollselect、poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后⾃⼰负责进⾏读写，也就是说这个读写过程是阻塞的。

select时间复杂度O(n)它仅仅知道了，有I/O事件发⽣了，却并不知道是哪那⼏个流（可能有⼀个，多个，甚⾄全部），我们只能⽆差别轮询所有流，找出能读出数据，或者写⼊数据的流，对他们进⾏操作。

所以select具有O(n)的⽆差别轮询复杂度，同时处理的流越多，⽆差别轮询时间就越长。

poll时间复杂度O(n)poll本质上和select没有区别，它将⽤户传⼊的数组拷贝到内核空间，然后查询每个fd对应的设备状态，但是它没有最⼤连接数的限制，原因是它是基于链表来存储的.epoll时间复杂度O(1)epoll可以理解为event poll，不同于忙轮询和⽆差别轮询，epoll会把哪个流发⽣了怎样的I/O事件通知我们。

所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。

（复杂度降低到了O(1)）在多路复⽤IO模型中，会有⼀个内核线程不断去轮询多个socket的状态，只有当真正读写事件发⽣时，才真正调⽤实际的IO读写操作。

因为在多路复⽤IO模型中，只需要使⽤⼀个线程就可以管理多个socket，系统不需要建⽴新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有读写事件进⾏时，才会使⽤IO资源，所以它⼤⼤减少了资源占⽤。

Epoll详解

2. 常用模型的缺点
如果不摆出来其他模型的缺点，怎么能对比出Epoll的优点呢。
2.1 PPC/TPC模型
这两种模型思想类似，就是让每一个到来的连接一边自己做事去，别再来烦我。只是P PC是为它开了一个进程，而TPC开了一个线程。可是别烦我是有代价的，它要时间和空间啊，连接多了之后，那么多的进程/线程切换，这开销就上来了；因此这类模型能接受的最大连接数都不会高，一般在几百个左右。
epoll_data_t data;
// User datavariable
};
typedef union epoll_data {
void *ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t; 可见epoll_data是一个union结构体,借助于它应用程序可以保存很多类型的信息:fd、指针等等。有了它，应用程序就可以直接定位目标了。 6. 使用Epoll 既然Epoll相比select这么好，那么用起来如何呢？会不会很繁琐啊…先看看下面的三个函数吧，就知道Epoll的易用了。
3.1. Epoll没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于2048, 一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/filemax察看。 3.2. 效率提升，Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。 3.3. 内存拷贝，Epoll在这点上使用了“共享内存”，这个内存拷贝也省略了。 4. Epoll为什么高效 Epoll的高效和其数据结构的设计是密不可分的，这个下面就会提到。首先回忆一下select模型，当有I/O事件到来时，select通知应用程序有事件到了快去处理，而应用程序必须轮询所有的FD集合，测试每个FD是否有事件发生，并处理事件；代码像下面这样：

简述LinuxEpollET模式EPOLLOUT和EPOLLIN触发时刻

简述LinuxEpollET模式EPOLLOUT和EPOLLIN触发时刻
ET模式称为边缘触发模式，顾名思义，不到边缘情况，是死都不会触发的。

EPOLLOUT事件：
EPOLLOUT事件只有在连接时触发一次，表示可写，其他时候想要触发，那你要先准备好下面条件：
1.某次write，写满了发送缓冲区，返回错误码为EAGAIN。

2.对端读取了一些数据，又重新可写了，此时会触发EPOLLOUT。

简单地说：EPOLLOUT事件只有在不可写到可写的转变时刻，才会触发一次，所以叫边缘触发，这叫法没错的！
其实，如果你真的想强制触发一次，也是有办法的，直接调用epoll_ctl重新设置一下event就可以了，event跟原来的设置一模一样都行（但必须包含EPOLLOUT），关键是重新设置，就会马上触发一次EPOLLOUT事件。

EPOLLIN事件：
EPOLLIN事件则只有当对端有数据写入时才会触发，所以触发一次后需要不断读取所有数据直到读完EAGAIN为止。

否则剩下的数据只有在下次对端有写入时才能一起取出来了。

现在明白为什么说epoll必须要求异步socket了吧？如果同步socket，而且要求读完所有数据，那么最终就会在堵死在阻塞里。

简述一般来说字数不能超过100，不知道这次超过没有~。

nio的三种实现方式：select,poll,epoll

nio的三种实现⽅式：select,poll,epoll参考：建议先看中IO那部分内容select 的⼏⼤缺点：（1）每次调⽤select，都需要把fd集合从⽤户态拷贝到内核态，这个开销在fd很多时会很⼤，内核需要将消息传递到⽤户空间，都需要内核拷贝动作（2）同时每次调⽤select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很⼤（3）select⽀持的⽂件描述符数量太⼩了，默认是单个进程默认是1024pollpoll 的机制与select类似，与select在本质上没有多⼤差别，管理多个描述符也是进⾏轮询，根据描述符的状态进⾏处理，但是因为底层数据结构是链表，所以poll没有最⼤⽂件描述符数量的限制。

poll和select同样存在⼀个缺点就是，1、⼤量的fd的数组被整体复制于⽤户态和内核地址空间之间，⽽不管这样的复制是不是有意义。

2、poll还有⼀个特点是“⽔平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

epoll是在2.6内核中提出的，是之前的select和poll的增强版本。

相对于select和poll来说，epoll更加灵活，没有描述符限制。

epoll使⽤⼀个⽂件描述符管理多个描述符，将⽤户关系的⽂件描述符的事件存放到内核的⼀个事件表中，这样在⽤户空间和内核空间的copy只需⼀次。

如果能给套接字注册某个回调函数，当他们活跃时，⾃动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

epoll的优势对于第⼀个缺点，epoll的解决⽅案在epoll_ctl函数中。

每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，⽽不是在epoll_wait的时候重复拷贝。

epoll保证了每个fd在整个过程中只会拷贝⼀次。

因为epoll通过内核和⽤户空间共享⼀块内存来实现的。

对于第⼆个缺点，epoll的解决⽅案不像select或poll⼀样每次都把current轮流加⼊fd对应的设备等待队列中，⽽只在epoll_ctl时把current挂⼀遍（这⼀遍必不可少）并为每个fd指定⼀个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调⽤这个回调函数，⽽这个回调函数会把就绪的fd加⼊⼀个就绪链表）。

epoll水平触发lt与边缘触发et的原理

epoll水平触发lt与边缘触发et的原理epoll是Linux操作系统提供的一种高效的I/O多路复用机制，它可以同时监控多个文件描述符的状态，从而实现高并发的网络编程。

在epoll中，有两种触发模式，分别是水平触发（Level Triggered，LT）和边缘触发（Edge Triggered，ET）。

水平触发（LT）是epoll的默认触发模式。

在LT模式下，当文件描述符上有可读或可写事件发生时，epoll_wait函数会立即返回，并将该文件描述符加入到就绪队列中，然后程序可以通过遍历就绪队列来处理就绪的文件描述符。

如果程序没有处理完就绪队列中的所有文件描述符，那么下一次调用epoll_wait函数时，仍然会返回这些文件描述符。

边缘触发（ET）是epoll的高级触发模式。

在ET模式下，当文件描述符上有可读或可写事件发生时，epoll_wait函数只会通知一次，即只返回一次该文件描述符。

如果程序没有处理完该文件描述符上的事件，那么下一次调用epoll_wait函数时，不会再返回该文件描述符。

这就要求程序在处理就绪的文件描述符时，要一直处理到没有事件可读或可写为止。

水平触发（LT）的原理是基于状态的变化。

当文件描述符上有可读或可写事件发生时，epoll_wait函数会立即返回，并将该文件描述符加入到就绪队列中。

即使程序没有处理完就绪队列中的所有文件描述符，下一次调用epoll_wait函数时，仍然会返回这些文件描述符。

这种机制保证了程序能够及时处理就绪的文件描述符，但也可能导致频繁的epoll_wait调用，造成一定的性能损耗。

边缘触发（ET）的原理是基于事件的变化。

当文件描述符上有可读或可写事件发生时，epoll_wait函数只会通知一次，即只返回一次该文件描述符。

如果程序没有处理完该文件描述符上的事件，下一次调用epoll_wait函数时，不会再返回该文件描述符。

这种机制要求程序在处理就绪的文件描述符时，要一直处理到没有事件可读或可写为止。

多路复用之epoll总结

IO 多路复用之epoll 总结1、基本知识epoll 是在2.6 内核中提出的，是之前的select 和poll 的增强版本。

相对于select 和poll 来说，epoll 更加灵活，没有描述符限制。

epoll 使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy 只需一次。

2、epoll 接口epoll 操作过程需要三个接口，分别如下：#include <sys/epoll.h>int epoll_create(intsize);int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);（1）int epoll_create(int size);创建一个epoll 的句柄，size 用来告诉内核这个监听的数目一共有多大。

这个参数不同于select()中的第一个参数，给出最大监听的fd+1 的值。

需要注意的是，当创建好epoll 句柄后，它就是会占用一个fd 值，在linux 下如果查看/proc/进程id/fd/，是能够看到这个fd 的，所以在使用完epoll 后，必须调用close()关闭，否则可能导致fd 被耗尽。

（2）int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);epoll 的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件epoll 的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

剖析 epoll ETLT 触发方式的性能差异误解(定性分析)

平时大家使用 epoll 时都知道其事件触发模式有默认的 level-trigger 模式和通过 EPOLLET 启用的 edge-trigger 模式两种。

从 epoll 发展历史来看，它刚诞生时只有 edge-trigger 模式，后来因容易产生 race-cond 且不易被开发者理解，又增加了 level-trigger 模式并作为默认处理方式。

二者的差异在于 level-trigger 模式下只要某个 fd 处于 readable/writable 状态，无论什么时候进行 epoll_wait 都会返回该 fd；而 edge-trigger 模式下只有某个 fd 从 unreadable 变为 readable 或从 unwritable 变为writable 时，epoll_wait 才会返回该 fd。

通常的误区是：level-trigger 模式在 epoll 池中存在大量 fd 时效率要显著低于 edge-trigger 模式。

但从 kernel 代码来看，edge-trigger/level-trigger 模式的处理逻辑几乎完全相同，差别仅在于 level-trigger 模式在 event 发生时不会将其从 ready list 中移除，略为增大了 event 处理过程中 kernel space 中记录数据的大小。

然而，edge-trigger 模式一定要配合 user app 中的 ready list 结构，以便收集已出现 event 的 fd，再通过 round-robin 方式挨个处理，以此避免通信数据量很大时出现忙于处理热点 fd 而导致非热点 fd 饿死的现象。

统观kernel 和 user space，由于 user app 中 ready list 的实现千奇百怪，不一定都经过仔细的推敲优化，因此 edge-trigger 的总内存开销往往还大于level-trigger 的开销。

epoll边缘触发实现原理

epoll边缘触发实现原理epoll是Linux操作系统提供的一种高效的I/O事件通知机制，它能够监控文件描述符上的I/O事件并通知应用程序进行相应的处理。

而边缘触发是epoll的一种工作模式，它与水平触发相比，具有更高的触发效率和更低的资源消耗。

在理解epoll边缘触发的实现原理之前，我们先来了解一下什么是epoll。

epoll是Linux内核提供的一种多路复用I/O模型，它可以同时监控多个文件描述符，当某个文件描述符就绪时，便会触发相应的事件。

与传统的select和poll相比，epoll具有更高的性能和扩展性。

epoll的实现原理是通过内核维护一个事件表，将需要监控的文件描述符添加到事件表中。

当一个文件描述符上有I/O事件发生时，内核会将相应的事件添加到就绪队列中，并唤醒等待该事件的应用程序。

应用程序可以通过epoll_wait系统调用来等待事件的发生，并获得就绪的文件描述符。

在epoll中，有两种工作模式：水平触发（Level Triggered，简称LT）和边缘触发（Edge Triggered，简称ET）。

水平触发是指当一个文件描述符上有可读或可写事件发生时，epoll_wait会立即返回，并将该文件描述符添加到就绪队列中。

此时，应用程序需要反复调用epoll_wait来处理该文件描述符上的所有事件，直到没有事件为止。

边缘触发是指当一个文件描述符上有可读或可写事件发生时，epoll_wait只会通知应用程序一次，并且只有在下一次epoll_wait 调用时，才会再次通知应用程序。

这意味着应用程序需要在每次epoll_wait调用后，立即处理所有就绪的文件描述符，并确保在下一次调用epoll_wait之前，该文件描述符上的事件已经处理完毕。

否则，下一次epoll_wait调用时，该文件描述符上的事件将被忽略。

通过边缘触发的工作模式，可以大大减少epoll_wait系统调用的次数，提高应用程序的触发效率。

EPOLL的ET和LT模式

EPOLL的ET和LT模式EPOLL的ET和LT模式近日又继续学习了一下EPOLL的工作模式，这会基本上搞清楚了，因而撰写了此篇文档进行描述。

先来一段网上的介绍文档：EPOLL事件分发系统可以运转在两种模式下：Edge Triggered (ET)、Level Triggered (LT)。

LT是缺省的工作方式，并且同时支持block和no-block socket；在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。

如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。

传统的select/poll 都是这种模型的代表。

ET是高速工作方式，只支持no-block socket。

在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。

然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了。

但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知。

后面才是我想说的内容，既然ET模式是高速模式，那我们进行服务器开发是一定要使用的了，可是查遍文档，也没有找到ET模式的设置方法，到底如何设置和使用呢？通过反复测试，终于搞明白“EPOLLET”就是ET模式的设置了，也许是我太笨所以才迷惑这么久了，以下就是将TCP套接字hSocket和epoll关联起来的代码：struct epoll_event struEvent;struEvent.events = EPOLLIN | EPOLLOUT | EPOLLET;struEvent.data.fd = hSocket;epoll_ctl(m_hEpoll, EPOLL_CTL_ADD, hSocket, &struEvent);如果将监听套接字m_hListenSocket和epoll关联起来，则代码如下:struct epoll_event struEvent;struEvent.events = EPOLLIN | EPOLLET;struEvent.data.fd = m_hListenSocket;epoll_ctl(m_hEpoll, EPOLL_CTL_ADD, m_hListenSocket, &struEvent);如果想使用LT模式，直接把事件的赋值修改为以下即可，也许这就是缺省的意义吧。

epoll水平边缘触发代码

epoll水平边缘触发代码在Linux中，epoll是一种高效的I/O事件通知机制，它允许程序监视多个文件描述符，以便在它们变得可读、可写或异常时得到通知。

epoll有两种工作模式：边缘触发（ET）和水平触发（LT）。

1.水平触发（LT）模式：只要有数据到来，就触发事件，可能后面还会有更多数据。

2.边缘触发（ET）模式：只有在数据真正变化（比如，从无到有，或者从有到无）时才触发事件。

下面是一个使用epoll的边缘触发模式的C代码示例：c#include <stdio h>#include <stdlib h>#include <string h>#include <unistd h>#include <sys/epoll h>#include <fcntl h>#include <errno h>#define MAX EVENTS 1000#define BUFFER SIZE 1024int main() {int epoll fd, nfds;struct epoll event ev, events[MAX EVENTS];char buffer[BUFFER SIZE];int fd;int i;// 创建epoll文件描述符if ((epoll fd = epoll create(MAX EVENTS)) == -1) {perror("epoll create");exit(EXIT FAILURE);}// 添加监听的文件描述符，并设置边缘触发模式ev events = EPOLLIN; // EPOLLIN表示我们关心的是文件描述符上的可读事件ev data fd = fd; // fd是我们要监听的文件描述符，这里我们假设fd为已经打开的文件描述符的编号。

ev data ptr = NULL; // data ptr通常用于指向更复杂的数据结构，这里我们不使用它。

Linuxc++（socket网络通信epoll的三种模式）

Linuxc++（socket⽹络通信epoll的三种模式）默认：⽔平触发模式 - 根据读来解释只要fd对应的缓冲区有数据epoll_wait返回返回的次数与发送数据的次数没有关系epoll默认的⼯作模式ET: 边沿触发模式客户端给server发数据发⼀次数据server的epoll——wait返回⼀次不在乎诗句是否读完// 将新的到的cfd挂到树上struct epoll_event temp;// 设置边沿触发temp.events = EPOLLIN | EPOLLET;temp.data.fd = cfd;epoll_ctl(epfd,EPOLL_CTL_ADD,cfd,&temp);边沿⾮阻塞触发效率最⾼如何设置⾮阻塞open()设置flags必须O_WDRW|O_NONBLOCK终端⽂件: /dev/ttyfcntlint flag = fcntl(fd,F_GETFL);flag |=O_NONBLOCK;fcntl(fd,F_SETFL,flag);将缓冲区的全部数据读出while（recv() > 0){printf();}边沿⾮阻塞代码⽰例#include <stdio.h>#include <sys/types.h>#include <arpa/inet.h>#include <string.h>#include <stdlib.h>#include <unistd.h>#include <sys/epoll.h>#include <fcntl.h>#include <errno.h>int main(int argc,char *argv[]){if(argc< 2){printf("eg: ./app port");exit(1);}int port = atoi(argv[1]);struct sockaddr_in serv_addr;socklen_t serv_len = sizeof(serv_addr);//创建套接字int lfd = socket(AF_INET,SOCK_STREAM,0);//初始化服务器memset(&serv_addr,0,serv_len);serv_addr.sin_family = AF_INET;serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);serv_addr.sin_port = htons(port);//绑定IP和端⼝bind(lfd,(struct sockaddr*)&serv_addr,serv_len);//设置同时监听的最⼤个数listen(lfd,36);printf("Start accept......\n");struct sockaddr_in client_addr;socklen_t cli_len = sizeof(client_addr);// 创建epoll树根节点int epfd = epoll_create(2000);// 初始化树struct epoll_event ev;ev.events = EPOLLIN;ev.data.fd = lfd;epoll_ctl(epfd,EPOLL_CTL_ADD,lfd,&ev);struct epoll_event all[2000];while(1){// 使⽤epoll通知内核fd ⽂件IO检测int ret = epoll_wait(epfd,all,sizeof(all)/sizeof(all[0]),-1);// 便利all数组中的前ret个元素for(int i = 0;i<ret;++i){int fd = all[i].data.fd;// 判断是否有新链接if(fd == lfd){int cfd = accept(lfd,(struct sockaddr*)&client_addr,&cli_len); if (cfd == -1) {perror("accept error");exit(1);}// 设置⽂件cfd为⾮阻塞模式int flag = fcntl(cfd,F_GETFL);flag |= O_NONBLOCK;fcntl(cfd,F_SETFL);// 将新的到的cfd挂到树上struct epoll_event temp;temp.events = EPOLLIN | EPOLLET;temp.data.fd = cfd;epoll_ctl(epfd,EPOLL_CTL_ADD,cfd,&temp);}else{// 处理已经链接的客户端发送过来的数据if(!all[i].events & EPOLLIN)continue;// 读数据char buf[1024] = {0};int len;while((len =recv(fd,buf,sizeof(buf),0))> 0){// 数据打印到终端write(STDOUT_FILENO,buf,len);// 发送给客户端send(fd,buf,len,0);}if(len == 0){printf("client disconnected ......\n");// 将fd从树上栽下ret = epoll_ctl(epfd,EPOLL_CTL_DEL,fd,NULL);if (ret == -1) {perror("epoll_ctl - del error");exit(1);}close(fd);}else if(len < 0){if(errno == EAGAIN){printf("缓冲区数据已经读完\n");}else{perror("recv error");exit(1);}}#if 0if(len < 0){}else if(len == 0){}else{printf("recv %s\n",buf);send(fd,buf,len,0);}#endif}}}close(lfd);return 0;}。

Epoll-水平触发和边缘触发

Epoll-⽔平触发和边缘触发EPOLL事件有两种模型：Level Triggered (LT) ⽔平触发.socket接收缓冲区不为空有数据可读读事件⼀直触发.socket发送缓冲区不满可以继续写⼊数据写事件⼀直触发符合思维习惯，epoll_wait返回的事件就是socket的状态Edge Triggered (ET) 边沿触发.socket的接收缓冲区状态变化时触发读事件，即空的接收缓冲区刚接收到数据时触发读事件.socket的发送缓冲区状态变化时触发写事件，即满的缓冲区刚空出空间时触发读事件仅在状态变化时触发事件ET还是LT?LT的处理过程：. accept⼀个连接，添加到epoll中监听EPOLLIN事件. 当EPOLLIN事件到达时，read fd中的数据并处理. 当需要写出数据时，把数据write到fd中；如果数据较⼤，⽆法⼀次性写出，那么在epoll中监听EPOLLOUT事件. 当EPOLLOUT事件到达时，继续把数据write到fd中；如果数据写出完毕，那么在epoll中关闭EPOLLOUT事件ET的处理过程：. accept⼀个⼀个连接，添加到epoll中监听EPOLLIN|EPOLLOUT事件. 当EPOLLIN事件到达时，read fd中的数据并处理，read需要⼀直读，直到返回EAGAIN为⽌. 当需要写出数据时，把数据write到fd中，直到数据全部写完，或者write返回EAGAIN. 当EPOLLOUT事件到达时，继续把数据write到fd中，直到数据全部写完，或者write返回EAGAIN从ET的处理过程中可以看到，ET的要求是需要⼀直读写，直到返回EAGAIN，否则就会遗漏事件。

⽽LT的处理过程中，直到返回EAGAIN 不是硬性要求，但通常的处理过程都会读写直到返回EAGAIN，但LT⽐ET多了⼀个开关EPOLLOUT事件的步骤LT的编程与poll/select接近，符合⼀直以来的习惯，不易出错ET的编程可以做到更加简洁，某些场景下更加⾼效，但另⼀⽅⾯容易遗漏事件，容易产⽣bug这⾥有两个简单的例⼦演⽰了LT与ET的⽤法(其中epoll-et的代码⽐epoll要少10⾏)：https:///yedf/handy/blob/master/raw-examples/https:///yedf/handy/blob/master/raw-examples/针对容易触发LT开关EPOLLOUT事件的情景（让服务器返回1M⼤⼩的数据），我⽤ab做了性能测试测试的结果显⽰ET的性能稍好，详情如下：LT 启动命令 ./epoll aET 启动命令 ./epoll-et aab 命令：ab -n 1000 -k 127.0.0.1/LT 结果：Requests per second: 42.56 [#/sec] (mean)ET 结果：Requests per second: 48.55 [#/sec] (mean)当我把服务器返回的数据⼤⼩改为48576时，开关EPOLLOUT更加频繁，性能的差异更⼤ab 命令：ab -n 5000 -k 127.0.0.1/LT 结果：Requests per second: 745.30 [#/sec] (mean)ET 结果：Requests per second: 927.56 [#/sec] (mean)对于nginx这种⾼性能服务器，ET模式是很好的，⽽其他的通⽤⽹络库，更多是使⽤LT，避免使⽤的过程中出现bug---------------------作者：dongfuye来源：CSDN原⽂：https:///dongfuye/article/details/50880251版权声明：本⽂为博主原创⽂章，转载请附上博⽂链接！。