16、I/O操作的重构：从阻塞I/O到非阻塞I/O、引入libevent/libuv、异步编程模式
聊到I/O重构，我得先说说自己早年踩过的一个坑。
那时候我维护一个网络服务程序，连接数一上来，程序就卡死。排查了半天，发现所有线程都在等I/O——等磁盘读、等网络收、等数据库回包。说白了，大家都在排队干等，CPU闲得发慌，业务却跑不动。
嗯，这就是典型的阻塞I/O问题。
阻塞I/O：为什么它成了瓶颈？
阻塞I/O的模型很简单：你调用read()，数据没到，线程就挂起。你调用write()，缓冲区满了，线程继续挂起。
单线程场景下，一个阻塞点就能让整个程序停摆。多线程场景呢？每个连接一个线程，线程数一多，上下文切换的开销就上来了。我记得有个项目，连接数到5000的时候，光是线程切换就占了40%的CPU。
说白了，阻塞I/O的致命伤就两条：
- 线程浪费：大量线程在等I/O，啥也不干
- 扩展性差：连接数一涨，线程数跟着涨，系统先扛不住
核心矛盾：程序需要处理成千上万个连接，但操作系统能高效管理的线程数有限。阻塞I/O让这个矛盾彻底暴露。
非阻塞I/O：让程序不再干等
非阻塞I/O的思路其实很直接：调用read()时，如果没数据，立即返回一个错误码（比如EAGAIN），而不是挂起线程。这样线程就可以去干别的事，过会儿再来检查。
但这里有个问题——你怎么知道什么时候该来检查？
轮询？那CPU就烧了。所以我们需要一种机制，让操作系统告诉我们：「嘿，这个fd可以读了」。这就是I/O多路复用——select、poll、epoll（Linux）和kqueue（macOS/FreeBSD）。
我个人习惯用epoll，它在高并发场景下表现最好。但直接操作epoll的API，代码写起来挺啰嗦的。你想想看，要处理事件注册、回调、错误处理、边缘触发和水平触发的区别……嗯，这里很容易出bug。
避坑指南：我曾经在epoll的边缘触发模式下，漏读了数据。原因是没在循环里读完所有数据，导致事件不再触发。后来养成了习惯——边缘触发必须配合非阻塞I/O，并且要循环读取直到EAGAIN。
引入libevent/libuv：把复杂留给自己
直接操作epoll/kqueue，代码量不小，而且跨平台是个大问题。这时候就需要事件库来帮忙了。
我接触过的两个主流库：
| 特性 | libevent | libuv |
|---|---|---|
| 出身 | Nginx、Memcached 在用 | Node.js 的底层引擎 |
| 平台支持 | Linux/macOS/Windows（通过IOCP） | 全平台，Windows支持好 |
| API风格 | 偏底层，更接近epoll | 封装更完整，自带定时器、DNS、文件I/O |
| 性能 | 极高，适合网关类 | 高，适合应用层开发 |
我个人建议：如果你做的是高性能中间件，libevent更合适；如果你做应用层服务，libuv用起来更顺手。
来看看libevent怎么用：
#include <event2/event.h>
void on_read(evutil_socket_t fd, short what, void *arg) {
char buf[1024];
int n = read(fd, buf, sizeof(buf));
if (n > 0) {
printf("收到数据: %s\n", buf);
}
}
int main() {
struct event_base *base = event_base_new();
struct event *ev = event_new(base, sockfd, EV_READ | EV_PERSIST, on_read, NULL);
event_add(ev, NULL);
event_base_dispatch(base); // 事件循环
return 0;
}
你看，代码简洁多了。不用管epoll的epoll_ctl，不用处理边缘触发。把回调函数注册好，事件库帮你搞定一切。
关键点：事件库的核心是事件循环（event loop）。它本质上是一个无限循环，不断调用epoll_wait（或等价函数），拿到就绪的fd，然后调用对应的回调函数。你的业务逻辑就写在回调里。
异步编程模式：回调、Promise、协程
引入事件库之后，编程模式就变了。不再是「顺序执行」，而是「注册回调，等待通知」。
这种模式有几个常见形态：
- 回调（Callback）：最基础。事件触发时调用你注册的函数。缺点是回调嵌套深了，代码可读性差——俗称「回调地狱」。
- Promise/Future：C++11以后有std::future，但C语言里没有原生支持。有些库自己实现了类似机制。
- 协程（Coroutine）：C语言里可以用ucontext或者汇编实现协程切换。libuv配合协程，写起来就像同步代码，但底层是非阻塞的。
我经历过一个项目，回调嵌套了五六层，调试起来简直要命。后来重构时引入了协程，代码瞬间清爽了。说白了，异步编程的难点不在性能，而在「怎么把逻辑写清楚」。
注意：异步编程里，回调函数中不能做阻塞操作。一旦阻塞，整个事件循环就停了，所有连接都受影响。我曾经见过有人在回调里调sleep()，结果整个服务响应延迟飙升。正确的做法是：把耗时操作扔到线程池里，或者用异步版本的系统调用。
重构路线图：从阻塞到非阻塞
如果你手里有个遗留系统，想改成非阻塞I/O，我建议分三步走：
- 先隔离I/O操作：把所有的read/write/connect/accept封装成统一的接口。这样后面替换时，改动范围可控。
- 引入事件库：用libevent或libuv替换掉原来的select/poll（如果原来用的是select，性能提升会非常明显）。
- 逐步迁移业务逻辑：把阻塞的I/O调用改成异步回调。这一步最耗时，建议从最核心的路径开始改，改完一个功能就测试一个。
嗯，这里要提醒一句：不要试图一次性全部改完。我见过一个团队，花三个月重构I/O层，结果上线后出了各种问题，又花了两个月回滚。更好的做法是——每次改一个模块，灰度上线，观察稳定后再改下一个。
SVG：I/O重构核心逻辑图
总结
从阻塞I/O到非阻塞I/O，说白了就是一次思维模式的转变。你不再控制流程，而是响应事件。事件库帮你屏蔽了底层差异，让你能专注于业务逻辑。
我个人觉得，这件事值得做。尤其是当你的服务需要支撑高并发时，非阻塞I/O几乎是必经之路。虽然重构过程有点痛苦，但改完之后，你会发现系统稳定多了，资源利用率也上去了。
嗯，最后说一句：别怕改代码，怕的是不改。
推荐实践：如果你刚开始接触，建议先用libuv写一个简单的echo server。跑起来，压测一下，看看单线程能撑多少连接。你会惊讶的——几万连接根本不是问题。
公众号:蓝海资料掘金营，微信deep3321