一、为什么出现Epool？---历史背景

在epool之前，Linux下有select和pool这两种I/O多路复用机制。但他们都有共同的、需要克服的性能瓶颈。

1.线性扫描：每次调用select/pool，都需要将进程关注的所有文件描述符集合从用户空间完整的拷贝到内核空间。

2.内核线性扫描：内核需要遍历整个传入的集合，检查每个文件描述符是否有I/O事件就绪。

3.返回整个集合：调用返回时，内核会将一个包含“就绪”和“未就绪”文件描述的集合完整的拷贝回用户空间。

4.用户空间线性扫描：用户进程需要再次遍历整个返回的集合，才能知道哪些描述符真正就绪了。

核心问题：当需要监听的连接数非常大时，每次调用两次拷贝和两次此遍历开销巨大，影响性能。

二、Epool的核心工作原理：三个系统调用

epool通过三个核心的系统调用来工作：epool_create  epool_ctl  epool_wait。

1. epoll_create- 创建 epoll 实例

int epfd = epoll_create1(0); // 推荐使用 epoll_create1(0)，flags 参数为 0

作用是 ：在内核中创建一个epool实例。

这个实例内部有两个关键的数据结构：

• 红黑树：用于存储进程想要监听的所有文件描述符。红黑树保证了在大量文件描述符下，增、删、改操作的效率。
• 就绪链表：一个双向链表，用于存储那些I/O事件已经就绪的文件描述符。
• 返回值：epfd时一个指向该内核数据结构的文件描述符。

2. epoll_ctl- 管理兴趣列表

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

作用：向epool实例（epfd）添加、修改或删除需要监听的文件描述符及其事件。相当于在编辑"监视清单"。

参数：

• op：操作类型：EPOLL_CTL_ADD（添加），EPOLL_CTL_MOD（修改），EPOLL_CTL_DEL（删除）。
• fd：要操作的文件描述符
• event：告诉内核你对这个fd的什么事件感兴趣。

工作流程（关键步骤）：

当你使用 EPOLL_CTL_ADD添加一个 fd时，内核会：

1.将这个fd和其关注的事件插入到红黑树中。

2.同时，内核回味这个fd注册一个回调函数。当这个fd对应的网络事件发生时，网卡驱动会中断CPU，内核协议栈处理完数据后，就会调用这个回调函数。

3.这个回调函数的作用是：将当前就绪的fd添加到就绪链表中。

这是epool高效的核心：通过回调机制，内核主动将就绪的fd加入列表，而不是像pool和select那样被动地去遍历查找。

3. epoll_wait- 等待事件发生

int nfds = epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

• 作用：这是阻塞（或超时等待）调用，用于收集在 epoll实例中已经就绪的 I/O 事件。它是程序的“等待中心”。

• 参数：

  • events: 一个由用户程序分配的数组，用于接收就绪的事件。

  • maxevents: 指定 events数组的大小，告诉内核最多返回多少个事件。

工作流程（极其高效）：

1. 调用 epoll_wait时，内核只需检查就绪链表是否为空。

2. 如果链表不为空，说明有事件就绪。内核将就绪链表中的事件复制到用户提供的 events数组中。

3. 如果链表为空，进程会进入睡眠（阻塞），直到超时或有事件就绪后被唤醒。

四、Epoll 的两种触发模式 (Trigger Mode)

这是 epoll的另一个关键特性，通过 epoll_ctl的 event.events字段设置（如 EPOLLIN | EPOLLET）。

1. 水平触发 (Level-Triggered, LT) - 默认模式

• 工作方式：只要文件描述符对应的读/写缓冲区处于非空/非满的状态，epoll_wait就会持续通知你。

• 比喻：一个水杯里的水位只要高于某个刻度（可读），传感器就会一直亮着灯提醒你。

• 优点：编程更简单，不容易遗漏事件。即使你一次没有读完所有数据，下次调用 epoll_wait还会提醒你。

• 注意：在写的时候，如果发送缓冲区未满，会一直触发可写事件，需要妥善处理，否则会导致高CPU占用。

2. 边缘触发 (Edge-Triggered, ET)

• 工作方式：只有当文件描述符的状态发生变化时（比如从不可读变为可读，或从不可写变为可写），epoll_wait才会通知你一次。

• 比喻：只有在水位超过刻度线的那一刻，传感器才亮一下灯，之后水位再高也不会亮了，除非水位曾低于刻度线然后又涨上来。

• 优点：事件通知次数更少，效率更高，尤其适合支持高并发、需要精细控制 I/O 的场景。

• 编程要求（非常关键！）：

  1. 必须使用非阻塞 I/O：这是硬性要求。

  2. 必须一次性读完或写完：当 epoll_wait通知你一个 fd可读时，你必须循环读取，直到 read返回 EAGAIN或 EWOULDBLOCK错误（表示本次通知的数据已读完）。否则，剩下的数据将不会再触发新的事件，直到对端发送了新数据（状态再次变化）。

选择建议：

• LT 模式更简单安全，是默认选择。

• ET 模式性能理论上更高，但对代码逻辑要求严格，是高性能服务器的常用选择。

---

总结

epoll的工作原理可以概括为：

1. 分而治之：将 select/poll的“每次传入全部描述符”拆分为 epoll_ctl（管理列表）和 epoll_wait（等待事件）两个步骤，避免了无效的重复拷贝和遍历。

2. 回调机制：内核通过为每个描述符注册回调函数，主动将就绪的描述符加入就绪链表，实现了事件通知的 O(1) 复杂度。

3. 共享内核空间：核心的红黑树和就绪链表常驻内核，避免了大量内存拷贝。

正是这些精巧的设计，使得 epoll能够轻松应对 C10K 甚至 C10M 级别的高并发连接，成为构建现代高性能网络服务的基石技术（如 Nginx、Redis）。