使用poll(2)或epoll(2)等I/O多路复用API时，该用阻塞还是非阻塞TCP套接字？

这问题问得特别戳痛点——很多刚上手多路复用的同学都会有这个疑惑：既然epoll已经精准告诉我哪个套接字有数据了，直接用阻塞套接字读/写不就完事了？为啥还要多此一举搞非阻塞？其实这里面藏着几个容易踩的硬坑，咱们一个个掰扯清楚：

1. 边缘触发（EPOLLET）模式下的致命陷阱 #

如果你用了epoll的边缘触发模式（高性能服务的常用选择），epoll只会在套接字状态从无事件变为有事件时触发一次通知。举个实打实的例子：

• 客户端给你发了10KB数据，epoll通知你这个fd可读
• 你用阻塞的recv()读了5KB，内核缓冲区里还剩5KB数据
• 但边缘触发只会发一次通知，epoll不会再告诉你这个fd还有残留数据
• 结果就是你的程序直接卡在这里，剩下的5KB数据永远没人处理，客户端也一直等不到响应，直接僵死

换成非阻塞套接字就不一样了：recv()读完5KB后会立刻返回EAGAIN/EWOULDBLOCK错误，你一看就懂“现在没数据了，下次等epoll通知再处理”，完美避开这个陷阱。

2. 水平触发（LT）模式下的饥饿问题 #

就算你用的是默认的水平触发模式（epoll会反复通知直到事件处理完），阻塞套接字也会搞出乱子：
假设你的服务同时连了10个客户端，其中一个在传1GB的大文件，其他9个只是发小请求。

• epoll通知你大文件的fd可读，你用阻塞recv()去读
• 因为数据量太大，recv()会一直阻塞在这里啃数据，根本没时间搭理其他9个客户端的请求
• 结果就是其他客户端的请求全部“饿死”，服务看起来像假死了一样

非阻塞套接字的话，你每次读一部分就返回，处理完当前可用数据后立刻回到事件循环，能保证所有客户端的请求都被公平处理，不会出现“一家独大”的情况。

3. 特殊场景下的意外阻塞 #

还有些容易被忽略的场景，阻塞套接字会让你猝不及防：

• accept()的坑：epoll通知你有新连接，但如果对方在你调用accept()前突然断开（比如三次握手没完成），阻塞的accept()会直接挂住，整个事件循环原地停摆
• send()的坑：epoll通知你fd可写，你用阻塞send()发大数据，结果发送缓冲区满了，send()会一直阻塞直到缓冲区有空位，这时候其他fd的事件完全没人处理
• EOF与异常处理：当对方关闭连接时，epoll会通知fd可读，阻塞recv()会立即返回0（表示EOF），这时候没问题，但如果遇到信号中断等异常，阻塞调用可能会陷入不可预期的阻塞状态

总结 #

一句话说透：I/O多路复用的核心是让你同时监控多个fd的状态，批量处理就绪事件，但阻塞套接字会直接打破这个逻辑——只要有一个fd的操作卡住，整个事件循环就停了。非阻塞套接字能保证每个fd的操作都是“即时完成/即时返回”，让你的事件循环永远转得起来，所有就绪事件都能被处理到。

内容的提问来源于stack exchange，提问作者Emil Engler