前阵子好几个开发朋友来问我同一个问题：用 epoll 写的服务，连接少的时候收发都正常，客户端一多就偶发卡顿，甚至丢数据；还有人用 select 写聊天室，人过了一百直接没反应。聊到最后，问题都指向多路 IO 复用里那几个“书上没细讲、网上答案又散”的细节上。

这篇内容就是把这些高频问题集中补一遍。适合已经会写简单回显服务、了解 select/epoll 基本用法，但又在实际项目里被各种怪异现象折磨过的开发者。我会尽量围绕真实场景讲，不堆概念，直接说为什么要这么做、坑在哪、怎么排查。

1. 先别急着选型：select 和 epoll 的核心差异在那里

很多人的认知是“select 慢、epoll 快”，然后直接选 epoll。这个结论大方向没错，但如果你不理解两种机制背后的工作方式差异，后面遇到问题基本要靠猜。

1.1 select 的“就绪状态突变”是一个隐藏包袱

select 最容易被忽略的一个特性是：它传入的三个 fd_set 既是输入也是输出。内核会在这三个 bitmask 上标记哪些 fd 就绪，返回给用户态。这就意味着，每次调用 select 之前，你必须重新构造 fd_set；调用之后，你还要遍历全部 fd，逐个用 FD_ISSET 去测试。

更隐蔽的问题是，select 返回后，没有就绪的 fd 对应的 bit 会被内核清掉。如果你把 fd_set 保存在某个地方，下一轮循环不重新初始化就直接复用，本来有事件等待处理的 fd 会被静默丢弃。

另一个天然限制是 FD_SETSIZE，默认 1024。如果你在代码里直接定义 fd_set，那么 fd 编号超过 1023 的连接根本没法管理。虽然重新编译内核或扩大宏可以突破这个数，但 select 的复杂度是 O(n)，连接数上千后，每次调用都要在内核态和用户态之间拷贝几百上千字节的 bitmask，再线性扫描，这个成本会非常难看。

所以 select 在我心里的定位是“小规模、多平台、快速实现”的备选方案，而不是大规模并发服务的地基。它的问题不是慢，而是它的工作模型决定了它不适合“事件驱动的大型状态机”。

1.2 epoll 的就绪链表机制，以及 LT/ET 的核心区别

epoll 和 select 最大的结构差异在于：内核通过 epoll_ctl 把 fd 和关注的事件注册进一棵红黑树，同时当 fd 有事件时，内核会通过回调把该 fd 放入一个就绪链表。调用 epoll_wait 时，内核只是把就绪链表里的数据拷贝给用户态，不会去扫描全部连接。

这就带来了两种触发模式：

水平触发（LT）：只要 fd 的缓冲区里还有数据可读，或者缓冲区还可写，每次 epoll_wait 都会返回该 fd。它和 select 的“轮询”很相似，都是我在某次调用中发现某个 fd 可读，处理不完下次还能继续处理。

边缘触发（ET）：只在 fd 状态从“没事件”变为“有事件”的那一刻通知一次。如果这次你没有把数据读完，之后内核不会再因为这批数据触发通知，除非又有新数据到达。

我来举个直观的例子。客户端一次性发送 100 字节，你的服务端一次只 read 了 10 字节。LT 模式下，下一次 epoll_wait 还是会告诉你“这个 fd 可读”，你可以继续读。ET 模式下，对不起，内核不会再次通知你。剩下的 90 字节就静静躺在内核缓冲区里，直到客户端再发新数据，才会再一次触发通知。

这正是 ET 模式容易“丢数据”的原因。很多人用 LT 的惯性思维写 ET 逻辑，流量一上来数据就莫名其妙地少，就是这个状态变化机制没搞懂。

1.3 为什么边缘触发必须配非阻塞 IO

ET 模式要求在事件到来时“尽可能一次读完”，直到 read 返回 EAGAIN 才算把缓冲区榨干。但如果你把 fd 设成阻塞模式，在读到缓冲区为空时，read 会阻塞住整个线程，而不是立即返回 EAGAIN。这意味着这个线程上的其他连接全部被卡死。

所以 ET 模式的标准配套是：把相关 fd 设为非阻塞，然后循环调用 read，每次读取固定大小的 buffer，直到返回值小于 buffer 大小或者 errno 为 EAGAIN。

这一步很关键，也经常被忽略。我见过不止一个项目在 ET 模式下“似乎能跑”，但在一次大胆的业务请求触发阻塞读之后，整个服务吞吐量直接掉到零，定位半天发现是 read 卡死。如果你选择 ET，非阻塞这个前提条件必须刻在脑门上。

2. 这些高频问题，一线开发几乎都会遇到

2.1 非阻塞 connect 怎么用 epoll 判断连接成功

写网络服务时，往外发起连接也是很常见的需求。有人直接在 epoll 里监听一个 socket 的 EPOLLOUT，以为“可写”就是连接成功。实际上 EPOLLOUT 可能由多种原因触发，你不能仅凭它来判断连接是否建立。

标准的非阻塞 connect 流程是这样：

1. 创建 socket，设置 O_NONBLOCK。
2. 调用 connect，如果返回 0，连接立即建立；如果返回 -1 且 errno 为 EINPROGRESS，说明连接正在建立中。
3. 把这个 fd 注册进 epoll，监听 EPOLLOUT。
4. 当 epoll_wait 返回 EPOLLOUT 事件时，调用 getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len) 获取 socket 错误状态。
5. 如果 err == 0，连接建立成功；否则连接失败，错误码就是 err。

int ret = connect(fd, addr, addrlen); if (ret < 0 && errno != EINPROGRESS) { // 立即失败 return -1; } // 注册 EPOLLOUT struct epoll_event ev; ev.events = EPOLLOUT; ev.data.fd = fd; epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);

等 EPOLLOUT 到达后：

int err; socklen_t len = sizeof(err); getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len); if (err == 0) { // 连接成功，记得把监听事件改回 EPOLLIN } else { // 连接失败 close(fd); }

这里有个小细节：getsockopt 返回的 err 才是真正的连接结果，而不是去看 errno。很多人在这里把 errno 当作判断依据，结果永远拿不到正确状态，因为 errno 在函数调用链中会被重置。

2.2 accept 的惊群问题与 EPOLLEXCLUSIVE

多进程或线程模型里，如果多个进程同时 epoll_wait 同一个 listen fd，当一个新连接到达时，在旧版本内核上所有等待者都会醒过来，但最终只有一个能 accept 成功。这个现象叫“惊群”。

Linux 内核做了一些改进：对 accept 本身做了去重，但 epoll_wait 层面的惊群在内核 4.5 之前依然存在。内核 4.5 之后引入 EPOLLEXCLUSIVE 标志，它可以保证把一个唤醒事件只交给一个等待者，从而避免惊群。

使用 EPOLLEXCLUSIVE 时需要注意：它不能和 EPOLLONESHOT 同时指定，否则 epoll_ctl 会返回 EINVAL。另外在多线程模型下，如果你只在 listen fd 上加了 EPOLLEXCLUSIVE，而后端 worker 还是共享同一个 epoll fd，那依然可能出现多个 worker 同时被同一个事件唤醒。常见的做法是：每个 worker 都有自己的 epoll fd，并且都在同一个 listen fd 上注册 EPOLLEXCLUSIVE 事件。

如果项目对稳定性要求高，又不想深入研究这些并发细节，更朴素的方案是：用一个单独的线程 accept，accept 成功后把新连接分发给空闲 worker。这个模型代码简单、逻辑清晰，很少有人会惊群，值得在早期版本使用。

2.3 EPOLLONESHOT：多线程业务下防止重复处理

当你把 fd 交给一个线程池去处理业务数据时，可能遇到一个场景：同一个 fd 上有多个事件连续到达，线程池里不同线程同时被唤醒，结果同一个连接的数据被两个线程同时处理，逻辑上就会串掉。

epoll 提供的 EPOLLONESHOT 能从根本上避免这个问题：它让内核在该 fd 触发一次事件后，把它从 epoll 的监听队列里摘除，后续不再触发，直到你显式调用 epoll_ctl 以 EPOLL_CTL_MOD 方式重新注册。

典型使用流程：

• 主线程注册 fd 时设置 EPOLLONESHOT。
• epoll_wait 返回某个 fd 的事件后，把这个 fd 交给线程池处理。
• 业务线程处理完当前数据后，重新调用 epoll_ctl(EPOLL_CTL_MOD) 注册这个 fd，让它回归到监听队列。

这个机制对内置状态机、半包处理、长时间业务逻辑都非常重要。没有它，就要自己在业务层加锁或者搞状态标记，很容易出竞态问题。

需要特别注意的是：重新注册时，fd 可能已经处于“未处理完”的状态，如果在 ET 模式下重新注册，内核是否会认为有新事件产生。这个行为在不同内核版本之间并不完全一致，所以稳妥做法是：在重新注册前，把 fd 上剩余数据读完或维护好读缓冲，不要让 ET 模式下的事件边界模糊。

2.4 EPOLLRDHUP / EPOLLHUP / EPOLLERR：断线检测别用错事件

对端关闭连接时，不同情况会触发不同事件，搞清楚这些事件的含义，能避免很多误判。

• 对端正常调用 close，发送 FIN 包：你会收到 EPOLLIN（因为可以 read 到 EOF，即 read 返回 0），同时也可能收到 EPOLLRDHUP。这里 EPOLLRDHUP 是 Linux 3.0 之后提供的半关闭检测事件，能明确告诉你“对端关掉了读方向”。
• 对端异常断开，比如网络中断、进程崩溃未发 FIN：不会立刻有事件。等你向它写入数据时，可能收到 EPIPE 或 ECONNRESET，此时 epoll 上可能出现 EPOLLERR 或 EPOLLHUP。
• EPOLLHUP 表示通信双方的两个方向都关闭，通常伴随 fd 释放；EPOLLERR 表示 socket 发生错误，比如收到了 RST。

判断连接是否存活，最可靠的标准还是看 EPOLLIN + read 返回 0。很多老代码通过判断 EPOLLHUP 或 EPOLLERR 来关闭连接，其实并不可靠，因为在某些半关闭场景下，EPOLLHUP 并不会出现，或者出现得比你预期晚很多。

另外，EPOLLRDHUP 需要在注册事件时单独指定，epoll 并不会自动帮你监听半关闭。如果你只在 events 里写了 EPOLLIN，那对端 close 时你还是只会看到可读，然后在 read 时拿到 EOF 才知道对方断开。对于需要及时感知半关闭的业务，比如聊天软件里对方退出的瞬间要立刻展示，建议注册 EPOLLIN | EPOLLRDHUP。

3. 问题补充：从报错到处理，一套排查思路

3.1 EPOLLERR 不代表立刻关闭连接

很多人收到 EPOLLERR 事件，习惯性直接 close(fd)。但这不一定对。EPOLLERR 只是告诉你这个 socket 出了问题，具体问题是什么，需要进一步确认。

常见的情况：对端发送 RST 时，socket 上可能有尚未读取的数据，也存在未已被消费的错误状态。如果你直接关闭，那么一部分已经到达的数据就没有机会被应用层处理。

正确姿势是收到 EPOLLERR 后，先尝试 read 一次，并记录 read 的错误码。如果 read 返回 -1 且 errno 是 ECONNRESET 或 EPIPE，说明连接已经不可用，再关闭。如果 read 还能读到数据，说明连接虽然出了问题，但数据至少还能读到，业务上可以先处理数据再决定是否关闭。

还有一个细节：当对端发送 RST 后，你试图 write 这个 fd，write 会触发 SIGPIPE 信号，默认行为是终止整个进程。很多线上服务偶发崩溃，就是漏掉了这点。解决方案是把 SIGPIPE 忽略掉（signal(SIGPIPE, SIG_IGN)），然后通过 write 的返回值和 errno 来感知连接异常。

3.2 ET 模式“读不完、EAGAIN 了还丢数据”的正确做法

ET 模式下最常见的 bug 是：只读一次，或者循环读但没正确判断 EAGAIN。这两种都会导致数据丢失。

正确的读取循环长这样：

char buf[4096]; while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { // 把 buf 交给业务层处理 } else if (n == 0) { // 对端关闭 close(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 数据已经读完了 break; } // 其他错误，处理异常 break; } }

注意 errno == EAGAIN 的判断必须在 n < 0 的分支里。有些初学者会把 EAGAIN 和 n == 0 搞混，导致对端正常关闭时被当作“暂时无数据”处理，连接永远不释放。

ET 模式还有一个很隐蔽的问题：如果 read 一次只读了 4096 字节，而对方发送了 100KB，你最后必然读到一个 EAGAIN，但如果在这之前你把一部分数据放在业务队列里，而又没有维护好每个 fd 的读缓冲，半包拼接逻辑就容易出错。

协议设计上，如果每个消息都有固定长度或者带长度字段，那 ET 模式的实现就相对舒服；如果协议靠分隔符划分消息，ET 模式下你必须有一个完善的“读缓冲队列”，把每次 read 的数据追加进去，再按分隔符切包。这个缓冲队列的管理复杂度，是 ET 模式的真实成本。

3.3 用 select 时，消息偶尔“丢”了是为什么

如果你还在用 select，并且遇到“数据偶尔丢了一部分”的情况，大概率是 fd_set 的复用问题。

比如这样写：

fd_set read_set, all_set; FD_ZERO(&all_set); FD_SET(listen_fd, &all_set); while (1) { read_set = all_set; // 每次拷贝 select(maxfd + 1, &read_set, NULL, NULL, NULL); for (int i = 0; i <= maxfd; i++) { if (FD_ISSET(i, &read_set)) { if (i == listen_fd) handle_accept(); else handle_read(i); } } }

这个写法是对的，因为它每次循环都重新赋值。

但如果你写成：

select(maxfd + 1, &all_set, NULL, NULL, NULL); for (...) { if (FD_ISSET(i, &all_set)) ... }

那么第二次循环时，all_set 已经被内核改成了“只有就绪 fd 的集合”，未就绪的 fd 全被清了。下一轮 select 时，那些 fd 其实还关心的事件，结果因为 fd_set 里没有它们，直接被忽略。表现就是：某个连接的数据来了，但服务端永远收不到，看起来像丢消息。

另一个 select 的坑：如果你在一次可读事件中没有把数据全部读完，而只是处理了开头一部分，那么对端不再发新数据时，这个 fd 不会再出现在就绪集合里。因为 select 的“可读”状态是“是否有数据可读”，如果你处理完一部分，内核缓冲区里还有剩余数据，它下一轮还是会就绪的。但如果你在业务上把“读到部分数据”当成“消息已消费”，下一个消息的字节流粘在一起，看起来就是“第一个消息丢了”。

解决这些问题没有捷径：要么检查 fd_set 的重新构造逻辑，要么直接切换到 epoll，让事件通知机制更可控。

3.4 epoll_wait 超时返回0，为什么心跳还是断了

很多服务的主循环长这样：

while (1) { int n = epoll_wait(epfd, events, MAXEVENTS, timeout_ms); for (int i = 0; i < n; i++) { handle_event(events[i]); } }

然后你发现，整个服务很空闲，只有几十个连接挂着，但某些连接的心跳超时了，对端已经断开，服务端却没有及时感知。

原因是：epoll_wait 返回 0 只表示“本次等待超时，没有 fd 就绪事件”，它不会帮你执行任何业务逻辑。如果你把心跳发送、超时检查这类定时任务都放在事件循环之外，那么它们只有在有事件发生时才有机会被处理。一旦某个时间段一直没有网络事件，心跳任务就被无限期延后。

正确模型是：把 epoll_wait 的超时参数当成“定时器的最短触发周期”。每次 epoll_wait 返回后，不管有没有事件，都去检查当前时间，看看哪些连接该发心跳了、哪些连接超时了。

更复杂的做法是引入一个最小堆或时间轮来管理定时任务，把 epoll_wait 的 timeout 设置为“最近一个即将到期的任务的时间差”。这样事件循环既能及时响应网络事件，又能保证定时任务不饿死。

4. 常见问题的实测对比与选型经验

4.1 连接数量级不同，选型完全不同

很多新人问“select 和 epoll 哪个好”，我一般会反问他一句：你的服务是面向什么场景的？

如果只是几十个连接、开发周期短、希望代码简单可移植，select 完全可以胜任。它的代码直观，调试容易，而且在连接数少时性能差距根本不明显。

一旦连接数上升到几百、几千甚至上万，select 的线性扫描和 fd 上限就成了硬伤。这个时候 epoll 的 O(1) 级别的复杂度才能真正体现优势，而且 epoll 的就绪链表只返回活跃连接，避免大量无效遍历。

我整理过一个简单的对比表：

这个表格只是参考，实际选型时还要考虑团队对这个机制的熟悉程度。如果你组里没人写过 epoll 的 ET 模式，那就别为了“压榨性能”硬上 ET，LT 模式配合非阻塞 IO 已经能扛住绝大多数业务。

4.2 从维护成本看 LT vs ET 的最终选择

我很长一段时间都倾向 LT，因为 LT 的语义和 select 接近，心智负担小。处理流程是：epoll 告诉你可以读，你就读，读不完没关系，下次还会告诉你。这样即使业务层处理半包逻辑不完美，至少不会因为“没一次读完”而把数据弄丢。

ET 模式真正适合的场景是：连接数巨大、每个连接的数据到达非常频繁、上层处理速度极快，你希望减少 epoll_wait 的通知次数，让每次系统调用带回尽可能多的数据量。这时候 ET 的“只通知一次，一次全读走”能降低内核态和用户态的切换成本。

但 ET 模式有代价：必须保证每个事件都“一次处理干净”，并且整个事件循环里的每个 fd 都必须非阻塞。这在小项目里还能控制，在大规模业务里，任何一个 fd 漏了非阻塞设置，就能把整个服务拖死。

所以我的结论是：LT 是默认选项，ET 是优化选项。绝大多数业务先用 LT 把功能跑通，在压测确认瓶颈确实是系统调用次数过多时，再考虑切换到 ET。切换前准备好完整的读缓冲管理方案。

4.3 再补一个容易忽略的“半包/粘包”误区

最后提一个容易被归罪于多路 IO 复用的问题：粘包。

很多人发现用 epoll 写的服务“收到数据不完整”，第一个怀疑对象是事件驱动没写好。但 TCP 本身是字节流协议，没有任何消息边界。它不保证一次 read 能拿到一个完整业务消息，也不保证两个业务消息不会被合并成一个 read 返回。

这个问题的根源在协议层，不在 epoll 或 select。你需要自己设计帧格式，常见做法有四种：

• 固定长度：每个消息都是相同字节数，按长度切分。
• 长度前缀：消息头部用一个固定字段表示载荷长度。
• 分隔符：消息之间用特定字符分隔，比如 HTTP 的 \r\n\r\n。
• 自描述格式：消息头部包含总长度和类型，剩下按类型解析。

无论你用什么多路复用模型，都要在业务层维护一个“接收缓冲 + 分包解析”状态。ET 模式下这个缓冲必须做得更严谨，因为一旦没读完，下一次通知可能遥遥无期，缓冲区就是唯一的数据来源。

我实际用过的方案是：每个连接的接收缓冲区用一块动态扩容的内存块，先按最大可读字节数读入，然后循环解析出完整消息，剩余字节保留在缓冲区头部，等待下一次数据到达继续拼接。这个思路在 LT 和 ET 下通用，区别只是 ET 要求每次读取要更彻底。

踩过不少坑之后，我个人的体会是：多路 IO 复用的技术难点不在 API 本身，而在你把“事件通知”和“业务处理”两条线结合起来的边界处。select 的 fd_set 复用、epoll 的 LT/ET 语义、非阻塞 IO 的边界情况、断线检测的事件选择，每一条单独看都不难，但组合在一起就会暴露各种隐藏假设。

如果你还在为自己服务的偶发丢包或者线程卡死发愁，先别急着换更复杂的框架，把这篇文章里提到的几个点逐项对照检查一遍。很多“莫名其妙”的问题，其实都出在那些你以为理所当然、但实际没写对的细节上。