1. IO模型到底是什么先分清这几个基础概念Unix/Linux下的IO很多人一看到就说异步、同步、阻塞、非阻塞四个词但真到了写代码或者排查性能问题的时候就发现完全对不上号。我自己带过不少刚入门的同学最典型的状态是背概念时头头是道一问他select和epoll的差别本质在哪或者为什么Nginx能扛住十万并发而Apache不行立刻卡壳。先说清楚一个最基本的模型。一次完整的网络IO在操作系统层面其实分成了两个阶段第一阶段等待数据准备完成也就是数据从网卡/磁盘到内核缓冲区。第二阶段把数据从内核缓冲区拷贝到用户态缓冲区。我们写的代码能直接使用的是用户态这块内存。这两个阶段里各个模型的差异全部体现在怎么等以及谁来拷上。五个经典的IO模型就是围绕这两个阶段做的不同处理策略阻塞式IO、非阻塞式IO、IO多路复用、信号驱动IO、异步IO。我在实际开发里最常遇到的情况是业务同学写完网络框架吞吐上不去一查发现要么是线程模型不匹配要么是IO模型选错了。比如一个在线聊天系统用户量上万如果每个连接一个线程走阻塞式IO你用多少内存都不够。反过来如果一个超低并发的管理后台非要用异步IO 事件驱动复杂度上去了收益微乎其微。这中间的权衡就是我写这篇文章想跟你聊清楚的核心。这篇内容除了讲五个模型的原理还会把非阻塞IO单独拎出来把它和阻塞IO、多路复用放在一起做对比最后给出实际场景里的选型建议。适合刚接触网络编程的开发者也适合已经写了几年业务代码但一直没有系统梳理过IO模型的同学。2. 逐个拆解五种IO模型的行为差异2.1 阻塞式IO最直观但最浪费资源的模型阻塞式IO是教科书默认模型。进程发起recvfrom调用之后如果内核缓冲区里没有数据进程直接进入睡眠状态直到数据到达并且被拷贝到用户态缓冲区调用才返回。整个过程里这个线程什么事情都干不了完全被这个IO操作独占。从资源角度看这种方式最省CPU因为线程睡着的时候不占CPU。但从业务并发角度看代价非常明显一个连接就要占用一个线程而线程本身的栈空间、调度开销都是实打实的成本。默认线程栈通常是8MB左右即使只开了几百个线程虚拟内存的开销就非常可观。用生活场景来类比阻塞式IO就像你去餐厅吃饭一个人坐在位置上干等服务员端菜上来等菜期间你什么都干不了电话不能打文件不能看。一对一服务时这没问题但如果同时来了几百个客人就得雇几百个服务员每个服务员只管一个客人这成本没有人扛得住。阻塞式IO适合的场景其实不多。早期Java的BIOBlocking IO就是这种模式在连接数很少、每个连接都要长期占用的时候它反而简单可靠。比如内网里的数据库客户端连接连接池保持少量长连接每个连接由独立线程处理这种场景下阻塞式IO完全够用代码清晰也容易调试。但一旦连接数上千阻塞式IO的线程模型立刻成为瓶颈。线程切换的开销、内存栈的消耗、上下文切换时CPU缓存失效这些问题会一起爆发。这也是为什么后来有了线程池优化但线程池只能限制线程数量并没有解决一个线程处理一个连接的本质限制。2.2 非阻塞式IO轮询带来的转机与陷阱非阻塞式IO和阻塞式IO最大的区别在于当内核缓冲区没有数据时recvfrom调用不会让进程睡眠而是立刻返回一个EWOULDBLOCK或者EAGAIN错误。这个返回值的意思是现在没有数据你等会儿再来问。由于调用不阻塞了我们就可以用一个线程去管理多个连接用循环轮询的方式反复调用recvfrom检查每个连接是否有数据。这就是传说中的轮询也就是很多教程里说的busy-loop。这种方式确实让一个线程能服务多个连接代价是CPU一直都在空转因为大部分轮询是没有数据到达的。回到餐厅的例子非阻塞式IO相当于你把菜单放桌上每隔几秒就去问一次服务员菜好了吗。心眼是好的能同时盯好几桌但是你得一直来回跑大部分时候得到的答案是还没好。你确实没干等但你也没干正事CPU全消耗在反复询问上了。实际编码中非阻塞IO有非常典型的陷阱。一个是我之前带人写客户端程序时经常看到的忘记处理EAGAIN错误把正常情况当成异常去处理日志里疯狂报错。另一个问题是窗口大小和发送缓冲区的处理非阻塞发送时如果对方接收缓慢write调用也可能返回部分写入甚至同样返回EAGAIN你需要自己维护发送队列稍不注意就会丢数据。非阻塞IO单独使用的价值其实有限但它作为IO多路复用的基础价值非常大。select、poll、epoll这些多路复用机制本质上就是把检查多个连接有没有数据这件事交给了内核让内核帮我们从轮询中解脱出来。而epoll内部对于未就绪的文件描述符采用的就是非阻塞模式这个结合才是真正的黄金组合。2.3 IO多路复用一个线程盯住成千上万个连接IO多路复用的核心思路是把多个连接的等待操作统一交给内核去监听内核同时盯着这些连接一旦某个连接有数据到达内核就通知应用程序去处理。实现方式上select和poll都是每次调用时把完整的文件描述符集合传给内核内核线性扫描这些描述符检查哪些已经就绪。这个过程有一个明确的性能特征文件描述符越多扫描时间越长而且不管有没有事件发生整个描述符集合都要完整拷贝一遍效率会随着连接数增长线性下降。epoll则完全不同。它通过在内核里维护一个事件表应用程序只需要把感兴趣的描述符注册一次后续等待时无须重复传递。当某个描述符就绪时内核会把它放到一个就绪列表里应用程序只需要处理就绪的那一小撮描述符即可。这就是epoll在高并发下远胜select/poll的根本原因。用生活场景来理解select/poll就像是你在自习室门口等同学每次都要报一遍所有同学的名字管理员帮你进去挨个看谁出来了人越多查得越慢。epoll则是你在管理员那里登记只要张三、李四、王五出来就通知我然后你安心看书有人出来时管理员主动喊你你只处理喊到的那些人。IO多路复用虽然解决了一个线程盯着海量连接的难题但它本身依然是同步IO。因为通知你有数据可读之后真正执行read操作时如果数据没有准备好你依然可能被阻塞。所以使用多路复用时每个被管理的socket都必须设置成非阻塞模式配合使用才是正确的姿势。我在实际开发中常用的组合是这样的用epoll监听服务端socket和所有客户端socket的可读/可写事件每个socket注册时设置为非阻塞事件循环里只处理就绪的socket读取数据、解析协议、响应业务这套组合是所有主流高并发网络框架的地基。Redis的单线程事件循环、Nginx的worker进程事件模型底层都是这个思路。2.4 信号驱动IO把主动询问变成被动通知信号驱动IO在五个模型里存在感比较低但在特定场景下非常有用。它的做法是进程先跟内核说好某个socket有数据可读的时候发一个SIGIO信号给我。然后进程可以继续做自己的事等信号来了再回头处理数据。这个被通知的过程比非阻塞IO的轮询高效得多因为它不需要反复检查数据就绪时内核主动来找你。但信号驱动IO有个先天不足要处理信号、要在信号处理器里做逻辑、而且像UDP这种协议下还行TCP下的信号驱动因为连接状态复杂实际用起来远没有理论那么美好。简单类比一下信号驱动IO相当于你在餐厅点了菜然后扫了桌上的二维码菜好了手机会推送消息给你。对比非阻塞IO那种每次跑去问的服务方式体验上确实是升级。但信号机制容易受到系统各种条件影响信号也可能被其他信号打断处理起来很麻烦。信号驱动IO实际在工程里用得少一方面是因为信号处理的事件模型不够统一另一方面是它和epoll这类多路复用相比没有明显优势。不过这个概念是理解异步IO的好铺垫因为异步IO也遵循内核主动通知的思路只是通知的粒度更彻底。2.5 异步IO数据准备好了连同拷贝一起做完异步IO和前四个模型的本质区别体现在数据拷贝阶段。前四个模型里即使数据到达内核缓冲区从内核到用户态缓冲区的拷贝操作依然需要应用程序发起read/recvfrom调用来完成这个过程是同步的。异步IO则不同应用发起aio_read之后内核负责等待数据到达并且主动把数据从内核缓冲区拷贝到用户缓冲区拷贝完成后才通知应用程序。这时候应用收到通知时数据已经在用户态缓冲区里躺着可以直接用不需要再发起一次read调用。这在餐厅比喻里相当于你不仅不需要等菜连菜端上桌这个过程都由服务员包办了你只需要接到菜已上齐的通知直接开吃就行。理论上异步IO是性能上限最高的模型因为进程在等待数据和拷贝的过程中完全不会被阻塞。但现实是Linux下异步IO的支持长期以来都不够完善。早期Linux的AIOAsync IO主要针对磁盘IO在文件描述符上的支持度有限。后来io_uring的出现算是把Linux异步IO补了一大块但它对编程模型的要求更高使用门槛也明显高于epoll。Windows平台上的IOCP是另外一个异步IO实现它的完成端口模型在Windows生态里使用很广泛很多高性能网络服务在Windows上都会选择IOCP。跨平台做网络框架时这块的差异需要额外注意。对于大部分应用场景来说epoll同步非阻塞这套组合已经是够用且优秀的状态异步IO多用于极端性能和特殊场景。在不理解透彻的情况下盲目追新往往会把复杂度引入业务代码里得不偿失。3. 非阻塞IO单独拿出来深究到底怎么用才对3.1 非阻塞IO和阻塞IO的切换方式在Linux下把一个socket设置成非阻塞模式有两种常用方式。一种是socket创建时传入SOCK_NONBLOCK标志另一种是创建后用fcntl系统调用设置O_NONBLOCK标志。int fd socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);这种创建时直接指定非阻塞的方式最简洁。如果用fcntl代码如下int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);对于已经创建好的socket比如accept调用返回的客户端连接fd通常需要用fcntl来设置。因为accept新返回的fd默认继承监听socket的阻塞属性服务端一般会把监听socket设成非阻塞所以accept返回的客户端fd自然也是非阻塞的。这里有一个比较容易踩的坑如果监听socket是阻塞的accept在无新连接时会让整个进程卡住这种问题在普通开发中很常见。3.2 非阻塞模式下的read和write行为差异非阻塞模式下读取数据的正确姿势是循环读取直到read返回0表示对端关闭或者返回-1且errno为EAGAIN/EWOULDBLOCK表示本次数据已经读完。这里有一个重要的点非阻塞模式下read只要读到一点数据就会立刻返回而不是像阻塞模式那样等满你要的长度。如果我们的业务协议要求读取完整的数据包就必须自己维护缓冲区把每次read到的数据拼接起来然后依据协议头判断是否收够一个完整包。while (1) { ssize_t n read(fd, buf offset, sizeof(buf) - offset); if (n 0) { offset n; // 在这里判断是否已经收齐一个完整协议包 if (is_packet_complete(buf, offset)) { process_packet(buf, offset); offset 0; } } else if (n -1 (errno EAGAIN || errno EWOULDBLOCK)) { break; // 当前没有更多数据可读跳出循环等待下一次事件通知 } else if (n 0) { // 对端关闭连接 close(fd); break; } else { // 其他错误 handle_error(errno); break; } }写数据的时候非阻塞模式更要小心。因为TCP发送缓冲区可能已满write可能只写入一部分数据就返回甚至直接返回EAGAIN。如果此时简单地把剩余数据丢弃就会出现数据丢失。正确做法是维护一个应用层发送队列写入遇到EAGAIN时把剩余数据放入发送队列等下一次可写事件触发时继续发送。服务端的发送队列如果一直积压通常意味着客户端消费速度太慢。这种情况下可以考虑关闭连接或者走慢客户端保护逻辑而不是无限缓存下去。3.3 非阻塞IO的正确搭档多路复用事件循环单独使用非阻塞IO时我们需要自己去循环每个socket反复调用read查看是否有数据。这样CPU空转率高代码还非常难看。把非阻塞IO和多路复用结合起来是实践中百试不爽的配套方案。基本流程是这样的创建监听socket设置为非阻塞调用epoll_create创建epoll实例将监听socket注册到epoll监听EPOLLIN事件可读事件进入事件循环调用epoll_wait阻塞等待事件epoll_wait返回后遍历就绪列表如果是监听socket可读调用accept获取新连接把新连接设为非阻塞并注册到epoll如果是普通socket可读执行上面说的循环读取逻辑如果是可写事件处理发送队列中的剩余数据循环往复这套流程写出来其实并不长但每一环节都有讲究。比如accept之后的新连接至少要设置TCP_NODELAY来关闭Nagle算法降低小包延迟又比如epoll_wait返回的事件数量很大时要循环处理完所有事件而不是只处理前几个。我见过不少同事把epoll_wait的返回值当作可处理的事件数然后只遍历前N个事件。这个理解是对的但如果就绪事件非常多一次epoll_wait返回了几百个事件只处理前几十个就把剩余事件丢弃会造成事件丢失。正确做法是遍历全部返回的event数组因为epoll_wait返回的事件数量是实际就绪的事件数量而不是一个上限值。3.4 非阻塞IO在业务代码里的实际案例假设我们做一个简单的IM消息推送服务客户端通过TCP长连接连接到服务器服务器需要支持大量连接同时在线并且能够把消息推送给指定用户。这个场景如果采用阻塞式IO撑死几百个连接而且不可能做全局广播。使用非阻塞IO epoll后单机支持几万连接是非常轻松的事情。因为每个连接只占用一个fd事件循环里真正活跃的连接才做IO操作大多数空闲连接的消耗几乎可以忽略。在业务代码层面每个连接需要维护的数据包括客户端的用户ID连接建立时间、最后活跃时间接收缓冲区和发送队列当前认证状态等业务信息这些数据在accept之后通过一个map把fd映射到对应的连接对象上。事件循环里拿到就绪fd后通过map找到对应的连接对象执行相应的业务逻辑。消息推送时往目标用户对应的fd的发送队列里写入数据同时注册EPOLLOUT事件等待可写时触发发送。这种结构非常清晰也是大部分C/C网络服务的基本架构。如果你用的是JavaNetty已经把event loop、ChannelPipeline这些概念做了很好的抽象如果你用的是Gogoroutine配合非阻塞的网络轮询也在运行时层面处理掉了语言层面的体验会友好很多。4. 关键问题与排查经验实录4.1 服务端连接数一高就频繁出现Connection Reset这个问题我在早期做长连接服务时踩过。客户端报错Connection reset by peer服务器日志里则出现大量send失败。排查的时候先确认了对端是不是真的关闭了连接。用tcpdump抓包看发现客户端已经发送了FIN包但服务端没有及时read到对端的FIN反而继续往这个连接上写数据。TCP协议栈在收到FIN之后如果继续收到数据会回复RSTRST一回来后续再write自然就报错。背后的原因是业务进程处理能力跟不上事件循环里有大量逻辑耗时过高导致即使socket有数据或者关闭事件也没有及时读到。这里的解法是一是减少事件循环里的耗时操作比如把日志、DB操作挪到单独线程池二是在write返回EPIPE错误时主动关闭连接并清理fd。EPIPE这个信号如果被忽略进程会被直接终止所以在写socket的代码里务必对SIGPIPE信号做处理通常的处理方式是signal(SIGPIPE, SIG_IGN)让write返回EPIPE错误码而不是杀掉进程。4.2 accept之后立刻read却一直EAGAIN有些同学在accept返回一个新连接之后立刻就在循环里调用read发现几乎每次都是EAGAIN。这其实是正常的。因为客户端数据到达还需要一个网络往返时间刚accept完数据可能还没到读到EAGAIN说明当前无数据可读不代表任何异常。正确的做法是把新连接注册到epoll里等可读事件而不是accept之后立刻同步读。如果你真的有必须在accept后立刻读取的场景那一般只适用于特殊协议且要处理好EAGAIN。4.3 epoll_wait返回的fd在我自己的连接表里找不到这个问题多出现在连接初始化和关闭的竞争场景。可能这个fd已经被close但事件队列里还有残留的事件没有处理完。还有一种可能是fd被复用新连接恰好分配了同一个fd号旧事件就错误地和新连接关联起来了。如果是多线程同时处理epoll事件这种问题就会更复杂。我建议事件循环单线程化或者使用多线程时确保同一个fd始终由同一个线程处理close fd之前先从epoll中移除再执行close维护连接状态标记处理事件前先校验连接的当前状态4.4 疑似内存泄漏连接数持续增长但是业务并发没涨出现这种情况先别急着怀疑代码里有分配没有释放。用ss或者netstat查看当前连接状态如果存在大量TIME_WAIT连接这是正常的主动关闭连接的一方会进入TIME_WAIT状态等待2MSL时间确保所有包都已经处理完毕。如果大量连接处于ESTABLISHED状态说明连接根本没有被关闭很可能是业务侧忘记调用close或者读到了EOF但是没走关闭分支。还有一种情况是keepalive配置的保活探测周期太长死链要很久才会被系统回收。这种问题调试时配合lsof、strace加上系统日志逐层排查定位速度会快很多。很多新手有个误区一上来就怀疑内核参数其实大多数情况下都是业务代码没有正确管理连接生命周期。4.5 非阻塞write总丢数据的排查思路如果你发现通过非阻塞socket发送的数据接收方总是少包优先考虑应用层发送队列是否实现了。非阻塞模式下write返回值可能小于你要发送的长度而这个部分写入是非常常见的尤其是在发送窗口变小时。处理的原则是定义write_complete函数内部循环write并且处理两种情况写完之后还有剩余则把剩余数据挂到发送队列等待可写事件可写事件触发时继续把队列里的数据发送出去如果服务端需要给单个客户端发送大数据块而客户端读取速度固定那发送缓冲区极容易积压。此时需要限速或者断连避免缓冲无限增长导致内存耗尽。5. 工具选型与实战配套建议5.1 Linux平台从epoll到io_uring的进阶路线Linux上最常见的多路复用工具是epoll它已经足够高效、稳定。除非你明确需要极致性能否则不必轻易上io_uring。如果你要构建消息网关、缓存服务这类高并发低延迟的系统可以了解io_uring它在异步化方面做得更彻底但对使用者的要求也高一些。我自己的经验是先用epoll把业务做对再谈io_uring优化不迟。5.2 跨平台方案Netty和libevent这类库的价值Java生态里Netty已经是事实标准它对业务程序员屏蔽了底层差异。用Netty写聊天服务、网关服务都很方便而且它的线程模型封装得成熟扩展性好。C/C生态里libevent和libuv也可以跨平台libuv是Node.js的底层事件库稳定性有保障。这里多说一句现在很多新项目直接用Go或者Rust这类语言它们在网络并发的处理上做了大量运行时优化底层屏蔽了非阻塞IO和事件循环的复杂性。Go的netpoller、Rust的tokio本质上都是非阻塞IO 多路复用的封装理解底层模型后用这些框架会有一种原来如此的豁然开朗感。5.3 推荐的两个排查利器strace和tcpdump排查IO问题的时候strace可以观察进程的系统调用行为确认是否发生了阻塞以及阻塞在哪里。启动一个简单的命令用strace跟踪其系统调用序列非常直观strace -f -e tracenetwork,read,write -p pidtcpdump则可以看网络包层面的交互过程确认握手、挥手、重传等细节tcpdump -i eth0 tcp port 8080 -nn -A这两个工具再加上ss、netstat、lsof这些常规命令基本覆盖了常见的IO排查需求。6. 多路复用的底层机制与性能边界6.1 select和poll到底慢在哪select的核心问题在于描述符集合是使用bitmap表示的有FD_SETSIZE限制默认1024超出就不可用。poll去掉了1024限制采用pollfd数组存储描述符但依然需要每次调用时把全部描述符传给内核内核在做完监听后要么修改传入的数组要么重新填充。无论select还是poll内核都要做一次全量扫描这个O(n)复杂度在连接数增长后成为瓶颈。这就像一家小餐馆客人到店后每来一波都要重新登记一遍所有人的姓名服务员再去逐个查看谁点的菜好了客人多了之后登记和查询的时间就会拖垮整体效率。6.2 epoll的高效体现在哪epoll的核心是三个操作epoll_ctl向内核事件表注册描述符、epoll_wait阻塞等待事件、事件就绪后从就绪列表取出事件。epoll_wait的时候不需要拷贝全部描述符集合到内核只需要传递一个就绪事件数组。内核通过回调机制在描述符就绪时直接加入到就绪链表里epoll_wait只需要把就绪链表复制到用户态即可。这个机制的效率是O(k)k是就绪事件的数量而不是连接总数。所以哪怕有一万个连接只有两个连接有数据epoll只会在那一次epoll_wait返回里告诉你这两个连接有数据不会去遍历剩下9998个没数据的连接。6.3 水平触发和边缘触发epoll支持两种触发模式水平触发LT和边缘触发ET。水平触发下只要缓冲区里还有数据epoll就会持续通知你所以即使你只读了一部分数据下次epoll_wait还会继续通知你不容易漏事件编程难度低。边缘触发下只有状态发生变化时才通知一次。如果你没有把数据全部读完剩下来的数据不会再有通知必须自己保证把缓冲区读干净。ET模式效率更高但漏读风险极大需要配合非阻塞IO循环读取把数据读至EAGAIN为止。我个人在做高并发服务时的习惯默认使用LT模式代码清晰、不容易出bug如果追求极致吞吐量再考虑ET模式并且严格测试读写的循环逻辑。6.4 事件驱动的性能边界事件驱动模型本身是单线程的它所受益的是没有线程切换开销、没有锁竞争但代价是一个事件循环里的CPU密集计算会阻塞所有连接的IO处理。所以如果某个业务逻辑要做复杂计算必须把它丢到线程池/协程池里执行事件循环只负责IO和轻量业务。Redis之所以能用单线程扛非常高并发深度原因正是它的事件循环里只做内存操作和IO没有阻塞点。而我们在业务代码里如果不小心加入了一个耗时的DB查询整个事件循环都会被拖住所有连接都会感受到延迟。这一点在设计架构时就要有意识地去规避。7. 按场景快速选型参考为了节省大家的时间我把常见场景下的IO模型选择整理成一个速查表。这个表并不是绝对标准但可以作为起步阶段的参考场景推荐模型理由单客户端文件读写/串口通信阻塞IO简单可靠调试容易少量连接的长连接服务阻塞IO 线程池代码清晰连接数可控时线程开销可以接受高并发短连接服务如HTTP非阻塞IO epoll减少线程开销支撑海量连接大规模长连接推送系统非阻塞IO epollLT/ET单机支持数万连接事件驱动高效管道/流式处理系统非阻塞IO或异步IO避免阻塞等待提升吞吐超高性能磁盘IO/NVMe场景io_uring异步IO彻底异步化降低系统调用开销推荐的原则只有一条优先选择你团队能驾驭的模型而不是纸面上性能最高的模型。错误使用异步IO的代价远比正确使用阻塞IO要高得多。8. 我踩过的坑和给后来者的建议第一不要试图用非阻塞IO模拟异步IO的效果。非阻塞IO本质是同步的它只是不等待数据而异步IO是内核完全帮你做完输入输出。如果非要从非阻塞IO里压榨出异步的效果往往会引入非常复杂的回调逻辑代码的可维护性会急剧下降。第二使用epoll的时候务必确认accept返回的每个连接都设置了TCP_NODELAY。Nagle算法默认开启时小包会被延迟合并这对实时性要求高的协议比如游戏、IM极不友好。很多延迟问题排查到最后就是这一个参数的问题。第三事件循环里尽可能不要做任何可能被阻塞的系统调用。比如磁盘IO、DB同步操作最好都放到其他线程去处理事件循环保持非阻塞 快速返回的节奏。这样才能发挥事件驱动模型的全部优势。第四遇到莫名奇妙的丢包、延迟问题先上tcpdump抓包看TCP层的表现再看应用层的协议解析逻辑。很多时候问题不在IO模型本身而在半包、粘包的处理逻辑上。我个人做了几年网络相关的开发之后最大的体会是IO模型没有银弹。每个模型的适用边界都很清晰关键是对自己的业务场景有准确的评估。刚开始做高并发服务的时候我也是把epoll、非阻塞IO、事件循环这些概念背得滚瓜烂熟但直到真的写出一个单机扛下几万连接的推送服务实际运行稳定上线之后才真正理解内核和业务之间这些微妙的关系。如果你正在走这条路建议先挑一个小型项目把非阻塞IO和epoll的组合完整写一遍在真实的数据量和连接数下观察它的表现。这个过程比看十篇理论文章都管用。