企业官网建设流程全解析

如果你写过网络服务，一定对阻塞式IO的痛深有体会：一个accept等在那里，后面的请求全排着队；稍微上点并发，线程一开就是几百上千，CPU全耗在线程切换上。于是大家开始用多路复用，先有select、poll，再后来只要是碰Linux高并发，几乎绕不开epoll。这篇是系列的终篇，前面把IO模型、阻塞非阻塞、select/poll的原理都铺垫完了，今天集中把epoll从内核设计到代码落地拆一遍，包括它为什么快、LT和ET差在哪、实际项目里怎么用、踩过的坑有哪些。适合刚接触高并发服务端开发的朋友，也适合写了好几年业务代码但一直没搞懂事件驱动的同学。

1. 为什么高并发I/O最终绕不开epoll

1.1 从阻塞IO到多路复用：问题到底出在哪里

先回到最原始的场景：一个进程同时服务多个客户端连接，最直接的办法就是每个连接开一个线程。连接少的时候没问题，连接一旦到了一万、十万，线程数量就成了灾难。线程本身有内存开销，栈空间默认8MB，就算只创建不干活，一万个线程也把内存吃光了；线程切换更是要命，每次系统调用进内核，调度器要维护一堆队列，CPU时间大量浪费在上下文切换上。

所以才会有人想到让一个线程同时盯着多个文件描述符，谁有事件就处理谁。这就是多路复用的价值。select和poll是最早的方案，它们的思路其实很单纯：把所有需要监听的fd交给内核，内核遍历一遍，把有事件的fd标记出来，再返回给用户态，用户态再遍历一遍处理。等于每次select/poll调用都要全量扫描所有fd，连接数到上万时，这个扫描成本已经高到不可接受了。

而且select本身还有先天的限制：能监听的fd数量由FD_SETSIZE决定，通常是1024。虽然可以改内核参数，但从设计上就注定了它不可能是大规模高并发场景的正解。poll突破了数量限制，但依然没有解决“无差别遍历”和“每次都要全量拷贝fd列表”的问题。讲到这里你应该能感觉到，真正的高并发方案需要两个改变：内核不再反复遍历全部fd，用户态也不再为了拿到几个事件就要拷贝整份fd列表。

1.2 select/poll的核心缺陷：无差别轮询

select/poll慢，不是慢在某个具体实现上，而是慢在机制本身。每次调用，用户态都要把整个fd集合拷贝进内核，内核拿到之后，对每个fd逐一检查状态，再把结果拷回用户态。这里有两个维度的问题。

第一是拷贝成本。假设你监听了5万个连接，每次调用都要把这5万个fd的位图或者结构体数组从用户态搬到内核态，内核处理完再搬回来。一次两次无所谓，问题是高并发服务里select/poll往往是主循环里不停调用的，每次调用都是O(n)的拷贝，n是监听fd总数。

第二是检查成本。内核不知道哪些fd真正活跃，只能把所有fd全部查一遍。实际的网络服务里，绝大多数连接在大部分时间是空闲的，真正活跃的可能只有几十个。可内核不知道这些信息，它还是要老老实实地把所有fd的等待队列都过一遍。这就相当于你站在一千个房间门口，挨个敲门问“有没有人找我”，而真正有事的可能只有三间。这种无差别轮询的设计，注定了它在连接数上了量级之后会指数级变慢。

epoll的做法完全不同，它让内核直接记住你关心的fd，并且只在你真正关心的那个fd上等事件。一旦某个fd有事件发生，内核主动把对应的结构体丢进一个就绪队列，用户态只需要取这个队列里的内容。这背后的核心思想是：要用回调通知来替代主动遍历。

1.3 epoll的设计哲学：回调通知替代遍历

要理解epoll的效率，先记住一句话：select/poll是“你问我答”，epoll是“有事叫我”。epoll_ctl添加一个fd时，内核会把一个epitem结构体挂到该fd的等待队列上，并注册一个回调函数。当这个fd上真的发生IO事件时，驱动程序会触发这个回调，回调的逻辑很简单：把这个epitem添加到epoll实例的就绪链表中。

这样内核绝大部分时间不用做遍历。它只需要在每次epoll_wait的时候，检查一下就绪链表是不是空的；如果非空，就把链表里的事件复制到用户态传入的数组里，然后清空就绪链表。注意，这里的复杂度是O(k)，k是实际就绪的事件数量，而不是总监听数量。这就是为什么连接数越大，epoll的优势越突出：十万连接和一百连接，对epoll来说，日常维护成本几乎是一样的。

它也不是没有成本。epoll在内核里维护了一棵红黑树用来快速增删监听的fd，每次epoll_ctl调用都会有红黑树的插入删除操作。所以说epoll快，是“等待事件”这个高频操作变快了，而注册和修改操作其实是比以前更重的。理解了这一点，你对后续的编程建议会更容易接受。

2. epoll内核实现原理拆解

2.1 三张核心数据结构：eventpoll、epitem、就绪队列

epoll在内核中并不是一个魔法，它由几个核心数据结构支撑。首先是eventpoll结构体，它就是epoll_create创建出来的那个实例的“内核化身”，对应我们在用户态拿到的epfd整数。一个eventpoll实例内部有两个关键成员：一棵红黑树和一个就绪链表。

红黑树的根节点就是epitem结构体，它代表一个被监听的fd。为什么用红黑树？因为epoll_ctl需要支持高效的添加、删除、修改操作，而这些操作的本质是查找，红黑树的查找、插入、删除都是O(log n)，在几万个fd的规模下性能非常稳定。每个epitem里保存了fd号、感兴趣的事件掩码、对应的file*指针、以及回调整等核心信息。

另一个关键成员是就绪链表，链表的节点就是被触发事件的epitem。事件发生时，回调函数把对应的epitem从红黑树“拎”出来，挂到就绪链表上。这里有一个容易被忽略的细节：同一个epitem如果被多次触发，它不会被重复放入就绪链表，因为结构体里有个rdllink字段，在放入链表前会做“是否已在链表中”的判断。这个设计保证了epoll_wait返回的事件不会重复。

还要注意一点：就绪链表中的事件，在epoll_wait返回后，到底会不会被自动清除？这取决于触发模式。LT模式下，只要fd上还有未处理的数据，下次epoll_wait还是会把事件加入就绪链表；而ET模式下，一次事件被取出后，除非新的数据到来，否则不会再加入。这部分后面详细展开。

2.2 系统调用如何协作：create、ctl、wait

用户态跟内核打交道的入口是三个系统调用。epoll_create负责创建一个eventpoll实例，老版本参数是size，用来给内核一个链表大小的提示；新版本推荐用epoll_create1(0)，参数为0表示与旧版等价，但也能传EPOLL_CLOEXEC，让fd在进程执行exec时自动关闭，避免意外泄漏给子进程。

epoll_ctl负责管理红黑树。它的操作类型有三种：EPOLL_CTL_ADD表示把一个新的epitem插入红黑树，EPOLL_CTL_MOD表示修改一个已有epitem上的事件掩码，EPOLL_CTL_DEL表示从红黑树中摘除。这个调用是同步操作，所有增删改都会立刻生效。实际写代码时最常见的错误是把MOD当成ADD来用，或者对一个已经添加过的fd重复ADD，会直接返回EEXIST。

epoll_wait负责等待事件。它把就绪链表中的事件批量复制到用户态传入的events数组里，最多复制maxevents个。第三个参数是超时时间，单位毫秒，-1表示永久阻塞，0表示立即返回。事件就绪时，用户态拿到的epoll_event结构体里有两个重要字段：events是这个fd上发生的事件掩码，data是一个联合体，可以存fd，也可以存指针。这里我强烈建议，如果你的项目结构里本来就有conn对象，就把data.fd和data.ptr配合好。多数人习惯用data.fd存裸fd，然后自己再用fd查对象，这会产生一次查表开销；直接存对象指针会更高效，但要注意生命周期管理，防止指针悬空。

2.3 LT与ET：两种触发模式的本质区别

LT是水平触发，也是默认模式。在这个模式下，只要fd上有数据可读，epoll_wait就会反复通知你。比如你注册了EPOLLIN，缓冲区来了1KB数据，你只读了512字节，那么下一次epoll_wait依然会把这个fd返回，直到你把数据读完。

ET是边缘触发，它只会在状态变化的那一刻通知一次。数据从无到有，这是“边沿”，它会通知你；但如果你没读完，剩下的数据还在缓冲区里，它不会再通知你了。所以ET模式要求你接到通知后，必须一次性把数据全部读完，否则就漏数据。这就引出了ET模式的两个铁律：fd必须设置为非阻塞，读取数据必须循环读到EAGAIN为止。

从内核实现看，两者的差别在就绪链表维护上：LT模式下，epoll_wait返回时如果发现fd上还有未消费的事件，会重新把它挂回就绪链表；ET模式下，事件被取出后就不再主动放回，除非有新的事件发生。因此，同样的并发量，LT产生的系统调用次数更多，ET更省，但对代码要求更高。实际项目中，我不建议一上来就无脑用ET，如果你的业务逻辑简单、数据量不大，LT反而更稳。

2.4 事件回调与就绪链表：为什么epoll能撑10万连接

很多人在聊高并发时喜欢拿“十万连接”当目标，实际上真正单机撑十万连接的瓶颈很少在epoll本身，而在于应用层怎么分配内存和CPU。epoll的关键贡献是：它把对事件源的监听成本从O(n)降到了接近O(1)。

一个连接从建立到关闭，epoll内核态维护的成本基本就是一棵红黑树节点加一个epitem结构体的内存。事件触发时，回调函数只是做一次链表插入，没有任何锁竞争（同一多路复用器内部）。在单线程事件循环模型下，一个进程哪怕管理几十万个空闲连接，CPU开销也主要消耗在epoll_wait返回后的业务处理上，而不是监听本身。

这个效率来自Linux内核的网络协议栈为我们提供的设备层回调机制。当网络数据包到达网卡、经过协议栈处理、最终插入socket接收队列时，会触发socket的等待队列回调，而epoll注册的回调函数正是在这一刻被调用的。换句话说，内核不是主动来告诉你“有事件了”，而是让事件自己顺着协议栈一路跑到你注册的函数里。这个“被动通知”的架构，是epoll高性能的根基。

3. epoll核心API使用与实战

3.1 接口签名与参数说明

先看三个核心接口：

#include <sys/epoll.h> int epoll_create1(int flags); 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);

epoll_event结构体定义如下：

struct epoll_event { uint32_t events; /* epoll事件掩码 */ epoll_data_t data; /* 用户数据，联合体 */ }; typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;

events字段常用取值包括：EPOLLIN（可读）、EPOLLOUT（可写）、EPOLLERR（错误）、EPOLLHUP（挂断）、EPOLLRDHUP（对端关闭连接，比EPOLLHUP更精细，常用于判断半关闭）、EPOLLET（边缘触发）、EPOLLONESHOT（一次性通知，通知后需要重新MOD才能继续监听）。

注意一个常被忽视的细节：EPOLLERR和EPOLLHUP并不需要你手动在events里注册，只要fd上发生错误或挂断，epoll_wait就会把它们加到返回的事件掩码中。所以处理事件时，不光要看EPOLLIN，还要检查EPOLLERR和EPOLLHUP，否则连接异常断开时可能引发意想不到的问题。

epoll_wait的timeout参数也值得说道。永久阻塞用-1，这在纯事件循环里没问题；但如果你所在的线程除了处理网络事件还要干点别的事（比如定期清理空闲连接、上报心跳指标），就不能永久阻塞，建议设置一个合理的超时值，比如50到100毫秒。这样主循环每轮都会醒来一次，做周期性任务。

3.2 一个最小可用的echo server实现

直接上一段可以跑起来的C代码。这个服务会监听9999端口，对每个客户端连接做echo回显。为了演示ET模式的标准写法，我把监听socket和连接socket都设成了非阻塞，并且都注册为边缘触发。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <sys/epoll.h> #include <sys/socket.h> #include <netinet/in.h> #define MAX_EVENTS 1024 #define MAX_BUFFER 4096 static int set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); if (flags < 0) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); return 1; } int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); set_nonblocking(listen_fd); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(9999); if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); return 1; } if (listen(listen_fd, 1024) < 0) { perror("listen"); return 1; } int epfd = epoll_create1(0); if (epfd < 0) { perror("epoll_create1"); return 1; } struct epoll_event ev; ev.events = EPOLLIN | EPOLLET; ev.data.fd = listen_fd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) { perror("epoll_ctl add listen_fd"); return 1; } struct epoll_event events[MAX_EVENTS]; while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); if (n < 0) { if (errno == EINTR) continue; perror("epoll_wait"); break; } for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (fd == listen_fd) { // 监听socket上有新连接，ET模式下必须循环accept直到EAGAIN while (1) { int conn_fd = accept(listen_fd, NULL, NULL); if (conn_fd < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; } else { perror("accept"); break; } } set_nonblocking(conn_fd); struct epoll_event conn_ev; conn_ev.events = EPOLLIN | EPOLLRDHUP | EPOLLET; conn_ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &conn_ev); } } else { if (events[i].events & (EPOLLERR | EPOLLHUP | EPOLLRDHUP)) { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); continue; } if (events[i].events & EPOLLIN) { char buf[MAX_BUFFER]; while (1) { ssize_t r = read(fd, buf, sizeof(buf)); if (r > 0) { send(fd, buf, r, MSG_NOSIGNAL); } else if (r == 0) { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; } else { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); break; } } } } } } } close(epfd); close(listen_fd); return 0; }

这个例子尽管短，但已经把ET模式的标准写法覆盖了。你注意几个关键点：监听socket是非阻塞的，accept放在循环里，直到返回EAGAIN；每个新连接都设置了O_NONBLOCK；读取数据用while循环，读到EAGAIN才停；对端关闭时，read返回0，做清理。

3.3 ET模式必须配合非阻塞IO：三个最容易踩的坑

第一个坑：在ET模式下用了阻塞socket。这是新手最常犯的错。ET模式通知一次，你如果只read一次，缓冲区里剩下的数据就再也等不到通知了。所以你要循环read，但阻塞socket在缓冲区没数据时，read会卡住线程，整个进程就僵死在那里。正确做法一定是：非阻塞socket加循环读取，读到EAGAIN确认本次事件处理完毕。

第二个坑：accept没有放在循环里。ET模式下，多个连接同时到达时，内核只触发一次EPOLLIN，如果你只accept一次，剩下的连接会一直留在已完成连接队列里，后面再也没有通知。最终表现就是客户端连接建立不了，而服务端毫无反应。这也是为什么监听socket在ET模式下也要循环accept。

第三个坑：处理EAGAIN时判断错了。read返回-1并不都代表出错，只要errno是EAGAIN或者EWOULDBLOCK，其实是“正常读完了”，需要区分对待。很多人把所有-1都当成错误直接关闭连接，结果就是高并发下连接被莫名奇妙断开。同样，send也可能返回EAGAIN，代表发送缓冲区满了，这时候要把数据放到待发送队列里，等EPOLLOUT事件再发，而不是直接关闭。

3.4 事件处理的五种常见姿势

实际项目中，处理epoll事件不只有“读到EAGAIN”一种姿势。我梳理了五种最常见的写法：

• 只关注EPOLLIN，处理读事件，适合简单的请求响应模型。
• EPOLLIN加EPOLLOUT双关注，适合大响应体、发送缓冲区容易满的场景。
• EPOLLIN加EPOLLONESHOT，适合多线程处理业务，保证一个连接同一时刻只被一个线程处理。
• EPOLLIN加EPOLLET，适合追求单线程高吞吐的压测场景。
• 只关注EPOLLOUT，适合批量推送场景，比如客户端连上后服务端主动灌数据。

你需要根据业务特点选择。比如你写一个推送服务，连接建立之后服务端要主动写大量数据，那么EPOLLOUT才是主事件。如果只是普通的HTTP服务，主要精力在EPOLLIN上，EPOLLOUT只在写缓冲区满了之后才临时注册，写完立即改回来。

这里有个值得养成的习惯：事件是按需注册的，不是越多越好。平时只关注读事件，当send返回EAGAIN时，再为这个fd额外注册EPOLLOUT；等缓冲区排空、EPOLLOUT触发后，再把EPOLLOUT从事件掩码里去掉。这比一开始就每个连接都注册EPOLLIN | EPOLLOUT要高效得多，因为大部分连接大部分时间没有数据要写，内核没必要每次都检查写空间。

4. 高并发服务中的epoll实践与调优

4.1 单线程Reactor模型的极限在哪里

很多接触epoll的人，第一版代码就是单线程事件循环：一个epoll_wait，拿到事件后一个个处理。这个模式简单、好调试，但你必须知道它的极限。单线程意味着所有请求串行处理，如果一个连接的业务逻辑里有耗时的阻塞操作（比如一次慢查询、一次磁盘IO），后面的连接都得等它完成。

那是不是单线程epoll完全不行？也不是。如果你的业务是IO密集型、每次处理耗时在微秒级，单线程事件循环在几千连接、每秒几万次请求的场景下依然能跑得很轻松。我见过一个转发服务，单线程epoll轻轻松松扛住每秒几万的包转发，CPU占用不到一核。原因很简单：事件处理里没有阻塞调用，epoll的唤醒开销又极低。

如果你需要真正的高并发，还是要面对“单线程处理不过来”的现实。这时候优先考虑的不是上多线程，而是把epoll_wait拿到的每个事件尽量快地派发出去，让处理逻辑在别的线程完成。这样主线程只负责“分发”，把CPU集中在事件监听和连接管理上。

4.2 多线程Reactor与EPOLLONESHOT

多线程Reactor的经典结构是：主线程跑一个epoll_wait，负责监听所有连接；收到事件后，把连接交给工作线程池去处理；工作线程处理完，再通过某种方式把结果写回连接。这个模型里最棘手的问题就是：一个连接的事件可能被主线程丢给线程A处理，结果另一个事件又被丢给线程B，同一时刻两个线程操作同一个socket，就会产生竞态。

解决这个问题的标准方案就是EPOLLONESHOT。带上这个标记后，epoll_wait在返回该fd的事件后，会把这个fd从就绪链表里摘除，并且直到你重新调用epoll_ctl的EPOLL_CTL_MOD重新注册事件之前，它都不会再被通知。这给了工作线程“独占处理一个事件”的机会，避免多个线程同时碰同一个连接。

但EPOLLONESHOT也有代价：每次事件处理完都要重新MOD一次，多了一次系统调用。如果事件非常频繁，这个开销不可忽略。我的建议是：如果你的工作线程处理逻辑很轻、每个事件耗时很短，可以用“主线程分发事件、工作线程只做读写”加一个互斥锁的简单方案；如果业务逻辑重、处理时间长，才考虑EPOLLONESHOT，保证一个连接同一时刻只属于一个线程。

4.3 性能参数调优：文件描述符上限与事件数组

先说文件描述符上限。epoll能管理的fd数量，理论上只受系统最大打开文件数限制。普通的bash会话默认一个进程只能开1024个文件描述符，这就是为什么很多新手写了epoll程序，连到一千个连接就报“Too many open files”。需要在程序里调用setrlimit提高RLIMIT_NOFILE，或者在启动环境里配置limits。生产环境建议直接调整到几十万。

/proc/sys/fs/file-max是系统级的总文件描述符上限，如果这个值偏小，进程再怎么调rlimit也没用。不过现代内核默认值通常够用了，你需要关注的更多是单进程限制。

再聊epoll_wait的events数组大小。很多人会问：maxevents设多大合适？这里有一个朴素原则：比预期峰值并发连接数略大，但不要大到浪费内存。每个epoll_event结构体大概占十几个字节，你就算设为1024，也就十几KB内存。但如果并发连接数真的到了几万，事件数组太小会导致一次epoll_wait处理不完所有就绪事件，剩下的要等下一次超时才能再取出来，增加延迟。常规做法是设为max(1024, 预期连接数/10)，再观察实际返回的n是否经常等于maxevents，如果频繁触顶，就调大。

还有一个容易被忽视的调优点：epoll_wait的timeout。如果你希望主循环保持敏锐，timeout不宜太长。比如配合心跳超时管理，每50毫秒醒来一次扫描过期连接，比永久阻塞更合理。但timeout太短会让CPU空转，加大功耗。我一般用50~200毫秒之间，具体要看业务对延迟的敏感度。

5. 常见问题排查实录

5.1 事件丢失？ET模式下读取不彻底

这是ET模式最典型的现象：客户端明明发了数据，服务端就是没反应，或者只处理了第一批数据，后面的数据像消失了一样。

原因几乎都是读取不彻底。ET模式只通知一次，你如果没有等到EAGAIN就跳出循环，剩下的数据一直留在内核接收缓冲区里，而内核又不会再有新的事件产生，于是这些数据就成了“僵尸数据”。排查方法很简单：在读取循环里加上日志，打印每次read的返回值，最后看是不是以EAGAIN结束的。如果直接返回了就跳出，那问题就在这。

同样的问题也会出现在accept上。监听socket是ET模式时，必须循环accept嵌套在事件处理里，直到返回EAGAIN。很多人在压测时发现连接数上不去，其实不是epoll的问题，而是accept只处理了第一批连接。

5.2 CPU飙到100%？忙轮询还是漏了EAGAIN

epoll程序CPU飙高，最常见的“假忙”场景是：某个fd在LT模式下被注册了EPOLLIN，但你处理得不够快，数据没读完；或者某个fd已经对端关闭，但你一直没处理EPOLLHUP。于是epoll_wait每次都返回这个fd，主循环立刻又转回来，形成一种类似忙轮询的死循环。

如果在ET模式下CPU飙高，大概率是因为某个事件处理路径没有正确处理EAGAIN：你循环read时，缓冲区读空了，但代码没把EAGAIN当成“正常结束”，而是直接continue或者又注册了事件，结果空转。排查时可以临时用perf或者strace看一下系统调用次数，如果epoll_wait每秒返回上万次，就要去查哪个fd一直在就绪。

5.3 惊群问题的真相与应对

惊群是指多个进程或线程同时epoll_wait在同一个epoll实例上，当一个事件到来时，所有等待者都被唤醒，但最终只有一个能处理事件，其余全部空跑一场。早期的epoll确实有这个问题，后来内核引入了EPOLLEXCLUSIVE标记，当一个fd以这个标记注册到多个epoll实例时，事件只会唤醒其中一个等待者，避免了惊群。

在多进程模型下，更推荐的做法是：每个工作进程拥有独立的epoll实例，通过负载均衡策略把新连接分发给不同进程。这样每个进程只监听自己负责的那批fd，压根不存在“多个进程等同一个fd”的情况。如果你的业务环境不允许改造模型，再考虑在描述符上使用EPOLLEXCLUSIVE，但要注意它要求所有注册该fd的实例都带上这个标记才能生效。

5.4 写好EPOLLOUT：不是靠忙等

很多新手一开始就把所有连接注册成EPOLLIN | EPOLLOUT，这在连接很少时没问题，但连接多了以后，EPOLLOUT会频繁触发，因为大多数时候socket发送缓冲区都是空的，内核认为“随时可写”，于是事件不断来，CPU不断空转。

正确的做法是：初始只关注EPOLLIN，需要写数据时先尝试send，只有返回EAGAIN，才通过epoll_ctl用EPOLL_CTL_MOD加上EPOLLOUT；等EPOLLOUT事件来了以后，先把待发送缓冲区的数据尽量send掉，如果发送缓冲区已空，就把EPOLLOUT从事件掩码里去掉。这个“按需订阅”的思路，能省掉大量无意义的系统调用。

我自己实现转发服务时，维护了一个“待写队列”链表：每个连接节点上有数据时，才向epoll注册写事件；数据发完立刻摘掉。实测下来，同样的压测请求，这种写法的CPU占用比“一直挂着EPOLLOUT”低40%以上。别小看这个细节，在高并发下它就是压测能不能过关的分水岭。

6. 个人实操心得与扩展建议

我最早用epoll时也踩过不少坑，最深刻的一条经验是：epoll本身不复杂，复杂的是事件驱动的思维转换。写业务代码时，你习惯了一件事做完再干下一件；写epoll之后，你不能假设“读了一次就一定读完了”，也不能假设“发起send就发出去了”。所有操作都是“可能有数据”、“可能被拒绝”、“继续等通知”。

如果你刚开始接触，我建议先用LT模式把模型跑通，确认数据收发稳定之后，再切到ET模式做性能优化。ET不是银弹，它对代码的严谨性要求更高，但带来的性能提升在连接数海量增长时才会真正体现。

关于后续扩展，有两件事值得深入研究：一是io_uring，它在某些场景下比epoll更高效，尤其是大量异步磁盘IO和网络IO混合的场景；二是用户态协议栈和共享内存通信，它们能进一步降低数据拷贝成本。但不管怎么演进，epoll作为Linux高并发编程的基石，你把它吃透了，再学任何事件驱动框架都会事半功倍。最后再说个实用小技巧：在每条连接的epoll_event.data里直接存你自定义的连接对象指针，而不是存fd再去查表，代码会简洁很多，性能也能好一点。前提是管理好连接对象的生命周期，避免指针悬空。