线上服务跑着跑着连接数就上不去了，CPU 看着不高，内存也稳，但吞吐量就是压不出曲线，这种时候十有八九要回到网络IO模型这一层去找答案。很多人对网络IO模型的理解停留在背八股：阻塞、非阻塞、多路复用、信号驱动、异步，五张图一画，名词一列，面试能过，真上手写服务端还是抓瞎。我这些年做过的连接密集型服务里，真正决定性能上限的往往不是业务代码写得多精巧，而是最开始那一下选型：你是每连接一个线程死等，还是用一个事件循环把几万个连接管起来，这两条路的分岔口，就在网络IO模型上。

这篇东西想干的事很明确：把网络IO模型从概念拉到地面上。前半段讲清楚一次 read 在内核里到底走了哪几步、五种模型分别在哪一步做了不同的选择、为什么说“等数据”和“搬数据”是两个阶段；中段用 epoll 写一份能直接跑的最小服务端，把 LT 和 ET 的坑一个个点出来，顺带把 backlog、fd 上限、maxevents 这些参数怎么估讲明白；后半段聊 Reactor 怎么把 IO 模型组织成架构，再把我自己踩过的连接数上不去、CPU 打满 QPS 不涨、ET 模式连接卡死这些问题的排查路径整理成速查表。适合已经能写点服务端代码、但对高并发场景心里没底的读者，也适合面试前想把这块从“背过”变成“懂了”的人。

1. 先把“IO”这件事拆开看，模型选择比代码优化更值钱

1.1 一次 read 调用在内核里到底发生了什么

很多人以为read(fd, buf, n)就是个简单的内存拷贝，实际上它是一段有明确阶段划分的流程。用户态发起系统调用后陷入内核，内核先看这个 socket 的接收缓冲区里有没有已经就绪的数据：有，就直接把数据从内核缓冲区拷到用户空间，返回实际字节数；没有，就要看这个 fd 是不是阻塞模式——阻塞模式就把当前进程挂到这个 socket 的等待队列上睡过去，非阻塞模式就立刻返回一个EAGAIN错误码让调用方自己看着办。

而数据是怎么进到内核缓冲区的？网卡收到以太网帧之后，通过 DMA 把数据写进内存里的环形缓冲区，然后触发硬件中断；内核在中断处理里做最小化的工作，把后续的协议栈处理丢给软中断；软中断里走完 IP 层、TCP 层的校验、排序、去重，把有效载荷挂到对应 socket 的接收队列上，最后唤醒这个 socket 等待队列上睡着的进程。这个唤醒动作，就是“数据就绪”的信号来源。

把这整条链路摊开，你会发现任何一次网络读取都必然包含两个阶段：等待数据就绪和把数据从内核空间拷贝到用户空间。前者耗时不可控，取决于对端什么时候发、网络抖不抖；后者是实打实的内存拷贝，量级和你要读的字节数正相关。所谓五种网络IO模型，区别根本不在第二阶段，而全在第一个阶段——你是傻等、是隔一会儿问一次、是让别人替你盯着、还是干脆让内核全干完再通知你。把这个视角建立起来，后面所有的名词都能自动归位。

1.2 五种模型的分水岭只有一句话

我习惯用一句大白话来区分它们：谁在等、怎么等、等到了谁去搬。

阻塞IO是调用方自己等，一直睡到数据就绪，然后自己搬；非阻塞IO是调用方不停地问“好了没”，没好就去干别的，好了自己搬；IO多路复用是调用方找一个代理人（select/poll/epoll）同时盯着一堆 fd，代理人说有动静了，调用方再自己去搬；信号驱动IO是调用方留个电话（注册 SIGIO 信号处理函数），内核数据就绪了打电话通知，调用方再自己去搬；异步IO是调用方把活整个外包出去，内核把数据都搬进用户缓冲区了才通知“活干完了”。

看明白没有？前四种模型的第二阶段都得应用自己动手，只有最后一种连拷贝都由内核代劳。这也是为什么很多号称“异步”的框架其实只是“多路复用 + 回调”，它们在语义上属于同步IO——因为真正的数据拷贝那一下还是阻塞在某个线程上的。这个区分在面试里经常被拿来挖坑，实际工程里也直接影响你怎么设计线程模型：如果你的“异步”底层还是同步拷贝，那大文件传输场景下照样会把事件循环卡住。

1.3 为什么阻塞模型在低并发下反而是最优解

这里得说句公道话，阻塞IO不是垃圾。一个连接数只有几十、每个请求处理时间又比较长的服务，用阻塞IO配线程池是最省心的：代码线性、调试友好、异常栈清晰，出问题一眼能看出卡在哪一行。真正的麻烦出现在连接数往上走的时候——每个连接至少占一个线程，线程栈默认 8MB（可调，但再小也有限），线程切换有上下文开销，几千个连接就能把调度器拖得够呛。

我见过一个内部工具，早期用“一连接一线程”写得飞快，后来接入方从 3 个涨到 200 个，机器负载就开始飘。改成多路复用之后，代码量翻了大概一倍，但同样的机器稳稳吃住了后来的量。这个取舍很现实：如果你的并发上限能预估在几百以内，别急着上 epoll，那是给自己找麻烦；一旦预期会到几千甚至上万，越早换模型越省事，因为业务代码会长在模型之上，迁移成本只会越来越高。

2. 五种网络IO模型逐一过筛，讲清楚每种的真实取舍

2.1 阻塞IO：老实，但会把线程池吃干净

阻塞IO的调用链最简单：accept阻塞等连接，read阻塞等数据，write阻塞等发送缓冲区有空位。整个过程里线程就是被“钉”在这个 fd 上的，什么也干不了。它的优点是心智负担极低，缺点是把“等待”这种廉价的事和“线程”这种昂贵的资源绑在了一起。

真正的坑不在单连接慢，而在慢连接会把线程池抽干。假设线程池 200 个线程，来了 200 个客户端，其中 50 个是网络极差或者故意只连不发的，这 50 个线程就全卡在read上。剩下 150 个线程要服务所有正常请求，一旦这 150 个里再有几个耗时操作，整个服务就开始排队。更阴险的是这类问题在监控上不明显：CPU 不高、内存不高，只有请求延迟在缓慢爬升，或者干脆超时。

要缓解就得设超时。setsockopt设SO_RCVTIMEO、SO_SNDTIMEO，或者用select做带超时的等待——但一旦你开始用select做超时控制，其实已经在往多路复用那条路上滑了。我的经验是：阻塞IO可以用，但必须配三样东西——连接数硬上限、读写超时、独立的健康检查通道，否则一个慢客户端就能把你整条线程链拖垮。

2.2 非阻塞IO：轮询的代价比想象中大

把 fd 设成O_NONBLOCK之后，read没数据立刻返回EAGAIN，程序可以继续干别的。听起来很美好，但纯非阻塞IO几乎没法单独用，因为你要不断重试。一个事件循环里挂了 1000 个 fd，你轮一遍就是 1000 次系统调用，大部分返回EAGAIN，纯属白跑。系统调用本身要陷入内核、保存上下文，这个开销在量大的时候非常可观。

所以非阻塞IO在工程里的真实角色是多路复用的必要配件，而不是独立方案。epoll 的 ET 模式强制要求 fd 非阻塞，因为 ET 只在状态变化时通知一次，你必须循环读到EAGAIN为止才能保证数据读干净，而循环读的前提就是非阻塞——否则最后一次读会把线程永久挂住。很多人写 ET 模式出问题，根子就在这儿：fd 忘了设非阻塞，或者循环读的时候没处理EAGAIN的退出条件。

顺带提一个容易忽略的点：accept在 ET 模式下也必须循环调用，因为可能同时有多个连接到达，只accept一次会漏掉后面的，那些连接就一直躺在全连接队列里没人管，表现是客户端连上了但发数据没反应。这个坑我踩过一次，排查了大半天。

2.3 IO多路复用：select、poll、epoll 的演进不是简单堆功能

select的问题大家都知道：fd 集合是位图，上限通常是 1024；每次调用都要把整个集合从用户态拷到内核态；返回后还要线性扫描一遍找出哪些 fd 就绪，复杂度 O(n)。连接数上千之后，光是这些拷贝和扫描就吃掉大量 CPU。

poll用数组替代位图，突破了 1024 的限制，但拷贝和线性扫描这两件事没变，本质还是 O(n)。所以 poll 更像是一次“参数接口的改良”，不是架构升级。

epoll才动了真格。它把“注册关注的 fd”和“等待事件”拆成两个操作：epoll_ctl把 fd 挂到内核的一棵红黑树上，只在这一步做一次拷贝；内核给每个 fd 注册回调，数据就绪时回调把它挂进一个就绪链表；epoll_wait直接看这个链表有没有东西，有就返回，复杂度跟活跃连接数相关，跟总连接数无关。这个设计对“连接多但活跃的少”的场景是降维打击——比如 IM 长连接、推送服务，十万个连接里同时活跃的可能就几千个。

不过 epoll 也不是银弹。如果场景是活跃连接占比很高、每个连接都频繁收发，那 epoll 的优势会被摊薄，因为它省下的是“遍历不活跃连接”的成本。另外 epoll 是 Linux 特有的，跨平台要考虑 kqueue（BSD/macOS）、IOCP（Windows），这也是为什么很多跨平台框架会再包一层事件抽象。选型时先看部署环境，别写完才发现目标平台没有对应实现。

2.4 信号驱动IO与异步IO：概念清晰，落地场景有限

信号驱动IO的流程是：给 socket 设O_ASYNC标志、绑定属主进程、注册SIGIO处理函数，之后就可以去干别的，数据到达时内核发信号。听起来优雅，实际问题不少：信号是进程级的，多个 fd 同时就绪时你很难知道是哪个；信号处理函数里能安全调用的函数有限，稍微复杂点的逻辑就得挪到别处；高并发下信号风暴本身就是负担。所以它在实际项目里出现频率很低，更多是作为知识体系的一环存在。

异步IO（POSIX 的aio系列）语义最干净：提交一个读请求，内核把数据搬完再通知你，应用全程不阻塞。但 Linux 原生 AIO 在socket 上的支持长期不完整，实际可用性一般；后来出现的io_uring才算把这个方向真正做起来了，用一对共享内存环形队列做提交和完成，减少了系统调用次数。不过io_uring对内核版本有要求，生态和调试工具链还在成熟过程中，除非你做的是存储、数据库这类对 IO 路径极度敏感的组件，否则不建议在新项目里一上来就用。

我的建议很朴素：业务服务端老老实实用 epoll 多路复用，这是投入产出比最高的选择；等哪天你的瓶颈真的卡在系统调用次数上了，再去评估 io_uring。

3. epoll 实战：从三个系统调用到一份能跑的服务端

3.1 epoll 三件套的最小用法

epoll的接口就三个：epoll_create1建一个 epoll 实例，返回一个 fd；epoll_ctl往里加、改、删关注的 fd 和事件类型；epoll_wait阻塞等待，返回就绪的事件数组。三个调用分工明确，理解了这一点，代码结构自然就出来了。

有个细节值得说：epoll_create1(0)和epoll_create(size)的区别在于后者那个 size 参数现在已经被忽略，但为了兼容老代码还留着，新代码用epoll_create1并传EPOLL_CLOEXEC更稳妥，避免 fork 之后子进程继承这个 fd 导致资源泄漏。

事件类型里最常用的几个：EPOLLIN可读、EPOLLOUT可写、EPOLLERR出错、EPOLLHUP挂断、EPOLLRDHUP对端关闭写端（需要定义_GNU_SOURCE）。还有个EPOLLET表示边缘触发，不加就是水平触发。EPOLLONESHOT用于多线程场景，保证一个 fd 同一时刻只被一个线程处理，处理完要重新epoll_ctl注册，否则再也不会被触发。

3.2 LT 与 ET：一句话说清区别，但坑在细节里

水平触发（LT）的语义是：只要缓冲区里还有数据，epoll_wait就会一直通知你。边缘触发（ET）的语义是：只在状态发生变化的那一刻通知一次，从“没数据”变成“有数据”通知，从“不可写”变成“可写”通知。

LT 写起来省心，你可以只读一部分就返回，下次还会被通知；ET 效率略高（通知次数少），但要求你必须一次把数据读干净。这两者的取舍不是性能问题，而是代码复杂度问题。我一般的建议是：先用 LT 把功能跑通，确认瓶颈确实在事件通知次数上，再考虑换 ET。很多项目的连接数根本没到需要 ET 的程度，盲目上 ET 只是给自己加调试成本。

ET 模式下有三条铁律。第一，fd 必须是非阻塞的，否则循环读到最后一次会阻塞住。第二，读操作要循环到返回EAGAIN或EWOULDBLOCK为止。第三，accept也要循环到EAGAIN。违反任何一条，症状都是“偶发卡死”或“连接上但没反应”，而且极难复现，因为它依赖时序。

3.3 一份可以直接编译运行的最小服务端

下面这段代码我刻意写得很朴素，没有连接管理、没有缓冲区抽象，就是把 epoll 的主干拎出来，方便你对着改。它做的事情是：监听端口，接受连接，把收到的数据原样回写，然后关闭。

#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include <arpa/inet.h> #include <sys/socket.h> #include <sys/epoll.h> #define PORT 9000 #define MAX_EVENTS 1024 #define BUF_SIZE 4096 static int set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); if (flags == -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main(void) { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); exit(1); } int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); 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(PORT); if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); exit(1); } if (listen(listen_fd, 512) < 0) { perror("listen"); exit(1); } set_nonblocking(listen_fd); int epfd = epoll_create1(EPOLL_CLOEXEC); if (epfd < 0) { perror("epoll_create1"); exit(1); } struct epoll_event ev, events[MAX_EVENTS]; ev.events = EPOLLIN | EPOLLET; /* 想先跑通可以去掉 EPOLLET */ ev.data.fd = listen_fd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) { perror("epoll_ctl add listen"); exit(1); } char buf[BUF_SIZE]; for (;;) { 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) { /* ET 下必须循环 accept 到 EAGAIN */ for (;;) { struct sockaddr_in cli; socklen_t len = sizeof(cli); int cfd = accept(listen_fd, (struct sockaddr *)&cli, &len); if (cfd < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) break; perror("accept"); break; } set_nonblocking(cfd); ev.events = EPOLLIN | EPOLLET | EPOLLRDHUP; ev.data.fd = cfd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &ev) < 0) { perror("epoll_ctl add client"); close(cfd); } } } else { /* ET 下必须循环读到 EAGAIN */ for (;;) { ssize_t r = read(fd, buf, sizeof(buf)); if (r > 0) { ssize_t off = 0; while (off < r) { ssize_t w = write(fd, buf + off, r - off); if (w > 0) { off += w; continue; } if (w < 0 && (errno == EAGAIN || errno == EINTR)) continue; goto close_conn; } } else if (r == 0) { goto close_conn; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) break; if (errno == EINTR) continue; goto close_conn; } } } continue; close_conn: epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } } close(epfd); close(listen_fd); return 0; }

编译命令：

gcc -O2 -Wall -o epoll_echo epoll_echo.c

测试就用nc或者telnet连上去敲字，能原样回显就说明通了。这段代码里有几个地方值得停下来看一眼：SO_REUSEADDR是为了避免重启时被TIME_WAIT卡住；EPOLLRDHUP让我们能在对端关闭写端时收到通知，比等到read返回 0 更早；write那段循环处理了部分写的情况，虽然示例里缓冲区很小基本不会触发，但真实场景必须处理，否则数据会被截断。

注意：write返回EAGAIN说明发送缓冲区满了，正确做法是把剩余数据存进应用层写缓冲区，注册EPOLLOUT事件，等可写时再继续。上面示例里为了简洁用的continue反复重试，在高负载下会空转烧 CPU，正式代码里不要这么写。

3.4 几个关键参数怎么估：backlog、fd 上限、maxevents

listen的 backlog 参数不等于实际队列长度，内核会取它和net.core.somaxconn的较小值。想看当前值用sysctl net.core.somaxconn，很多发行版默认是 4096，老一些的是 128。如果你的服务要承接瞬时连接洪峰，这个值建议调到 4096 以上，同时net.ipv4.tcp_max_syn_backlog也一起看，半连接队列太小会在 SYN 洪峰时丢包。

fd 上限用ulimit -n看，默认常见是 1024。一个连接占一个 fd，加上日志文件、epoll 实例、监听 socket，实际能撑的连接数大概是上限的 90%。十万连接就得把nofile调到 12 万以上，同时检查/proc/sys/fs/file-max。这里有个坑：ulimit -n是进程级限制，改完要重启进程或者用 systemd 的LimitNOFILE配置，光在 shell 里改对已有进程无效。

epoll_wait的maxevents决定一次最多返回多少个事件。设太小会多跑几轮循环，设太大会多占栈内存。我一般按“预期同时活跃连接数 / 4”来估，再夹在 512 到 4096 之间。比如预期活跃连接 8000，那就设 2048。这个值不是性能关键，但设成 1 会非常难看。

4. Reactor 与 Proactor：把 IO 模型组织成能维护的架构

4.1 从一个循环到一个可扩展的线程模型

光有 epoll 只是有了“等待事件”的能力，怎么组织代码处理这些事件，就是 Reactor 模式要解决的问题。最朴素的单 Reactor 单线程就是：一个循环里epoll_wait，读到事件就当场处理完。这个模型在连接数不多、每个请求处理又快的时候完全够用，代码也最好懂。

问题出在业务处理变重的时候。假设你在这个循环里做了数据库查询或者磁盘读写，整个事件循环就被卡住了，所有连接都得等。这时候自然会想到把处理逻辑扔到线程池：Reactor 线程只负责收发和编解码，业务逻辑交给 worker 线程。这就是单 Reactor 多线程模型。

再往上走，连接数到了几十万，单个 Reactor 线程光是处理 IO 事件就忙不过来了，于是拆成主从 Reactor：主 Reactor 只负责accept新连接，把新连接分给若干个从 Reactor，每个从 Reactor 有自己的 epoll 实例和事件循环，各自管一批连接。很多高性能网络框架都是这个路子，区别只在从 Reactor 的数量和分配策略。

分配策略这块有个细节：如果按连接轮询分配，容易出现某个从 Reactor 上恰好挂了几个特别活跃的连接，负载不均。有些框架会按从 Reactor 当前的连接数或者事件处理量做动态分配，实现复杂度会上去一些。我的经验是先做静态轮询，等监控上确实看到不均衡再优化，别一上来就搞复杂调度。

4.2 大部分框架选 Reactor 不是因为它先进

Proactor 的语义更漂亮：发起异步读，内核把数据读完放进用户缓冲区，再通知你处理。应用层完全不用关心“数据什么时候到”，只处理“数据已经到了”这件事。理论上的效率也确实更高，因为省掉了“通知就绪 + 应用自己读”这一来一回。

但落地时有两个现实问题。一是操作系统支持，前面说过 Linux 上真正的异步 IO 生态还不够成熟，跨平台就更麻烦。二是编程模型，Proactor 的回调是在数据已经就绪的前提下触发的，但你依然要管理缓冲区的生命周期、处理回调嵌套、保证不阻塞，调试难度比 Reactor 高。

所以绝大多数服务端框架选择 Reactor，本质是一个工程折中：用一点点理论上的效率损失，换一个更成熟、更好调试、跨平台一致的模型。理解了这一点，你就不会纠结“为什么不用异步IO”这种问题了——不是不知道，是划不来。

4.3 线程模型和 IO 模型必须配套，混搭会出事

我见过最常见的错误是：底层用了 epoll，上层却用阻塞的方式处理业务。比如在事件回调里同步调用一个可能超时的下游接口，整个事件循环就停在那了。表现出来就是所有连接一起变慢，监控上看不出哪个环节有问题，因为 CPU 是空闲的，线程都卡在等下游返回。

正确的做法是把“可能阻塞的事”全部隔离出去：IO 事件回调里只做编解码和状态机推进，真正的业务处理投递到有界线程池，线程池满了要有明确的拒绝策略而不是无限排队。这样一来，事件循环的响应时间就可控了，即使下游抖动，受影响的也只是线程池里的任务，不会波及连接管理本身。

还有一个容易忽略的点是单连接内的顺序性。如果你把一个连接的多个请求分发到不同线程，就要保证响应顺序和请求顺序一致，否则客户端会收到乱序响应。简单做法是同一个连接始终投递到同一个线程（按连接 fd 哈希），复杂一点的做法是给每个连接维护一个序列号，在写回时排序。

5. 常见问题与排查技巧实录

5.1 连接数上不去，先看这三层

第一层看上是不是 fd 耗尽了。ls /proc/<pid>/fd | wc -l数一下，跟ulimit -n比。如果接近上限，日志里通常会有Too many open files，但有些封装库会吞掉这个错误，只表现为accept失败。这时候用strace -f -e trace=accept,accept4 -p <pid>跟一下，能直接看到返回的 errno。

第二层看全连接队列有没有溢出。ss -lnt输出里的Send-Q那一列就是当前监听 socket 的 backlog 上限，如果Recv-Q长期接近Send-Q，说明队列满了，内核开始丢新连接。这时候要么调大 backlog，要么查为什么accept处理得慢——常见原因是事件循环里有阻塞操作。

第三层看是不是CLOSE_WAIT堆积。ss -ant | grep CLOSE_WAIT | wc -l，如果这个数字只涨不跌，说明你的代码没有正确关闭连接：对端发了 FIN，你没调close，连接就挂在那占着 fd。这个问题的根子往往在异常路径上，正常流程记得关，出错分支忘了关。

5.2 CPU 打满但 QPS 不涨，往这几个方向查

先区分是用户态高还是内核态高。top看us和sy的比例，sy高说明系统调用或中断开销大，可能是事件通知太频繁、或者 ET 写成了 LT 导致重复通知、或者write的EAGAIN重试在空转。

用perf top看一眼热点函数，如果看到大量epoll_wait或sys_read，基本能确认是事件循环太忙。如果看到业务函数占大头，那是业务逻辑的问题，跟 IO 模型无关。

还有一个隐蔽的原因：惊群。多个线程或者进程同时epoll_wait同一个 epoll 实例，事件到来时全部被唤醒但只有一个能处理，其余白跑一趟。较新的内核在accept上已经做了处理，但如果你的场景是自己 listen 多个线程共享，可以考虑用EPOLLEXCLUSIVE标志，或者干脆每个线程独立 epoll 实例配合SO_REUSEPORT。

5.3 ET 模式下的两个经典事故

事故一：数据读不干净。客户端发了一大段数据，你只读了一次 4096 字节就返回，因为 ET 只在状态变化时通知，缓冲区里剩下的数据不会再有新通知，这段数据就永远留在内核里，服务端状态机卡住。症状是请求偶尔“半截”，或者连接一直挂着不返回。

事故二：accept漏连接。前面提过，ET 模式下accept必须循环。漏掉的连接会躺在全连接队列里，客户端认为连上了，服务端却没有任何处理。用ss -lnt能看到Recv-Q一直大于 0，这就是信号。

这两个问题的共同点是难复现，因为它们依赖时序和缓冲区大小。压测时并发不够高、数据包不够大，可能一次都不触发。所以写 ET 代码时宁可啰嗦一点，把循环读和循环accept写成固定模板，别图省事。

5.4 问题速查表

6. 一些实测数据和选型上的个人体会

在一台 8 核 16G 的测试机上，我做过一组简单的对照：同样的回显服务，阻塞IO配 200 线程，连接数到 800 左右就开始有明显的延迟抖动，主要是线程切换和内存占用上来了；换 epoll 单线程之后，空闲连接挂到 5 万、活跃连接 1 万时，QPS 能稳定在 3 万上下，CPU 大概用到 60%。这个数字没什么普适性，因为业务逻辑复杂度、报文大小、网络环境都会影响，但它能说明一个趋势：多路复用带来的不是单连接更快，而是连接数上限的量级变化。

选型上我的判断顺序是这样的：先看并发连接数的预期峰值，几百以内直接阻塞IO配线程池，别折腾；几千到几万，上 epoll，先单 Reactor 单线程把功能跑通，再看要不要加线程池；十万以上，才需要考虑主从 Reactor、多队列、SO_REUSEPORT这些。跨平台需求优先的项目，可以看看各语言生态里成熟的事件驱动库，它们已经把 epoll/kqueue/IOCP 的差异抹平了，自己造轮子的收益很低。

还有一点值得反复强调：网络IO模型解决的是“等待”的效率问题，不是“处理”的效率问题。我见过太多服务把 epoll 用得很溜，结果瓶颈在数据库慢查询或者序列化上，改 IO 模型一点用没有。上模型之前先用压测把瓶颈定位清楚，如果 CPU 大部分花在业务函数上，那把 epoll 优化到极致也是白搭。反过来，如果你的监控上看到大量线程处于可中断睡眠状态、上下文切换次数很高，那基本可以确定是 IO 等待在拖后腿，这时候换模型才有意义。

最后分享一个我自己的调试习惯：遇到高并发下的诡异问题，先别急着改代码，用strace -c -p <pid>跑十秒钟，看系统调用的次数分布。如果epoll_wait调用次数远低于预期，说明事件循环被卡住了；如果read次数远高于数据量对应的次数，说明在读空；如果write返回EAGAIN特别多，说明发送侧没做背压。这三个信号基本能覆盖八成的 IO 层问题，比盯着日志猜要快得多。