Epoll原理详解

最新推荐文章于 2025-09-11 16:47:23 发布
原创 最新推荐文章于 2025-09-11 16:47:23 发布 · 1k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#服务器 #网络

Epoll是Linux下的一种高效I/O事件通知机制，它通过就绪列表优化了对大量文件描述符的监控。与select不同，Epoll在边缘触发(ET)和水平触发(LT)模式下工作，其中LT模式是默认且更易用的，而ET模式可能导致处理热点fd时其他fd被饿死，需要配合用户空间的策略。文章指出，两种模式的性能差异主要体现在epoll_wait的处理速度，实际应用中应根据场景选择合适模式。

工作队列和等待队列

工作队列指处在运行态的进程排成的队列
等待队列指一些对此socket感兴趣的进程组成的队列，事实上这个队列只是对进程的引用，当socket可读或可写时，会唤醒等待队列中的进程

当进程A运行了socket，操作系统会创建一个由文件系统管理的socket对象
这个socket对象包含了发送缓冲区、接收缓冲区与等待队列等成员。等待队列是个非常重要的结构，它指向所有需要等待该socket事件的进程。
当程序执行到recv时，操作系统会将进程 A 从工作队列移出，将进程A的引用添加到该socket的等待队列中

在这里插入图片描述

Epoll设计思路

在这里插入图片描述

  • 相比与select，epoll不会再每次都需要重添加队列再进行epoll_wait
  • select需要每次将集合数据从用户态拷贝到内核态进行监控
  • 当有socket可读可写时，select还需要遍历fd集合。epoll采用就绪列表，不用遍历

epoll原理

如下图所示，当某个进程调用epoll_create 方法时，内核会创建一个 eventpoll 对象（也就是程序中 epfd 所代表的对象）。eventpoll 对象也是文件系统中的一员，和socket一样，它也会有等待队列，创建此eventpoll的进程会被添加到此等待队列
如果进程通过epoll监视sock1，2，3，就会将eventepoll加入到三个socket的等待队列

在这里插入图片描述
当socket收到数据后，中断程序会操作 eventpoll 对象，而不是直接操作进程。
在这里插入图片描述
当socket收到数据后，中断程序会给 eventpoll 的**“就绪列表”**添加socket引用。
在这里插入图片描述
因此当某个加入epoll的socket可读可写后，内核会将此socket加入到epoll的rdlist，并通知epoll的等待队列上的进程

LT与ET

平时大家使用 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 的开销。
一般号称 edge-trigger 模式的优势在于能够减少 epoll 相关系统调用，这话不假，但 user app 里可不是只有 epoll 相关系统调用吧？为了绕过饿死问题，edge-trigger 模式的 user app 要自行进行 read/write 循环处理，这其中增加的系统调用和减少的 epoll 系统调用加起来，有谁能说一定就能明显地快起来呢？
实际上，epoll_wait 的效率是 O(ready fd num) 级别的，因此 edge-trigger 模式的真正优势在于减少了每次 epoll_wait 可能需要返回的 fd 数量，在并发 event 数量极多的情况下能加快 epoll_wait 的处理速度，但别忘了这只是针对 epoll 体系自己而言的提升，与此同时 user app 需要增加复杂的逻辑、花费更多的 cpu/mem 与其配合工作，总体性能收益究竟如何？只有实际测量才知道，无法一概而论。不过，为了降低处理逻辑复杂度，常用的事件处理库大部分都选择了 level-trigger 模式（如 libevent、boost::asio等）
结论：
•epoll 的 edge-trigger 和 level-trigger 模式处理逻辑差异极小，性能测试结果表明常规应用场景 中二者性能差异可以忽略。
•使用 edge-trigger 的 user app 比使用 level-trigger 的逻辑复杂，出错概率更高。
•edge-trigger 和 level-trigger 的性能差异主要在于 epoll_wait 系统调用的处理速度，是否是 user app 的性能瓶颈需要视应用场景而定，不可一概而论

世界和平~
关注
Linux下的socket编程实践（九） epoll实现高并发的原理及其使用
NK_test的博客
10-22 9495
在 linux 没有实现 epoll 事件驱动机制之前，我们一般选择用 selec t或者 poll 等IO多路复用的方法来实现并发服务程序（详见此链接）。在大数据、高并发、集群等一些名词唱得火热之年代，select 和 poll的用武之地越来越有限，风头已经被 epoll 占尽。  本文便来介绍 epoll 的实现机制，并通过对比其不同的实现机制，真正理解为何 epoll 能实现高并发
【计算机网络】IO多路转接之epoll
qq_67582098的博客
03-06 1894
【计算机网络】IO多路转接之epoll
epoll详细工作原理.docx
04-29
epoll详细工作原理.docx
深入理解 epoll：从原理到实践的全方位剖析
最新发布
2401_86353562的博客
09-11 737
本文深入解析Linux高效I/O多路复用技术epoll的核心原理与应用。文章首先对比了select/poll/epoll三代的演进过程，指出epoll通过红黑树+就绪链表的数据结构设计，解决了FD数量限制、线性遍历和频繁拷贝等性能瓶颈。详细剖析了epoll_create/ctl/wait三个系统调用的实现机制，以及LT/ET两种触发模式的特点与适用场景。通过TCP服务器示例代码展示了epoll的完整使用流程，并给出最佳实践建议：监听socket采用LT模式，客户端连接使用ET+非阻塞IO；正确处理ET模式下
linux下epoll如何实现高效处理百万句柄的
yiyeqinghuasoon
01-06 2000
开发高性能网络程序时，windows开发者们言必称iocp，linux开发者们则言必称epoll。大家都明白epoll是一种IO多路复用技术，可以非常高效的处理数以百万计的socket句柄，比起以前的select和poll效率高大发了。我们用起epoll来都感觉挺爽，确实快，那么，它到底为什么可以高速处理这么多并发连接呢？ 先简单回顾下如何使用C库封装的3个epoll系统调用吧。 in...
Epoll的本质（内部实现原理）
k916631305的博客
11-06 1870
转自：https://zhuanlan.zhihu.com/p/63179839 作者：罗培羽 从事服务端开发，少不了要接触网络编程。epoll作为linux下高性能网络服务器的必备技术至关重要，nginx、redis、skynet和大部分游戏服务器都使用到这一多路复用技术。 因为epoll的重要性，不少游戏公司（如某某九九）在招聘服务端同学时，可能会问及epoll相关的问题。比如epoll和select的区别是什么？epoll高效率的原因是什么？如果只靠背诵，显然不能算上深刻的理解。 网上虽.
Epoll原理解析
u013328965的博客
04-06 1469
从事服务端开发，少不了要接触网络编程。Epoll 作为 Linux 下高性能网络服务器的必备技术至关重要，Nginx、Redis、Skynet 和大部分游戏服务器都使用到这一多路复用技术。 Epoll 很重要，但是 Epoll 与 Select 的区别是什么呢?Epoll 高效的原因是什么? 网上虽然也有不少讲解 Epoll 的文章，但要么是过于浅显，或者陷入源码解析，很少能有通俗易懂的。 笔者于是决定编写此...
Linux网络编程——epoll原理详解及epoll反应堆模型
qq_74811378的博客
11-25 2608
设想一个场景：有100万用户同时与一个进程保持着TCP连接，而每一时刻只有几十个或几百个TCP连接是活跃的(接收TCP包)，也就是说在每一时刻进程只需要处理这100万连接中的一小部分连接。那么，如何才能高效的处理这种场景呢？进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出其中有事件发生的几百个连接呢？实际上，在Linux2.4版本以前，那时的select或者poll事件驱动方式是这样做的。
【Linux | IO多路复用】epoll的底层原理详解
qq_42037383的博客
10-26 1669
epoll是一种高效的 I/O 多路复用机制，广泛用于 Linux 系统中，用于处理大量并发的文件描述符。它比传统的select和poll方法具有更好的性能，特别是在处理大量并发连接时。
epoll详细工作原理
ylx1066863710的博客
12-21 2548
开发高性能网络程序时，windows开发者们言必称iocp，linux开发者们则言必称epoll。大家都明白epoll是一种IO多路复用技术，可以非常高效的处理数以百万计的socket句柄，比起以前的select和poll效率高大发了。我们用起epoll来都感觉挺爽，确实快，那么，它到底为什么可以高速处理这么多并发连接呢？ 先简单回顾下如何使用C库封装的3个epoll系统调用吧。 [cpp] view plaincopy int epoll_create(int size); int epoll_ctl
epoll详解
2301_80105928的博客
08-12 3344
epoll的起源：epoll 是Linux内核中的一种I/O事件通知机制。它是 select 和 poll 这两个系统调用的增强版本，专为处理大量文件描述符而设计，特别是在需要高并发处理的应用程序中，如网络服务器和分布式系统。他的起源可以追溯到21世纪初，当时Linux系统在处理大量并发连接时遇到了性能瓶颈。select 和 poll 方法的性能随着文件描述符数量的增加而线性下降，因为它们需要检查每个文件描述符的状态。为了解决这个问题，Linux内核引入了 epoll。
Epoll 反应堆模型核心原理及代码讲解
weixin_47826078的博客
06-08 934
epoll反应堆模型的三个要素：epoll ET模式非阻塞轮询处理结构体中联合体中的指针 – 实现回调机制socket、bind、listen – epoll_create 创建监听 红黑树 – 返回 epfdepoll_ctl() 向红黑树上添加一个listenfd（监听socket）while(1) {【可选】每轮迭代监测100个连接，若存在超时连接（沉积用户）则主动关闭； 监听 --> 对应监听fd有事件产生 --> 返回监听满足结构集 （即结构体数组）；判断返回数组元素 :}
epoll的实现原理
RTC hacker
12-11 1619
<br />epoll与select/poll不同的一点是，它是由一组系统调用组成。<br />     int epoll_create(int size);<br />     int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);<br />     int epoll_wait(int epfd, struct epoll_event *events,<br />                       int ma
图文并茂讲解epoll原理，彻底弄懂epoll机制
m0_60259116的博客
11-10 9439
图文并茂讲解epoll原理，彻底弄懂epoll机制
【epoll原理详解】
Sugar_wolf的博客
06-21 366
【epoll原理详解】
epoll原理
佛系程序猿
05-08 1259
转载地址：https://www.cnblogs.com/pluser/p/epoll_principles.htmlepoll原理设想一个场景：有100万用户同时与一个进程保持着TCP连接，而每一时刻只有几十个或几百个TCP连接是活跃的(接收TCP包)，也就是说在每一时刻进程只需要处理这100万连接中的一小部分连接。那么，如何才能高效的处理这种场景呢？进程是否在每次询问操作系统收集有事件发生的T...
epoll的工作原理
qq_18883663的博客
11-05 819
epoll作为服务器搭建时不同于多线程/进程/协程方式的原因是 （1）epoll实现了单进程，单进程，不堵塞服务器。对于资源占用是最小的 和协程中gevent的原理类似 （2）工作原理为在进程内存空间和Kernel操作系统内存空间中开辟了一个新的内存空间。这个内存空间用来存储浏览器客户端的访问网络套接字。进程和操作系统都可以访问。优化在于原来的访问列表中客户端服务的套接字列表需要先拷贝到操作系统的...
epoll原理与应用详解
tianmo2010的专栏
01-14 2503
epoll简介 epoll 是Linux内核中的一种可扩展IO事件处理机制，最早在 Linux 2.5.44内核中引入，可被用于代替POSIX select 和 poll 系统调用，并且在具有大量应用程序请求时能够获得较好的性能（ 此时被监视的文件描述符数目非常大，与旧的 select 和 poll 系统调用完成操作所需 O(n) 不同， epoll能在O(1)时间内完成操作，所以性能相
epoll用法详解
03-23
<think>好的，用户之前询问了select的用法，现在又想知道epoll的详解。首先，我需要确认用户对I/O多路复用已经有一定了解，可能是在学习网络编程或者高并发服务器开发。用户可能在使用select时遇到了性能瓶颈，或者听说epoll更高效，所以想深入了解。 接下来，我需要比较select和epoll的不同，突出epoll的优势。用户可能关心epoll如何解决select的问题，比如文件描述符数量限制和效率问题。要详细解释epoll的三个主要函数：epoll_create、epoll_ctl和epoll_wait，以及它们的参数和使用方法。 用户可能对边缘触发（ET）和水平触发（LT）的区别不太清楚，这部分需要重点说明，并举例说明如何正确处理这两种模式。特别是ET模式下的注意事项，比如必须循环读取数据直到EAGAIN错误，避免数据未处理完的情况。 还要考虑用户的实际应用场景，比如如何在一个简单的TCP服务器中使用epoll。需要给出代码示例，但要注意不要过于复杂，保持伪代码的简洁性，同时覆盖关键步骤，如创建epoll实例、注册事件、处理就绪事件等。 另外，用户可能对epoll的性能优势感兴趣，需要解释其背后的原理，比如使用红黑树管理描述符和就绪列表，减少内核和用户空间的拷贝开销。同时，对比epoll与select、poll的差异，帮助用户全面理解。 最后，提醒用户epoll的适用场景和注意事项，比如在Linux下的专有性，以及在高并发环境下的优势。可能用户需要根据项目需求选择合适的多路复用机制，因此提供对比表格会有帮助，但之前的回复中已经有一个对比表格，这里可以适当调整或补充。 需要确保语言清晰，结构合理，步骤详细，避免技术术语过多，但又要准确。检查是否有遗漏的重要点，比如epoll的事件类型（EPOLLIN、EPOLLOUT等），错误处理，以及非阻塞IO的必要性，特别是在ET模式下的应用。确保回答覆盖了用户可能需要的所有关键信息，同时引导用户根据实际情况选择合适的技术。</think>### I/O多路复用中 `epoll` 用法详解 #### 一、核心概念 `epoll` 是Linux特有的**高效I/O多路复用**机制，针对 `select`/`poll` 的缺陷设计，可处理百万级并发连接。核心特性： - **事件驱动**：仅关注活跃的文件描述符（fd），避免无效遍历。 - **红黑树管理fd**：增删改查时间复杂度$O(\log n)$。 - **就绪列表**：内核通过回调机制维护就绪事件列表，无需全量扫描。 --- #### 二、核心函数 1. **`epoll_create`** 创建epoll实例，返回一个文件描述符（epfd）： ```c #include <sys/epoll.h> int epoll_create(int size); // size已废弃（>0即可），返回epfd ``` 2. **`epoll_ctl`** 管理监控的fd（增、删、改）： ```c int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); ``` - **`op` 操作类型**： - `EPOLL_CTL_ADD`：注册新fd - `EPOLL_CTL_MOD`：修改已有fd的监听事件 - `EPOLL_CTL_DEL`：删除fd - **`event` 结构体**： ```c struct epoll_event { uint32_t events; // 监听的事件类型（EPOLLIN/EPOLLOUT等） epoll_data_t data; // 用户数据（常存储fd或指针） }; ``` 3. **`epoll_wait`** 等待事件就绪，返回就绪事件数量： ```c int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); ``` - `events`：输出参数，存储就绪事件数组。 - `maxevents`：数组长度（需预分配）。 --- #### 三、事件类型详解 | 事件类型 | 说明 | |------------------|----------------------------------------------------------------------| | `EPOLLIN` | 数据可读（包括新连接、客户端数据到达） | | `EPOLLOUT` | 数据可写（通常用于非阻塞写操作） | | `EPOLLERR` | 发生错误（自动监听，无需显式设置） | | `EPOLLHUP` | 对端关闭连接（如TCP FIN） | | `EPOLLET` | **边缘触发（Edge-Triggered）模式**（默认水平触发：Level-Triggered） | --- #### 四、使用步骤（以TCP服务器为例） 1. **创建epoll实例** ```c int epfd = epoll_create(1); // size=1足够 ``` 2. **注册监听套接字** ```c struct epoll_event ev; ev.events = EPOLLIN; // 监听可读事件（新连接） ev.data.fd = listen_fd; // 存储监听套接字 epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); ``` 3. **事件循环** ```c #define MAX_EVENTS 64 struct epoll_event events[MAX_EVENTS]; while(1) { int nready = epoll_wait(epfd, events, MAX_EVENTS, -1); // 阻塞等待 for (int i = 0; i < nready; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 int client_fd = accept(listen_fd, ...); ev.events = EPOLLIN | EPOLLET; // 边缘触发模式 ev.data.fd = client_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev); } else { // 处理客户端数据 if (events[i].events & EPOLLIN) { char buf[1024]; int n = read(events[i].data.fd, buf, sizeof(buf)); // 处理读到的数据... } } } } ``` --- #### 五、触发模式对比 | 特性 | 水平触发（LT） | 边缘触发（ET） | |---------------------|------------------------------------------------|------------------------------------------------| | **数据未读完时的行为** | 下次调用`epoll_wait`仍会通知 | 仅通知一次，需一次性处理完数据 | | **非阻塞IO必要性** | 可配合阻塞IO使用 | **必须使用非阻塞IO**，循环读取直到`EAGAIN`错误 | | **适用场景** | 简单场景，容错性高 | 高性能场景，需减少事件触发次数 | **ET模式注意事项**： 必须循环读取数据直到返回`EAGAIN`错误，否则可能丢失数据： ```c // ET模式下读取数据的典型写法 while (1) { int n = read(fd, buf, size); if (n > 0) { // 处理数据... } else if (n == 0) { // 连接关闭 close(fd); break; } else if (errno == EAGAIN) { // 数据已读完 break; } else { // 错误处理 perror("read"); break; } } ``` --- #### 六、性能优势原理 1. **减少数据拷贝** `select`/`poll`每次调用需向内核传递全量fd集合，`epoll`通过`epoll_ctl`预先注册，仅传递就绪事件。 2. **时间复杂度优化** - 增删改fd：$O(\log n)$（红黑树） - 事件就绪检查：$O(1)$（就绪链表） --- #### 七、适用场景 - 高并发服务器（如Web服务器、即时通讯系统） - 需要处理长连接且连接数巨大的场景 - 对延迟敏感的应用（如游戏服务器） --- #### 八、与`select`/`poll`对比 | 特性 | select/poll | epoll | |---------------------|--------------------------|---------------------------| | 最大fd数量 | 有限（默认1024） | 仅受系统内存限制 | | 事件通知效率 | 遍历全部fd（$O(n)$） | 仅返回就绪事件（$O(1)$） | | 内存操作开销 | 每次全量拷贝到内核 | 内核直接管理fd | | 适用场景 | 低并发、跨平台需求 | 高并发、Linux专属 | --- #### 九、注意事项 1. **ET模式必须使用非阻塞fd** 避免因未读完数据导致线程阻塞。 2. **正确处理EPOLLERR和EPOLLHUP** 即使未注册这些事件，内核也会自动通知。 3. **避免频繁调用`epoll_ctl`** 批量操作可提升性能（如使用`EPOLLONESHOT`标志）。 --- `epoll` 是Linux高性能网络编程的核心工具，合理使用其特性（如ET模式、非阻塞IO）可显著提升服务器吞吐量。在实际开发中需结合具体业务场景选择触发模式，并严格遵循最佳实践以避免潜在问题。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值