I/O模型深度解析：从阻塞到异步，一次讲透

说实话，I/O模型这个话题，我每次讲课时都觉得特别重要。它就像网络编程的"内功心法"——你招式再花哨，内功不行，关键时刻准掉链子。今天咱们就把五种I/O模型掰开揉碎了聊。

1. 阻塞I/O：最朴实的做法

阻塞I/O，说白了就是"死等"。你调用recvfrom，数据没来？那你就老老实实等着，啥也别干。

// 阻塞I/O示例
int sock = socket(AF_INET, SOCK_STREAM, 0);
connect(sock, ...);
char buf[1024];
// 这一行会卡住，直到有数据
int n = recv(sock, buf, sizeof(buf), 0);

我在项目中遇到过一个问题：一个网关程序，用阻塞I/O处理多个客户端连接。结果一个客户端发数据慢了，其他所有客户端都得等着。这就像你去银行办业务，前面一个人办了两个小时，后面的人全得站着等——效率太低了。

2. 非阻塞I/O：轮询的代价

非阻塞I/O的思路是：我调用recvfrom，数据没来？没关系，我先去干别的，过一会儿再来问。

// 设置非阻塞
int flags = fcntl(sock, F_GETFL, 0);
fcntl(sock, F_SETFL, flags | O_NONBLOCK);

// 轮询读取
while (1) {
    int n = recv(sock, buf, sizeof(buf), 0);
    if (n > 0) {
        // 处理数据
        break;
    } else if (errno == EAGAIN) {
        // 没数据，先干别的
        do_other_work();
        continue;
    }
}

你想想看，这种轮询方式有什么问题？CPU一直在空转。我曾经接手过一个项目，里面用了非阻塞I/O加while循环轮询，CPU占用率直接飙到100%。说白了，这就是用CPU资源换响应速度，得不偿失。

3. I/O多路复用：select/poll/epoll

这是今天最核心的内容。I/O多路复用的思路是：用一个线程同时监控多个文件描述符，哪个准备好了就处理哪个。

3.1 select：老当益壮

fd_set readfds;
FD_ZERO(&readfds);
FD_SET(sock1, &readfds);
FD_SET(sock2, &readfds);

struct timeval tv = {5, 0}; // 5秒超时
int ret = select(max_fd + 1, &readfds, NULL, NULL, &tv);

if (ret > 0) {
    if (FD_ISSET(sock1, &readfds)) {
        // 处理sock1
    }
    if (FD_ISSET(sock2, &readfds)) {
        // 处理sock2
    }
}

select的问题很明显：文件描述符数量有限制（默认1024），而且每次调用都要把整个fd_set从用户态拷贝到内核态。我记得有一次做高并发测试，连接数刚过1000，select就开始丢事件了——这就是它的硬伤。

3.2 poll：改进有限

poll解决了select的1024限制，但性能问题依然存在。它用链表存储文件描述符，没有上限了，但每次调用还是要遍历所有fd。

struct pollfd fds[2];
fds[0].fd = sock1;
fds[0].events = POLLIN;
fds[1].fd = sock2;
fds[1].events = POLLIN;

int ret = poll(fds, 2, 5000); // 5秒超时

说实话，poll和select在本质上没有太大区别。它们都是"无状态"的——每次调用都要重新传入所有fd，内核也不知道上次处理到哪了。

3.3 epoll：Linux下的王者

epoll才是真正解决性能问题的方案。它的核心思想是事件驱动——内核帮你记住哪些fd是你关心的，有事件发生时主动通知你。

// 创建epoll实例
int epfd = epoll_create1(0);

// 添加监听
struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = sock1;
epoll_ctl(epfd, EPOLL_CTL_ADD, sock1, &ev);

// 等待事件
struct epoll_event events[1024];
while (1) {
    int n = epoll_wait(epfd, events, 1024, -1);
    for (int i = 0; i < n; i++) {
        if (events[i].events & EPOLLIN) {
            // 处理就绪的fd
            handle_read(events[i].data.fd);
        }
    }
}

我个人习惯用epoll的边缘触发（ET）模式。为什么？因为水平触发（LT）模式下，如果一次没读完数据，下次epoll_wait还会通知你——这可能导致重复处理。边缘触发只通知一次，你必须一次性把数据读完。

4. 信号驱动I/O：另辟蹊径

信号驱动I/O的思路是：你告诉内核"数据准备好了发个信号给我"，然后你就可以去干别的事了。信号来了，再处理。

// 启用信号驱动I/O
fcntl(sock, F_SETOWN, getpid());
int flags = fcntl(sock, F_GETFL, 0);
fcntl(sock, F_SETFL, flags | O_ASYNC);

// 信号处理函数
void sigio_handler(int sig) {
    // 读取数据
    char buf[1024];
    int n = recv(sock, buf, sizeof(buf), 0);
    // 处理...
}

// 注册信号处理
signal(SIGIO, sigio_handler);

嗯，这里要注意：信号驱动I/O在实际项目中用得不多。为什么？因为信号处理函数里能做的事情有限，而且多个信号可能丢失。我曾经在一个UDP服务器里试过，结果发现高并发下信号会排队，处理不过来。

5. 异步I/O：终极方案？

异步I/O是最理想的模型：你发起一个读操作，然后完全不用管。内核把数据读好放到你指定的缓冲区里，再通知你"搞定了"。

// Linux AIO示例（简化）
struct iocb cb;
struct io_event events[1];
io_context_t ctx;

// 准备异步读
io_prep_pread(&cb, fd, buf, sizeof(buf), 0);
io_set_eventfd(&cb, event_fd);

// 提交请求
struct iocb *cbs[] = {&cb};
io_submit(ctx, 1, cbs);

// 干别的事...
do_other_work();

// 等结果
io_getevents(ctx, 1, 1, events, NULL);

说实话，Linux下的异步I/O（AIO）一直有点"尴尬"。它对于磁盘I/O表现不错，但网络I/O的支持并不完美。Windows下的IOCP倒是做得很好，但那是另一套体系了。

知识体系总览

下面这张图，是我梳理的五种I/O模型的核心逻辑。你可以看到，从阻塞到异步，核心变化在于"谁在等"以及"怎么等"。

如何选择？我的实战建议

讲了这么多，到底该用哪个？我根据实际项目经验，给你几个参考标准：

• 连接数 < 100：用阻塞I/O + 多线程就够了。简单、稳定、好调试。
• 连接数 100-1000：select或poll都可以。注意select有1024限制。
• 连接数 > 1000：必须上epoll。这是Linux下高并发的唯一选择。
• 磁盘I/O密集型：可以考虑异步I/O（AIO），但要做好缓冲区管理。
• 跨平台需求：用libevent或libuv这类封装库，它们帮你屏蔽了底层差异。

好了，五种I/O模型就聊到这儿。记住一句话：理解I/O模型，就是理解"等待"的艺术。你在等数据的时候，CPU在干什么？内核在干什么？想清楚这些，你就能写出高性能的网络程序。