前阵子好几个开发朋友来问我同一个问题用 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 为什么边缘触发必须配非阻塞 IOET 模式要求在事件到来时“尽可能一次读完”直到 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 流程是这样创建 socket设置 O_NONBLOCK。调用 connect如果返回 0连接立即建立如果返回 -1 且 errno 为 EINPROGRESS说明连接正在建立中。把这个 fd 注册进 epoll监听 EPOLLOUT。当 epoll_wait 返回 EPOLLOUT 事件时调用 getsockopt(fd, SOL_SOCKET, SO_ERROR, err, len) 获取 socket 错误状态。如果 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 事件。如果项目对稳定性要求高又不想深入研究这些并发细节更朴素的方案是用一个单独的线程 acceptaccept 成功后把新连接分发给空闲 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 这个 fdwrite 会触发 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 的就绪链表只返回活跃连接避免大量无效遍历。我整理过一个简单的对比表维度selectepollfd 数量上限默认 1024需要重编译才能扩大受系统最大文件描述符限制远超 select复杂度O(n)每次都要全量扫描O(就绪数量)只返回活跃 fd就绪事件检测每次调用都要重新设置 fd_set通过回调维护就绪链表无需重新注册触发模式仅水平触发支持 LT ET状态维护用户态和内核态反复拷贝内核通过 epoll_ctl 统一维护跨平台性广泛支持Windows 等平台有对应实现主要是 Linux 平台这个表格只是参考实际选型时还要考虑团队对这个机制的熟悉程度。如果你组里没人写过 epoll 的 ET 模式那就别为了“压榨性能”硬上 ETLT 模式配合非阻塞 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 的边界情况、断线检测的事件选择每一条单独看都不难但组合在一起就会暴露各种隐藏假设。如果你还在为自己服务的偶发丢包或者线程卡死发愁先别急着换更复杂的框架把这篇文章里提到的几个点逐项对照检查一遍。很多“莫名其妙”的问题其实都出在那些你以为理所当然、但实际没写对的细节上。