10. epoll I/O复用：Linux高性能I/O复用模型epoll的使用与原理
聊到Linux网络编程，绕不开的一个话题就是I/O复用。select和poll大家可能都用过，但说实话，在高并发场景下，它们俩真的有点力不从心。我记得我刚入行那会儿，用select写了一个简单的聊天服务器，连接数一上千，CPU直接飙到90%多，卡得跟幻灯片似的。
后来我接触到了epoll，才真正体会到什么叫「高性能」。epoll是Linux内核为处理大量文件描述符而做的改进，它解决了select和poll的很多痛点。说白了，epoll就是Linux上最高效的I/O复用机制，没有之一。
10.1 为什么需要epoll？
我们先看看select和poll的问题在哪。
- 文件描述符数量限制：select默认最多监听1024个fd，改内核参数虽然能调大，但性能会下降。
- 每次都要全量拷贝：每次调用select/poll，都需要把所有的fd集合从用户态拷贝到内核态，这个开销随着fd数量增加而线性增长。
- 内核态全量遍历：内核拿到fd集合后，得一个个遍历检查状态，O(n)的复杂度跑不掉。
- 用户态也要全量遍历：返回后，用户还得再遍历一遍所有fd，才知道哪些有事件发生。
你想想看，如果同时管理一万个连接，每次都要遍历一万次，这效率能高吗？
epoll的出现，就是为了解决这些问题。它引入了三个关键改进：
- 事件驱动：只返回有事件发生的fd，不需要全量遍历。
- 内核与用户共享内存：通过mmap减少数据拷贝。
- 红黑树+就绪链表：高效管理fd和事件。
核心结论：epoll的复杂度是O(1)的，而select/poll是O(n)。在连接数上万时，这个差距就是天壤之别。
10.2 epoll的工作原理
epoll的工作机制，我习惯用三个核心操作来理解：
- epoll_create：创建一个epoll实例，内核会分配一个eventpoll结构体。
- epoll_ctl：向epoll实例中添加、修改或删除要监听的fd。
- epoll_wait：等待事件发生，返回就绪的fd列表。
内核里是怎么实现的呢？简单来说：
每个epoll实例在内核中维护了一棵红黑树，用来存储所有注册的fd。同时还有一个就绪链表，用来存放有事件发生的fd。当某个fd上有事件发生时，内核的回调函数会把这个fd加到就绪链表中。epoll_wait只需要检查就绪链表是否为空，不为空就直接返回。
嗯，这里要注意：epoll_wait返回的是有事件发生的fd，而不是所有fd。这就避免了用户态的全量遍历。
个人经验：我在项目中遇到过一个问题，就是epoll_wait返回后，处理事件时又去遍历所有连接。这其实就失去了epoll的优势。正确的做法是：只处理返回的fd列表，其他的不用管。
10.3 epoll的两种触发模式
epoll支持两种触发模式，这是它比select/poll灵活的地方。
| 模式 | 说明 | 特点 |
|---|---|---|
| LT（水平触发） | 只要fd上有数据可读，epoll_wait就会一直返回 | 默认模式，编程简单，但可能重复通知 |
| ET（边缘触发） | 只有状态发生变化时才通知，比如从无数据变为有数据 | 高效，但必须一次把数据读完，否则会丢失 |
我个人习惯用ET模式，因为它更高效。但ET模式有个坑：你必须用非阻塞I/O，并且要循环读取直到返回EAGAIN。否则数据没读完，下次就不会再通知了。
避坑指南：我曾经在ET模式下忘了设置非阻塞，结果程序卡在recv上，整个事件循环都停了。排查了半天才发现是这个问题。所以记住：ET模式一定要配合非阻塞I/O使用。
10.4 epoll的使用步骤
下面我写一个简单的epoll服务器示例，大家感受一下。
#include <sys/epoll.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#define MAX_EVENTS 1024
#define PORT 8080
int main() {
int listen_fd, epoll_fd, nfds;
struct epoll_event ev, events[MAX_EVENTS];
// 1. 创建监听socket（省略了bind和listen的细节）
listen_fd = socket(AF_INET, SOCK_STREAM, 0);
// ... bind, listen ...
// 2. 创建epoll实例
epoll_fd = epoll_create1(0);
if (epoll_fd == -1) {
perror("epoll_create1");
exit(EXIT_FAILURE);
}
// 3. 添加监听fd到epoll
ev.events = EPOLLIN; // 监听可读事件
ev.data.fd = listen_fd;
if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev) == -1) {
perror("epoll_ctl: listen_fd");
exit(EXIT_FAILURE);
}
// 4. 事件循环
while (1) {
nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
if (nfds == -1) {
perror("epoll_wait");
exit(EXIT_FAILURE);
}
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == listen_fd) {
// 有新连接
int conn_fd = accept(listen_fd, NULL, NULL);
// 设置非阻塞
int flag = fcntl(conn_fd, F_GETFL, 0);
fcntl(conn_fd, F_SETFL, flag | O_NONBLOCK);
// 添加到epoll
ev.events = EPOLLIN | EPOLLET; // ET模式
ev.data.fd = conn_fd;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, &ev);
} else {
// 处理客户端数据
// 注意：ET模式下要循环读取
handle_client(events[i].data.fd);
}
}
}
close(epoll_fd);
return 0;
}这段代码展示了epoll的基本用法。核心就是三步：create、ctl、wait。循环里只处理有事件的fd，效率非常高。
10.5 epoll与select/poll的对比
我整理了一个对比表，方便大家直观理解：
| 特性 | select | poll | epoll |
|---|---|---|---|
| 最大fd数 | 1024（默认） | 无限制 | 无限制 |
| 数据结构 | 位图 | 链表 | 红黑树+就绪链表 |
| 拷贝方式 | 全量拷贝 | 全量拷贝 | 共享内存（mmap） |
| 遍历方式 | 全量遍历 | 全量遍历 | 只返回就绪fd |
| 时间复杂度 | O(n) | O(n) | O(1) |
| 触发模式 | 仅水平触发 | 仅水平触发 | LT+ET |
从表里可以清楚看到，epoll在各方面都优于select和poll。但要注意，epoll是Linux特有的，如果你要写跨平台代码，还是得用select或者libevent这样的封装库。
10.6 epoll的常见问题与优化
在实际项目中，我遇到过几个epoll相关的坑，分享给大家：
- 惊群问题：多个进程/线程同时epoll_wait同一个fd，当事件发生时，所有进程都被唤醒，但只有一个能处理。解决方案是使用EPOLLEXCLUSIVE标志（Linux 4.5+），或者用SO_REUSEPORT。
- 事件丢失：ET模式下，如果一次没读完数据，后续事件不会触发。一定要循环读取到EAGAIN。
- 内存泄漏：关闭fd后，记得从epoll中删除，否则epoll实例会一直持有引用。
优化建议：如果连接数特别大（比如10万+），可以考虑使用epoll的EPOLLONESHOT标志，让每个fd只触发一次事件，防止多线程同时处理同一个fd。
10.7 epoll的工作流程
下面我用一张SVG图来展示epoll的完整工作流程，帮助大家建立整体认知。
这张图展示了epoll的核心流程：用户态通过系统调用与内核态交互，内核使用红黑树管理fd，就绪链表保存有事件的fd，用户只需处理就绪列表即可。
10.8 总结
epoll是Linux高性能网络编程的基石。它的核心思想就是「只通知有事件发生的fd」，避免了无意义的遍历。我个人觉得，理解epoll的关键在于三点：
- 红黑树：高效管理大量fd的增删改查。
- 就绪链表：只返回有事件的fd，O(1)复杂度。
- ET/LT模式：根据场景选择合适的触发方式。
如果你现在还在用select写高并发服务器，我建议你尽快切换到epoll。性能提升是立竿见影的。当然，epoll也不是银弹，它只适用于Linux平台，而且ET模式需要更小心的编程。但掌握了它，你的网络编程能力会上一个台阶。
一句话总结：epoll就是Linux给网络编程开发者的一把利器，用好了，百万并发不是梦。