1. 阻塞IO的卡点到底在哪：一次真实压测引出的问题

几个月前我接手了一个内部网关服务的性能优化，业务本身不复杂：客户端连上来，发送请求，服务端处理完返回结果。代码写得很规矩，线程池、队列、超时控制全都有，可压测到四五千并发连接时，延迟像坐了过山车，CPU占用率却不到30%。当时第一反应是“线程数不够”，把线程池从200调到500，情况不但没好转，反而频繁出现线程创建失败。后来才意识到，真正的问题根本不是“线程不够多”，而是每个线程都被阻塞在IO等待上，线程越多，等待越多，上下文切换越频繁，整个系统就在那里做无用功。

所谓阻塞IO，就是当你调用recv()、read()这类系统调用时，如果数据还没准备好，内核会把当前线程挂起，让出CPU。这在单连接、交互不频繁的场景下很合理，线程睡就睡了，不碍事。但在高并发场景下，问题来了：每个连接都需要一个线程来伺候，每来一个请求，线程就要经历一次从用户态到内核态的切换，线程多了之后，光切换开销就能吃掉大量CPU，真正干活的时间少得可怜。

这就是业界常说的C10K问题的根源之一。不是CPU不够快，也不是内存不够大，而是等待的方式错了。你让一万个线程各自干等自己的网络数据，还不如让一个线程去同时盯着这一万个连接，谁有数据就处理谁。想要做到这一点，你就得先让IO变得“不阻塞”，或者用更聪明的机制让内核替你完成“盯梢”的工作。这就是非阻塞IO和多路转接机制的用武之地。

理解这一层是下面所有内容的基础。很多人一上来就背epoll的概念，却说不清为什么需要它，最后写出来的代码还是阻塞模型的路子，换汤不换药。我先把阻塞IO的老底揭开，再一步步看非阻塞IO怎么解决“等”的问题，最后看多路转接是怎么把“找就绪连接”这件事从O(n)变成O(1)的。

1.1 阻塞IO的基本行为：recv/read的等待逻辑

阻塞IO最典型的行为模式是这样的：进程调用recv()时，如果socket接收缓冲区里没有数据，系统调用不会立即返回，而是把当前进程状态设为睡眠，加入到socket的等待队列中。直到数据到达、或者连接出错、或者超时，内核才把进程唤醒，recv()返回数据或错误码。

这个过程对应用层来说是“简单”的，你不需要关心数据什么时候到，反正函数不返回就是在等。但代价就是，一个正在recv()的线程无法服务任何其他连接。如果你只有十几二十个连接，这个模型完全没问题。但假设你有5000个连接，每个连接每秒发一个请求，你要开至少5000个线程，每个线程要维护自己的栈空间（默认8MB虚拟内存），光线程的虚拟内存就占了40GB，这还没算线程切换的开销。

我在那次压测中看过vmstat的输出，cs（context switch）列飙到了十几万，系统几乎把所有时间都花在切换线程上了。你以为是并发太高，其实是阻塞等待导致的连锁反应。线程池不是不能扛并发，而是扛不住“大量连接同时存在”这种场景——每个连接都是个长期占据线程的“钉子户”。

1.2 线程模型在并发下的代价：上下文切换与内存开销

线程切换的代价到底多大？一次上下文切换大约需要几十微秒，看起来不多，但那是单次的。每秒发生几千上万次切换，CPU时间就被白白消耗了。而且切换还要涉及用户态和内核态的反复进出，TLB缓存失效、cache miss，这些隐性开销比账面上的数字更可怕。

内存开销同样不容忽视。Linux默认线程栈是8MB，当然虚拟内存不是真实占用的，可一旦线程栈被触碰过，物理内存就会相应增长。5000个线程，就算每个线程只用了1MB左右的真实栈空间，那就是5GB物理内存。压测的机器如果只有16GB内存，剩下给业务逻辑用和文件缓存的还剩下多少？所以当你看到“线程池加不上去，OOM了”的时候，往往不是内存泄漏，而是模型本身的资源消耗太大了。

1.3 C10K问题的本质：是等待方式错了

C10K问题，字面意思是“处理一万个并发连接”，但它真正的核心矛盾不是“一万”这个数字，而是当并发连接数远大于可用线程数时，你必须改变等待方式。

阻塞IO模型下，等待是每个线程独立进行的。一万个连接，就得有一万个线程在各自等待。但仔细想想，同一时刻，真正有数据可读的连接可能只有几十个，剩下的都在等。“盯着连接”这件事本身，完全可以由一个线程完成：它负责看哪些连接就绪了，就绪之后，再交给其他线程去处理数据。这样一来，等待的代价就从“每个连接一个线程”变成了“每个连接一个条目”，内存和CPU的消耗就都不是问题了。

这就是非阻塞IO和多路转接的出发点。非阻塞IO解决的是“等待时不能干别的事”的问题，多路转接解决的是“如何高效地同时盯很多连接”的问题。两者配合起来，才算是摸到了高并发IO的门道。

2. 非阻塞IO的第一次优化：忙等轮询解决了什么，又带来了什么

2.1 O_NONBLOCK与EAGAIN：非阻塞的底层工作方式

非阻塞IO，从内核实现的角度看，本质是修改了socket文件描述符的一个标志位：O_NONBLOCK。你可以通过fcntl()在运行时设置，也可以在socket()创建时直接传入SOCK_NONBLOCK标记。

设置之后，recv()的行为就变了：如果socket接收缓冲区没有数据，它不会挂起进程，而是立刻返回-1，并设置errno为EAGAIN（对Linux来说EAGAIN和EWOULDBLOCK等价）。这个错误码的意思是“现在没有数据，但你不用等我，你可以去干别的事，待会再来问”。

这段逻辑可以用很简单的方式验证：

#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> #include <sys/socket.h> #include <netinet/in.h> int main() { int fd = socket(AF_INET, SOCK_STREAM, 0); int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); char buf[64]; ssize_t n = recv(fd, buf, sizeof(buf), 0); if (n == -1 && errno == EAGAIN) { printf("no data available, errno=%d (EAGAIN)\n", errno); } return 0; }

这个程序在没有任何连接的情况下调用recv()，如果是阻塞IO，它会一直挂在那里；但因为是non-blocking模式，它会立即返回并走到EAGAIN的分支。

明白EAGAIN的意义很重要，这是非阻塞IO的核心信号。你后续所有轮询逻辑，本质都是在围绕这个错误码转：调用函数，如果返回EAGAIN，就说明“现在没数据，我换个时间再来”。

2.2 用户态轮询机制的实践：纯busy-wait的CPU账本

有了非阻塞IO之后，你可以设计一个简单的用户态轮询机制：把所有连接的fd放进一个数组，然后循环遍历，逐个调用recv()（或者先recv()试探），有数据就处理，没数据（返回EAGAIN）就继续下一个。

伪代码大概是这样的：

while (1) { for (i = 0; i < nfds; i++) { n = recv(fds[i], buf, sizeof(buf), MSG_DONTWAIT); if (n > 0) { handle_data(fds[i], buf, n); } else if (n == -1 && errno != EAGAIN) { handle_error(fds[i]); } } }

这个方案能工作，但效率极其糟糕。因为在for循环里，每次recv()都是一次系统调用，即使socket上没有数据，也要从用户态陷入内核态，查一遍socket的等待队列，发现没数据，再返回用户态。这一来一回，一次系统调用差不多要几百纳秒到几微秒。如果同时盯5000个连接、每个连接大部分时间都没有数据，那么每一轮循环就要做5000次无意义的系统调用。

我做过一个粗略估算：假设一次无数据recv()耗时1微秒（实际上在内核态和用户态之间穿梭，加上缓存失效，差不多的数量级），5000个fd一轮就是5毫秒。1秒钟大概只能轮询200轮。每个连接哪怕每秒钟只发一个请求，200轮的覆盖频次也勉强够用，但CPU在空转上的开销已经非常可观。更不要说处理数据本身的延迟也被拉长了——一个连接的数据可能在缓冲区里待了好几个轮询周期才被发现。

为了改善“无数据时反复系统调用”的问题，有些人会在循环里加上usleep()，比如每轮循环睡1毫秒。这样确实能降低CPU占用，但代价是两个轮询周期之间会有一个固定延迟，请求的处理延迟被拉高了。而且，如果你sleep的时间长了，高峰期数据到达后就得不到及时处理，延迟反而更糟。

2.3 游戏规则变了：引入独立线程做轮询也一样亏

有人会想，那我用独立线程专门做轮询，主线程继续处理业务逻辑，总该好了吧？实际上这是在转移成本，而不是消除成本。轮询线程依然要反复进出内核态做无意义的检查，CPU的浪费一点没少，只是从主线程挪到了别的线程上。你还需要额外处理轮询线程和业务线程之间的数据同步（队列、锁、条件变量），复杂度上来了，性能账却依然不好看。

更本质的问题是，用户态轮询永远无法解决“我怎么知道fd有没有数据”这件事的高效性问题。每次去问内核都是一次系统调用，而系统调用是昂贵的。你需要一种机制，让内核在数据就绪时主动通知你，而不是你自己反复去问。这正是多路转接（I/O Multiplexing）要做的事：把“盯着所有fd”这件事从用户态交给内核态，由内核帮忙找到哪些fd就绪了，你只需要问一次内核，拿到一个就绪列表，然后只处理这些就绪的fd。

这也是轮询机制在多路转接里的另一种形态：不是应用层逐个recv()，而是内核层批量告诉你答案。select()、poll()、epoll_wait()本质上都是“你睡一觉，内核叫醒你，告诉你谁醒了”。

3. 多路转接如何改变局面：select、poll与epoll的演进逻辑

多路转接（I/O Multiplexing），中文教材里也译作“多路复用”，它的思路就是把多个fd的等待合并成一个等待。你告诉内核“帮我盯着这一堆fd”，然后你自己睡过去。内核发现有任何一个fd就绪，就把你唤醒，并且告诉你哪些fd就绪了。这样，一个线程就能同时管理成千上万个连接，而且只有在“有活干”的时候才被唤醒，不会像忙等轮询那样空转。

这种机制在工程上的演化分了三代：select、poll、epoll。三者的核心目的相同，但实现和性能特性差异巨大。理解三者的演进逻辑，就理解了多路转接的精髓。

3.1 select：为什么说它是“轰炸机式”的等待

select()是最老的多路转接接口，上世纪80年代就有了。它的签名长这样：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

使用方法说来也简单：你先把关注的fd加入一个fd_set集合（本质是位图），然后调用select()，内核会在这组fd上等待，直到至少一个fd就绪或者超时。返回后，你遍历所有fd，逐个用FD_ISSET()检查它是不是就绪的那个。

select()存在的几个严重问题，每一个在高并发场景下都是致命的：

• fd数量受限：fd_set的大小由FD_SETSIZE决定，Linux 默认是1024。如果你想监控超过1024个fd，就得自己改宏重新编译内核或程序，非常别扭。
• 集合是“输入输出一体”的：调用前你要把关注的fd设进去，内核返回后会原地修改fd_set，把没就绪的fd清掉。所以每次调用select()，你都得重建这个集合，又得重新遍历一遍所有fd，才能知道接下来要等谁。
• 就绪检测是O(n)的：内核不知道哪些fd是活跃的，它只能暴力扫描整个集合，检查每个fd是否有事件。返回后，应用层还要再扫描一遍完整的fd列表，才能找出就绪的子集。n个fd，每次都是满表扫。

select()的问题在于它把“等待”和“查找就绪fd”揉到了一起，每次调用都要做一遍完整扫描。连接数一多，它就成了瓶颈。这就像你让门卫把所有住户都点一遍名，才能知道谁家有客人来访，效率自然不高。

3.2 poll：解决了fd_set限制，但没解决线性扫描

poll()是对select()的改良，它不再用位图，而是用一个struct pollfd数组：

struct pollfd { int fd; // 要监控的文件描述符 short events; // 关注的事件（POLLIN / POLLOUT ...） short revents; // 内核返回的就绪事件 };

和select()相比，poll()有两个明确进步：

• 没有最大fd数量限制，你可以监控任意多的fd，只要内存够。
• events与revents分离，内核不会修改你传入的事件信息，你不需要每次调用前重新构造数组。

但它的核心性能瓶颈还在：内核依然通过遍历整个pollfd数组来判断哪些fd有事件，返回后，应用层也还要再遍历一遍才能知道哪些fd就绪了。10000个连接，每次poll()都是从头到尾扫一遍这10000个fd。如果大多数fd都没有事件，那么每次调用的大部分时间都花在了无意义的检查上。

poll()的另一个隐性问题是，连接数增加时，用户态和内核态之间拷贝的pollfd数组也在变大。用户态把数组拷贝给内核，内核检查完再拷贝回用户态，这部分内存拷贝的开销也会随连接数线性增长。如果你监控10000个fd，每个pollfd约8字节，一次poll()就要在用户态和内核态之间拷贝160KB的内存。虽然不至于致命，但也是实实在在的浪费。

3.3 从示例看select的使用逻辑和边界

我用select()写过一个简易的echo server，感受非常直观。关键代码大概是下面这个样子：

fd_set readfds; FD_ZERO(&readfds); int max_fd = -1; for (int i = 0; i < nfds; i++) { FD_SET(fds[i], &readfds); if (fds[i] > max_fd) max_fd = fds[i]; } int ready = select(max_fd + 1, &readfds, NULL, NULL, NULL); if (ready == -1) { perror("select"); return; } for (int i = 0; i < nfds; i++) { if (FD_ISSET(fds[i], &readfds)) { // 处理 fds[i] 上的数据 handle_event(fds[i]); } }

注意几个细节：

1. select()的第一个参数要求传入的是“最大fd数字+1”，不是fd数量。这很容易写错，而且新加fd的时候如果忘了同步更新max_fd，后果是内核根本没监控到那个新fd。
2. readfds在select()返回后已经被内核修改过了，只保留了就绪的fd。所以如果你要在下一次循环继续用，必须重新FD_ZERO()再重新FD_SET()一遍。这正是我前面说的“重复构造集合”问题。
3. 应用层依然要用FD_ISSET()从头到尾遍历一遍fd列表。连接数上万的时候，每次事件回来都要遍历全量fd，这成了无法回避的O(n)成本。

所以select()和poll()本质上都还是“线性扫描型”的多路转接，适合管理几百个fd，再往上就力不从心了。它们解决了应用层忙等轮询的空转问题，但没有解决“找就绪fd”的效率问题。

4. epoll的高效实现拆解：红黑树、就绪链表和两个回调

4.1 epoll_create/epoll_ctl/epoll_wait的三段式设计

epoll是Linux 2.6内核引入的多路转接机制，它一改select/poll的“每次调用传全量fd”的模式，用“三个函数、两个数据结构”的架构把事件监控做成了持久化操作。

第一步，epoll_create()创建一个epoll实例，内核返回一个文件描述符，它就是所有被监控fd的“集合”的家。第二步，epoll_ctl()负责管理这个集合：把fd加入、修改、删除。第三步，epoll_wait()阻塞等待，内核只返回“就绪的fd”，而不是让你自己扫全量列表。

这个设计最巧妙的地方在于：监控关系是持久的。fd加入epoll实例后，除非你显式删掉它，否则它在整个生命周期内都处于被监控状态。每次等待事件时，你不需要重新再把所有fd传一遍，内核自己维护着那份清单。这在根本上消除了select/poll每次调用都要重复拷贝和重复遍历的浪费。

4.2 内核侧的关键数据结构：红黑树与就绪链表

epoll高效的核心秘密在内核里的两个数据结构：

• 红黑树：用来存储所有注册到epoll实例的fd。插入、删除、查找都是O(log n)的复杂度。就算你有10万个连接，增删一个连接的开销也就是十几次比较，完全可以忽略。
• 就绪链表（rdllist）：用来存储“已经有事件发生”的fd。epoll_wait()只做一件事——把就绪链表中的fd复制到用户空间，然后清空链表。

这里的关键在于：就绪链表是怎么被填充的？答案是回调机制。每个被监控的socket在内核里都有一个等待队列，epoll_ctl()注册的时候，会往这个等待队列里挂一个回调函数。当socket的数据到达时，内核在唤醒等待进程的同时，会调用这个回调。回调函数做的事情就是：把当前fd加入到epoll实例的rdllist里。

注意，整个过程是“事件驱动”的——只有真正发生事件的fd才会出现在就绪链表里。所以你epoll_wait()返回时拿到的fd列表，就是“有事件且值得处理”的fd列表，不需要再自己扫一遍去判断谁就绪。这就是epoll能实现O(1)就绪检测的原因：它有事件才通知，没有事件就老老实实睡着。

用生活类比来说，select/poll是班主任每天早自习挨个点名，看谁到了；epoll是每个学生到教室的时候主动举手喊“我到了”，班主任只需要等学生举手就行，完全不用一个个去查。

4.3 LT vs ET：水平触发和边缘触发的取舍

epoll提供了两种事件触发模式：水平触发（Level-Triggered，LT）和边缘触发（Edge-Triggered，ET）。

LT模式是默认模式，也是和select/poll行为最接近的模式。它的规则是：只要fd上有未处理的事件，epoll_wait()就会反复通知你。比如一个socket的缓冲区到了100字节数据，你只读了50字节就调epoll_wait()，那么下次它还会再通知你“这个fd还有数据”。

LT模式对编程非常友好，即使你处理事件时不小心漏了一部分数据，下次还会收到通知，不会丢事件。但代价就是你可能会被“重复提醒”——如果某个fd的事件一直没处理完，它每次都会出现在就绪链表里，相当于内核在反复提醒你，这本身就是一种开销。

ET模式的规则是：只有当fd的状态发生变化时，才通知一次。比如缓冲区从空变为有数据，这是“从无到有”的边沿，会触发通知；但如果第一次通知后你没有读完数据，第二次epoll_wait()就不会再通知你了，直到有新的数据再次到达。

ET模式的收益是通知次数大幅减少，更高效。但代价是编程难度提高：你必须在一次通知中把数据尽量读完（通常读到返回EAGAIN为止），否则就可能漏掉数据。这也是为什么使用ET模式时，fd必须设置为非阻塞——因为你必须在循环里一直读，直到读空，而阻塞IO在读完数据后会挂在那里，整个线程就卡死了。

4.4 ET模式下必须配合非阻塞IO的原因

进一步解释一下ET模式和非阻塞IO的关系。在ET模式下，你收到一个可读事件，意味着“fd的状态刚刚从无数据变成了有数据”。为了不遗漏任何数据，你需要在这次事件中把数据尽量处理完，处理完的标志就是read()返回EAGAIN，表示“缓冲区已经读空了”。

如果你使用的是阻塞IO，那么当你读到缓冲区为空时，read()会阻塞在那里，等待下一批数据到来。可问题是，现在还没有新数据，你阻塞了，整个线程就卡住了。更糟的是，因为你卡在read()里，你没法回头调用epoll_wait()去等待其他fd的事件，其他连接的事件全部得不到处理。

这就是为什么在每个使用ET模式的epoll server里，你一定会看到类似这样的代码：

// 非阻塞fd上，边沿触发的读循环 while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { handle_data(buf, n); } else if (n == -1 && errno == EAGAIN) { break; // 数据已读完，退出读循环 } else { handle_error(fd); break; } }

这里的read()只有在fd为非阻塞时，才能在你把数据读完之后返回EAGAIN，让你跳出循环，回到epoll_wait()继续等待。所以 ET + 非阻塞IO 这套组合拳，是Linux高并发编程中最常见、也是效率最优的IO姿势之一。

5. 实战应用的选择逻辑：为什么Redis、Nginx、Netty全走这条路

理论讲清楚之后，更有意思的是看真实的高性能组件是怎么把这些机制组合起来的。你会发现它们的选择惊人地一致：非阻塞IO打底，多路转接管事件分发，事件循环处理业务。

5.1 Redis的单线程事件循环：为什么听上去“单线程”却能抗高并发

Redis 的核心是单线程事件循环，它用ae.c这个事件驱动库封装了底层的多路转接API。在Linux上默认就是epoll，逻辑可以简化成下面的循环：

while (1) { // 等待就绪事件 numevents = epoll_wait(epfd, events, maxevents, timeout); for (j = 0; j < numevents; j++) { // 根据就绪事件的fd分发到对应的事件处理器 dispatch(events[j]); } }

注意这里的epoll_wait()返回的是就绪事件的数量和列表，不是全部fd。假设有一万个客户端连接，但某一时刻只有10个连接有请求到达，epoll_wait()返回的就只有这10个fd。Redis只需要处理这10个fd上的命令即可，完全不需要关心另外9990个连接。

这就是Redis能抗住每秒十万级QPS的关键原因之一。单线程的意义在于规避了锁竞争和线程切换，而epoll让它“单线程照样能同时管理海量连接”。你可以把 Redis 的事件循环想象成一个高效的门卫：他不需要记住所有住户的样子，因为住户谁有访客谁就按门铃（事件回调），他只需要响应门铃声就行。

需要提醒的是，Redis虽然是单线程事件循环，但在实际的网络IO处理上，非阻塞IO保证了它不会因为某个连接的数据没准备好而卡住整个循环。每个连接的数据到达路径都是“事件触发->读取数据->处理命令->返回结果”，一旦某个fd的数据读完了，read()返回EAGAIN，Redis就回到epoll_wait()继续等待下一个事件，整个循环绝不阻塞在任何单个连接上。

5.2 Nginx的accept_mutex与负载均衡思路

Nginx同样基于事件驱动架构，它的worker进程每个都有自己的epoll实例，管理着自己负责的那批连接。但Nginx比Redis更复杂的一点在于多进程之间的协调。多个worker进程都监听同一个socket，当一个新连接到达时，如果所有worker都被唤醒去accept()，会引发“惊群”问题——大家都在抢同一个连接，最后只活一个，其他白忙一场。

Nginx的解法是accept_mutex：多个worker通过锁来竞争，同一时刻只有一个worker能持有监听socket的接收权。这样的事件通知配合epoll_wait()，让Nginx在高并发下还能维持很低的内核唤醒开销。这个设计思路对你自己写多进程服务也有借鉴意义：epoll的注册关系是每个进程各自独立的，如果多个进程都在epoll里注册了同一个监听fd，内核就得考虑要不要唤醒所有进程——这个问题在写网关类服务时很常见。

5.3 方案选型小抄：什么场景用poll、什么场景直上epoll

我简单总结一个选型参考，不妨直接抄作业：

如果你是在Linux上做高并发服务，直接用epoll是唯一合理的选择。select和poll不是说不能用，但它们在高fd数量下的线性扫描是硬伤，你迟早要换掉，与其等踩坑再换，不如一开始就走epoll的路子。

6. 写代码容易踩的几个坑：来自真实项目的排查笔记

理论滚了一遍之后，落地的时候才是真正出问题的地方。我自己在非阻塞IO和epoll的项目里踩过不少坑，有几个非常有代表性，写出来帮大家避一避。

6.1 文件描述符上限的坑

第一个坑是进程级的fd数量上限。Linux默认单个进程能打开的fd上限通常是1024，不管你是用select还是epoll，这个限制都卡着你。用ulimit -n就能看到当前值。在高并发的环境里，你必须把这个上限调大，常见的做法是调到65535甚至更高。

注意，调大这个是有限制的，还要看系统级的限制/proc/sys/fs/file-max，如果系统级设置不够，进程级再怎么调都没用。我见过一个服务，epoll代码写得完全没问题，压测到两千个连接时就开始报EMFILE（打开的文件过多），排查了大半天才发现是/etc/security/limits.conf里的nofile没调。这种问题一旦遇到，很容易怀疑是代码逻辑出错了，实际上就是资源限制。

6.2 EAGAIN不处理导致的空转

第二个坑是忘了处理EAGAIN，导致事件处理逻辑陷入空转。我收到过不止一次线上CPU飙到100%的报警，最后定位原因，都是某个fd上持续出现可读事件，应用层去读取时又只读了一部分，下次epoll又通知同fd可读，反复循环，就像一个永远干不完活的死循环。

LT模式下尤其容易出这种问题。如果你注册了可读事件，但读数据的逻辑不够积极——比如每次只读一小段缓冲区就退出，那么内核会反复通知你这个fd可读，你就反复去读那一点点数据，造成浪费。解决方法是：在LT模式下，只要事件通知到了，就尽量读完当前缓冲区中已有的数据，直到read()返回EAGAIN，再回到epoll_wait()。这虽然不是ET模式的硬性要求，但能显著减少无意义的重复通知。

6.3 与业务线程共享fd的关闭时机问题

第三个坑比较隐蔽，是我在实现多线程+epoll混合模型时遇到的。主线程在epoll_wait()中等待事件，业务线程负责处理耗时任务。当一个连接的请求处理完毕，业务线程会关闭这个socket。可是主线程同时还在epoll实例里挂着这个fd。如果业务线程先关了fd，而主线程又恰好从epoll_wait()里拿到了这个fd的事件，就会出现对已关闭fd进行操作的情况——更麻烦的是，这个fd的编号可能立刻被复用给了一个新连接，导致对“新连接”执行了“旧连接”的操作。

我当时的解决方案是：所有关闭操作统一回到事件循环线程中执行。具体怎么做呢？（1）业务线程不直接关闭socket，而是往事件循环线程的待处理队列里丢一个“关闭连接”的任务；（2）事件循环线程在处理完当前批次事件后，统一从epoll中移除这些fd，再执行关闭。这样就能避免fd在epoll实例中被意外清理时出现的竞态问题。如果你的架构中也存在多线程共享fd的情况，建议尽早设计一套统一的fd生命周期管理方案，别等线上出怪问题了再来排查。

6.4 不要忽略EPOLLERR和EPOLLHUP事件

第四个坑是只关注EPOLLIN和EPOLLOUT，忽略EPOLLERR和EPOLLHUP。在 epoll 的实践里，这两个事件通常意味着连接出错、对端关闭了连接、或者socket发生了异常。很多新手的写法是：

if (event.events & EPOLLIN) { handle_read(fd); } if (event.events & EPOLLOUT) { handle_write(fd); }

然后不处理EPOLLERR和EPOLLHUP，结果就是连接已经挂了，你的程序还在傻傻地等它可读。正确的处理方式一般是把错误事件和读事件合并判断：只要events里有EPOLLHUP或EPOLLERR，就主动关闭连接、清理资源。这样能在对端异常断开时及时回收资源，不至于让连接对象越积越多。

这几个坑是我实际项目中反复踩过的，现在写代码时会刻进肌肉记忆里。很多问题看起来是“偶发”的，实际上是fd生命周期管理不当或者事件处理不完整导致的必然结果。

7. 写在初篇末尾的几句实在话

把这套机制彻底吃透之后，再回头看最初那个压测失败的网关服务，问题就很清楚了：阻塞IO下的线程模型撑不起成千上万的并发连接，不是线程池参数调得不好，而是模型本身有天花板。换成epoll事件驱动模型之后，同样的机器，直接扛住了之前5倍的并发量，CPU利用率反而降了20%。非线性收益，就是这么立竿见影。

关于这篇“初篇”，我刻意从非阻塞IO和轮询机制讲起，再一步步走到多路转接，目的就是让整个过程有个清晰的演进脉络。非阻塞IO是基础，轮询机制是必经之路，多路转接是最终的高效解法。如果一上来就甩epoll的API，很容易陷入“会调用但不理解”的尴尬境地，等遇到线上疑难杂症时，连排查方向都找不到。

下一篇我大概率会写多路转接中“写事件”和“边缘触发模式”的工程细节，尤其是ET模式下如何处理部分写入、如何应对EPOLLOUT的频繁触发这些实操话题，都是我在代码里被磨过的亲身经历。如果你正准备从阻塞模型转向事件驱动，或者正在用epoll写高性能服务，这篇的内容应该能给你省下不少趟坑的时间。

最后想说的是，IO模型这套东西，光看明白和真正能在项目里用熟练，中间隔着很多实际操作上的差距。如果你读完这篇，能照着思路自己写一个小型的epoll echo server跑一跑，那它的价值才算真正落地了。