五种IO模型与非阻塞IO：从阻塞故障到epoll实操

你有没有遇到过这样的情况：一台配置不算差的服务器，平时扛几千个请求都很轻松，但只要有一个响应极慢的客户端连上来，整个服务的吞吐就肉眼可见地往下掉，甚至其他正常请求也跟着排队。几年前我调一个内部网关的时候就被这个问题折磨了很久，最后追根溯源，问题出在服务端用了一整套阻塞式IO模型，而那个慢客户端把线程池里的线程几乎占满了。搞清楚这件事之后，我才真正把五种IO模型和非阻塞IO的底层逻辑理顺。

这篇文章不打算写成教材式的知识点罗列，而是想从一个实际故障出发，把IO模型的分类标准、非阻塞IO的实操细节、以及最容易踩的坑一次讲清楚。无论你刚接触网络编程，还是已经写了几年业务代码但一直对select、epoll、非阻塞这些概念似懂非懂，这篇文章都能帮你把散落的经验串成一条线。

1. 一次性能事故复盘：阻塞IO如何拖垮整个服务

先回到那个网关场景。服务端用的是最经典的阻塞式socket加线程池，每个连接分配一个线程。平时连接数不多，请求处理得又快，没什么感觉。但某天一个客户端的回调地址出了问题，TCP连接一直保持着，却再也不发数据了。这个连接占用的线程就阻塞在recv调用上，傻等。更麻烦的是，这个客户端还特别执着，每隔几秒会重连一次，于是一个慢客户端就慢慢耗掉了十几个线程。线程池一满，后面的正常请求只能排队等待，服务就"变卡了"。

1.1 阻塞IO的等待链路到底长在哪里

阻塞IO的核心行为，是一次系统调用要等数据真正"准备好"才返回。以一个TCP连接上的recv为例，它内部走的是recvfrom这个系统调用，大致有三道关卡：

1. 检查socket接收缓冲区里有没有数据，有就拷贝给用户态，调用返回。
2. 缓冲区空，把当前线程/进程挂起，进入睡眠状态。
3. 等内核收到网络包、写入缓冲区之后，再唤醒这个线程，数据拷回用户态，recv才返回。

注意第2步，线程睡下去之前，它手上线程池的位置就占着不放，不会去处理别的连接。如果你的服务逻辑是"一个线程只服务一个连接"，那这个线程的生命周期就完全被对端牵着走。对端不按套路出牌，你的线程就不干活还占着坑。

1.2 阻塞模型的隐性成本

阻塞IO最大的问题不是性能差，而是并发能力的开销大。每增加一个连接就要增加一个线程，而线程的创建、切换、销毁都是有成本的。一个8核16线程的机器，跑几百个线程还能应付，跑到几千个线程的时候，光是上下文切换就能吃掉大量CPU时间片。这就是业界常说的C10K问题：单机能不能支撑上万个并发连接？用阻塞IO加线程池的思路，到了一千个连接的时候就已经捉襟见肘了。

但阻塞IO也不是一无是处。如果连接数量少、每个请求处理时间短，它反而是最清晰、最不容易写错的方案。毕竟在阻塞模式下，代码是线性的：收数据、处理、返回，出错就是返回-1，逻辑非常直接。所以我的建议是，不要一上来就迷信非阻塞，而是要搞清楚你服务的真实连接模型，再决定用哪种IO方式。

那个网关的修复方案，就是把连接的处理从"一线程一连接"改成"事件驱动加非阻塞IO"。后面的内容，就是我在改造过程中对IO模型本身的完整梳理。

2. 五种IO模型不是五座孤岛：划分标准藏在数据流里

很多人把五种IO模型背得滚瓜烂熟，但问一句"它们到底按什么标准划分"，就答不上来了。其实标准没那么玄，就看数据从网络到用户态要经历的两个阶段里，你的程序分别在哪个阶段等待、怎么等待。

2.1 网络数据到达用户态的两个阶段

第一阶段是等待数据就绪。数据从网卡进来，经过内核协议栈处理，放入socket接收缓冲区，这个阶段用户态做不了任何事，只能等。第二阶段是将数据从内核缓冲区拷贝到用户态缓冲区。注意，这一步也是由系统调用执行的，比如recvfrom的返回值就是把数据拷出去之后才拿到的。

两个阶段加起来，就是一个完整的读操作。不同IO模型的差异，就在于这两个阶段分别怎么处理：

每次我讲这张表，都要强调一个容易混的点：阻塞和非阻塞，说的是第一阶段的表现；异步不同步，说的是第二阶段由谁来做。很多人以为非阻塞IO就是异步IO，其实完全两回事。非阻塞IO在真正拷贝数据的时候，线程还是要等在recvfrom调用上；只有异步IO才把拷贝这个动作也交给了内核。

2.2 五大模型的通俗类比

拿点外卖来类比，这五种模型的差别会非常直观。

• 阻塞IO：你站在取餐口死等，不拿到外卖不干别的。代码简单，但时间全耗在等待上。
• 非阻塞IO：你每隔几分钟去取餐口问一次"好了没"，没好就先回工位干活。但每次询问都要跑一趟，问的次数越多越浪费。
• IO复用：前台放了块牌子，外卖好了叫号，你坐在工位上等叫号，叫到了再去取。一个人可以同时等好几份外卖。
• 信号驱动IO：你留了手机号，外卖好了商家打电话通知你，你再过去取，取的过程还是要等。
• 异步IO：你点了外卖之后该干嘛干嘛，外卖送到之后有人直接摆到你桌上，你甚至不用自己去取餐口。

这里IO复用和信号驱动容易混淆，区别在于：IO复用是你主动去等一批fd的事件；信号驱动是内核主动通知你"有数据了"，你的程序通过信号处理函数去执行读取。信号驱动听起来很美好，但信号处理函数里做复杂操作很容易出问题，实际项目里用得很少，属于存在但存在感极低的一类。

2.3 非阻塞IO在五种模型里的承上启下位置

非阻塞IO单独拎出来，乍一看效率并不高——要反复用recv去问内核有没有数据，每次都是系统调用，空转成本不低。但它的真正价值不在"独自使用"，而在于它是IO复用模型的地基。

epoll这类多路复用器只是告诉你"某几个fd有数据了"，但它不会替你把数据读出来。你仍然需要自己调用read去拿数据，而这时的read如果还是阻塞式的，就会出大问题。最经典的场景：epoll_wait通知你某个fd可读，你去read，结果读了一部分之后内核缓冲区里暂时没数据了，如果是阻塞式read，线程就直接睡在里面，其他所有就绪的fd都没人管了。所以epoll之所以要配非阻塞fd，不是品味问题，而是架构上的必需品。读的时候返回EAGAIN，你就知道"这次的事件处理完了"，可以回到事件循环里等下一批事件。非阻塞IO，承担的是"事件循环模型里的收尾动作"这个角色。

3. 非阻塞IO的三个基本功：模式设置、错误处理、事件衔接

上面讲了理论，这一节进入实操。很多新手拿到一个非阻塞socket，第一反应是"为什么我的recv返回-1"，然后开始怀疑程序写错了。其实返回-1加上errno等于EAGAIN，才是非阻塞模式的正常作息。

3.1 把一个fd设置成非阻塞的三种方式

第一种是创建socket时直接用SOCK_NONBLOCK：

c复制int fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);

不过这个方式是Linux特有的。更通用、也更推荐的做法是用fcntl：

c复制int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

这段代码先取当前文件状态标志，再追加O_NONBLOCK，目的是不覆盖掉原有的标志位——直接赋值往往会丢掉O_APPEND之类别的属性。

第三种是专门给accept用的accept4：

c复制int cfd = accept4(lfd, (struct sockaddr*)&addr, &len, SOCK_NONBLOCK);

accept4能在接受新连接的同时直接把它设置成非阻塞，省一次fcntl调用。在需要频繁accept的高并发放场景下，少一次系统调用就是少一次开销。

另外有个容易误解的点：对普通文件打开时加O_NONBLOCK，基本没用。本地文件的read不会因为数据没准备好而返回EAGAIN，这个标志主要影响的是FIFO、设备文件和socket这类"数据会迟到"的对象。

3.2 read的非阻塞范式：EAGAIN不是错误

非阻塞模式下，read的返回结果不只有"正数或0"，还有"负数加上特定errno"。处理逻辑应该稳定成下面这种模板：

c复制ssize_t n;
while (1) {
    n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        // 处理正常数据
        handle_data(buf, n);
    } else if (n == 0) {
        // 对端关闭连接
        close(fd);
        break;
    } else {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            // 本次内核缓冲区已读空，退出事件循环
            break;
        } else if (errno == EINTR) {
            // 被信号打断，重新调用
            continue;
        } else {
            // 真正的错误
            handle_error(fd, errno);
            break;
        }
    }
}

这里值得多说两句EINTR。阻塞模式下，如果线程在read睡眠中被信号唤醒，也会返回EINTR。很多代码图省事，遇到非EAGAIN的错误就直接关socket，其实应该区分开，尤其是接手了老项目，信号处理逻辑复杂的时候，忽略EINTR会导致连接被莫名关闭，还特别难排查。

n == 0的情况也有个隐藏细节。如果对端发送数据后立刻关闭连接，你的第一次read很可能返回的是数据长度，第二次才返回0，而不是一次read就把数据和FIN一块打包带回来。所以不能在第一次读到数据时就假设连接一定开着，要等下一次read返回0才算真正结束。

3.3 非阻塞fd如何与epoll正确衔接

有了非阻塞fd，搭配epoll的标准流程是：

1. 把服务端监听socket设为非阻塞。
2. accept4返回的每个连接fd也设为非阻塞。
3. 将连接fd注册进epoll，监听EPOLLIN事件。
4. epoll_wait返回就绪列表后，逐个对就绪fd执行非阻塞read，读到EAGAIN说明这次处理完了。
5. 如果某个fd在处理过程中出错或对端关闭，从epoll树中移除并关闭。

这里有个水平触发（LT）和边缘触发（ET）的差异要特别说明。LT模式下，只要内核缓冲区还有数据，epoll_wait就会反复通知你；ET模式下，只有状态发生变化（比如新数据到来）才通知一次。ET模式下，你必须在一个事件里循环read直到返回EAGAIN，否则缓冲区剩的那点数据就永远等不到下一次通知了。很多线上故障，比如"偶发性地丢数据""请求响应慢一截"，排查到最后都是ET模式少了一次循环read。

所以我的习惯是：默认用LT，代码简单容错高；只有对性能有明确要求、且对每个环节都足够熟悉的时候才上ET，而且要配完整的循环读取逻辑。

4. 非阻塞编程最容易踩的四个坑：write、connect、accept、read

第三节讲的read，只是非阻塞编程的入门。真正让老手也翻车的，集中在write、connect、accept这几个操作上，每一个都和阻塞模式下的习惯思维有冲突。

4.1 非阻塞write：返回正数不意味着发送完了

阻塞模式下，write要么返回完整长度，要么返回错误，不存在"写一半"的情况（除非进程被信号打断）。非阻塞模式下，这个铁律被打破了：当socket发送缓冲区空间不足时，write能写多少就写多少，返回值可能小于你要发送的长度，对应代码就是部分写入。

来看这个典型处理：

c复制ssize_t n = write(fd, data, len);
if (n > 0 && n < len) {
    // 部分写入，剩余部分必须缓存，等EPOLLOUT事件再发
    append_to_send_queue(fd, data + n, len - n);
} else if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
    // 缓冲区完全满了，整个包先进发送队列
    append_to_send_queue(fd, data, len);
}

append_to_send_queue这一步很关键。在事件循环模型里，你要保证"每个fd最多只有一个写事件在等"：把待发送数据挂到fd对应的队列里，然后把这个fd的EPOLLOUT事件注册进去。等epoll_wait通知可写时，再回头从队列里取数据补发。补发完之后，如果队列清空了，记得把EPOLLOUT从监听列表里去掉，否则它会一直触发，白白消耗CPU。

不光是数据发送，幂等性也得考虑。如果一次回调里没把队列发完，下次EPOLLOUT再触发时，要从上次断掉的位置继续，而不能从头再发一遍。这个"断点续传"逻辑写错，就会造成数据重复，而且是那种只在高压下出现的偶发bug，调试起来能逼疯人。

4.2 非阻塞connect：EINPROGRESS才是正常返回

大部分新手第一次用非阻塞connect，都会被返回的-1和EINPROGRESS吓到。其实这是告诉你：连接正在建立中，你去做别的事吧，建立完成之后内核会通知你。

完整的非阻塞connect套路是这样：

1. socket设为非阻塞。
2. 调用connect。如果返回0，说明立即完成（回环地址经常这样）；如果返回-1但errno == EINPROGRESS，进入第3步；其它错误则直接失败。
3. 把fd注册进epoll，监听EPOLLOUT。
4. EPOLLOUT触发后，调用getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len)，传入SO_ERROR选项，取出内部保存的错误码。err为0，连接成功；否则就是连接失败，常见的是ECONNREFUSED。

这里尤其要强调的是第4步：可写事件不等于连接成功。如果对端主动拒绝连接，内核一样会让fd可写，不走getsockopt检查这一层，程序会误以为连接建立了，然后去发数据，然后收到一个无意义的EPIPE。老代码里这种错误太多了，几乎成了非阻塞connect的"标准翻车点"。

4.3 accept的空转问题：监听socket要不要非阻塞

很多人把监听socket设成阻塞，然后只在处理连接fd时用非阻塞，结果在单线程事件循环里照样翻车。原因是：epoll_wait通知"有新连接"，你调accept去接，如果在accept返回的瞬间，那个连接恰恰已经被对端断开（RST），阻塞模式的accept不会立刻返回，它可能会在那里等下一个新连接，整个事件循环就卡住了。

所以服务端的监听socket也建议设成非阻塞。accept返回EAGAIN时，说明当前所有待处理连接都已经接完了，直接退回到epoll_wait即可。特别注意ET模式下，必须循环accept直到EAGAIN，否则可能漏掉连接，让客户端发送的数据一直躺在内核缓冲区里无人处理。

有些实现为了图省事，会直接用accept4接收新连接并同时设非阻塞，相当于把"accept + fcntl"两步合并成一步，还能避免上述卡死问题，这是我认为最值得养成的习惯。

4.4 内核缓冲区耗尽时会发生什么

这块属于进阶认知。非阻塞模式下，write只往内核发送缓冲区塞数据，塞不进去就返回EAGAIN。如果对端一直不读，发送缓冲区会被写满，此时你的应用层发送队列就会不断堆积。阻塞模式下，这个堆积发生在内核buffer和用户线程睡眠之间，你的内存占用也许可控，但线程被挂起会直接拖垮线程池。

所以高吞吐服务里，一定要给每个连接的发送队列设一个上限。超过上限，要么直接断开这个"慢客户端"，要么对它进行限速。否则一个客户端拖垮整个服务的事件，就会从"线程耗尽"变成"内存耗尽"，换汤不换药。

5. 结合业务选型：阻塞、非阻塞、异步分别用在哪儿

理论讲完，坑也列完了，最后聊聊实战中最重要的问题：一个具体的服务到底该选哪种模型？我见过不少人把非阻塞和epoll当成银弹，结果写出来的代码比阻塞版复杂好几倍，性能还没提高多少。选型的关键，是先回答两个问题：你的连接数有多大，每个连接平均活跃时长是长是短。

5.1 不同模型对应的代表作

以我熟悉的开源项目为例，能更直观地感受每种模型适合什么场景。

• Nginx采用的是epoll多路复用加非阻塞fd的事件驱动模型，适合海量并发连接，尤其是大量长连接、低活跃度的场景。它最鲜明的特点是一个worker进程能同时管理数万个连接。
• Redis也走事件驱动路线，但它单线程加非阻塞IO，之所以能撑住高并发，是因为它的操作都在内存里完成，处理速度极快，事件循环几乎没有"空转等IO"的空隙。
• 传统多线程阻塞服务则适合连接数少、每个连接持续交互、或者请求任务本身消耗CPU时间比较多的场景。比如内部管理后台、设备网关这种并发量级在几百以内的系统，阻塞模型反而好维护。

我做过一次粗略的对比测试：同一个网关服务，连接数在50以内时，阻塞模型和非阻塞模型的吞吐差异几乎可以忽略；但连接数到了2000，阻塞模型的CPU上下文切换开销就被明显放大了，非阻塞模型的CPU占用反而更稳定。

5.2 我自己的三个选型判断逻辑

第一，连接数和线程池上限的关系是硬指标。如果最大并发连接数可能超过线程池处理能力的5到10倍，就别硬扛阻塞模型了。第二，请求是否天然并行。如果每个请求里都有一大段等外部接口返回的操作，那IO等待和CPU计算可以重叠，用一个较小的线程池配合非阻塞IO会划算得多。第三，团队能否驾驭复杂度。非阻塞模型的代码隐式状态多，调试链路长，如果团队谁都说不清EPOLLOUT什么时候触发，上线后就是定时炸弹。

code复制| 业务特征 | 推荐模型 | 背后的理由 |
| --- | --- | --- |
| 连接少（<100）、走短请求 | 阻塞IO + 线程池 | 代码简单，逻辑清晰，没有隐藏状态 |
| 连接多（>1000）、长连接多 | epoll + 非阻塞fd | 单线程管理大批fd，线程数与连接数解耦 |
| 连接多且单连接吞吐高 | 非阻塞fd + 多线程/多进程 + 发送队列上限 | 既扩大并发管理，又利用多核 |
| 追求极限IO（大文件、高吞吐） | io_uring等异步IO | 把内核拷贝阶段的等待也去掉 |

5.3 异步IO对现有模型的影响

最后说一句异步IO。io_uring是Linux 5.1以后提供的异步IO接口，配合liburing使用，它把"等待数据就绪"和"数据拷贝到用户态"两个阶段都下沉给了内核，用户态提交请求后完全不需要再等。它的性能上限比epoll这套方案更高，尤其适合大文件读写和RocksDB这类存储引擎场景。但要注意，它目前主要服务于磁盘IO和网络IO的高性能场景，使用复杂度也不低，普通业务选型还不必急着迁移。换句话说，五种IO模型中最理想的那种——异步IO——已经不只是教科书上的概念了，它正在进入工程实践。理解好它和非阻塞IO的关系，以后切io_uring的时候会轻松得多。

在实际操作中我还有一个小习惯，可以分享给你：在设置完非阻塞标志或者注册epoll事件时，随手打一行调试日志，把fd、期望事件、当前状态打出来。看起来微不足道，但排查类似"EPOLLOUT不触发""缓冲区满导致连接挂起"这类问题的时候，这行日志能直接帮你定位到是事件没注册成功，还是数据没发完。网络编程的坑大多不在语法上，而在你对每一个返回值的理解有多深。非阻塞IO尤其如此，把上面几个细节吃透，大部分线上诡异问题都和你无缘了。