阻塞IO模型（Blocking IO）

核心机制

阻塞IO是最基础的IO操作模式，其核心特征在于：当用户进程发起系统调用（如recvfrom）时，内核会同步处理数据读取，期间进程必须持续等待直至操作完成。这种”一对一”的等待关系导致进程在IO期间无法执行其他任务。

代码示例

int sockfd = socket(AF_INET, SOCK_STREAM, 0);
char buffer[1024];
ssize_t n = recvfrom(sockfd, buffer, sizeof(buffer), 0, NULL, NULL);
// 进程在此阻塞，直到数据到达或连接关闭

性能特征

• 延迟特性：单次IO操作延迟固定，包含完整的等待时间
• 吞吐量瓶颈：并发连接数受限于进程/线程数量（通常<1000）
• 资源消耗：每个连接需独占进程/线程（约2-10MB栈空间）

典型场景

• 简单命令行工具
• 低并发服务器（<500连接）
• 教学演示场景

非阻塞IO模型（Non-blocking IO）

核心机制

通过fcntl(fd, F_SETFL, O_NONBLOCK)设置文件描述符为非阻塞模式后，系统调用会立即返回。当数据未就绪时返回EAGAIN或EWOULDBLOCK错误，需要应用层通过轮询检查状态。

代码示例

int flags = fcntl(sockfd, F_GETFL, 0);
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);
while (1) {
    ssize_t n = recvfrom(sockfd, buffer, sizeof(buffer), 0, NULL, NULL);
    if (n > 0) {
        // 处理数据
        break;
    } else if (errno == EAGAIN) {
        usleep(1000); // 避免CPU占用过高
        continue;
    }
}

性能特征

• CPU效率：空轮询导致CPU资源浪费（需配合休眠机制）
• 实时性：数据就绪后能立即处理
• 扩展性：单线程可管理数千连接（需配合IO多路复用）

典型场景

• 需要快速响应的实时系统
• 连接数中等（1k-10k）的应用
• 自定义调度逻辑的场景

IO多路复用模型（Multiplexing IO）

核心机制

通过select/poll/epoll等系统调用，内核提供事件通知机制。应用层只需注册关注的文件描述符，当数据就绪时内核会主动通知，实现单线程管理海量连接。

三种实现对比

机制	最大连接数	时间复杂度	跨平台性	特色功能
select	1024	O(n)	高	通用性强
poll	无限制	O(n)	高	支持更多文件类型
epoll	无限制	O(1)	Linux	ET/LT模式、边缘触发

epoll代码示例

int epfd = epoll_create1(0);
struct epoll_event ev, events[MAX_EVENTS];
ev.events = EPOLLIN;
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);
while (1) {
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
    for (int i = 0; i < n; i++) {
        if (events[i].events & EPOLLIN) {
            // 处理就绪的连接
        }
    }
}

性能特征

• 扩展性：epoll可轻松支持10万+并发连接
• 延迟：事件通知存在微秒级延迟
• 内存：每个连接仅需约128字节内核空间

典型场景

• 高并发Web服务器（Nginx核心机制）
• 即时通讯系统
• 金融高频交易系统

信号驱动IO模型（Signal-driven IO）

核心机制

通过fcntl设置SIGIO信号，当文件描述符就绪时内核发送信号通知进程。需配合信号处理函数实现异步处理，但实际工程中应用较少。

代码示例

void sigio_handler(int sig) {
    // 处理IO就绪事件
}
signal(SIGIO, sigio_handler);
fcntl(sockfd, F_SETOWN, getpid());
flags = fcntl(sockfd, F_GETFL);
fcntl(sockfd, F_SETFL, flags | O_ASYNC);

性能特征

• 实时性：信号通知延迟约50-100μs
• 复杂性：需处理信号竞态条件
• 兼容性：信号处理函数有严格限制（不能调用非异步安全函数）

典型场景

• 特定Unix系统的监控程序
• 简单事件通知系统

异步IO模型（Asynchronous IO）

核心机制

真正实现”提交请求-继续执行-完成回调”的异步流程。通过io_getevents（Linux）或IOCP（Windows）等接口，内核在数据就绪且拷贝到用户空间后通知应用。

Linux AIO代码示例

struct iocb cb = {0};
struct iocb *cbs[] = {&cb};
char buffer[1024];
io_prep_pread(&cb, fd, buffer, sizeof(buffer), 0);
io_submit(aio_ctx, 1, cbs);
struct io_event events[1];
while (1) {
    int n = io_getevents(aio_ctx, 1, 1, events, NULL);
    if (n > 0) {
        // 处理完成的事件
        break;
    }
}

Windows IOCP示例

OVERLAPPED overlapped = {0};
char buffer[1024];
WSABUF wsaBuf = {sizeof(buffer), buffer};
DWORD flags = 0;
WSARecv(sockfd, &wsaBuf, 1, NULL, &flags, &overlapped, NULL);
// 通过GetQueuedCompletionStatus等待完成

性能特征

• 吞吐量：理论最优的IO模型
• 延迟：包含两次上下文切换开销
• 实现复杂度：需要处理完成队列和错误恢复

典型场景

• 数据库系统（Oracle、MySQL）
• 存储系统（Ceph、分布式文件系统）
• 高性能计算应用

模型对比与选型建议

性能维度对比

维度	阻塞IO	非阻塞IO	IO多路复用	信号驱动IO	异步IO
并发能力	低	中	极高	低	极高
延迟	高	中	中	低	最低
实现复杂度	低	中	高	极高	极高
跨平台性	高	高	中	低	低

选型决策树

1. 连接数<1000：阻塞IO（简单可靠）
2. 1k<连接数<10k：非阻塞IO+轮询（需控制CPU占用）
3. 10k<连接数<1M：epoll/kqueue（Linux/BSD首选）
4. 需要极致性能：异步IO（需平台支持）
5. 实时监控系统：信号驱动IO（特定场景）

优化实践建议

1. Linux环境：优先使用epoll+ET模式（边缘触发）
2. Windows环境：采用IOCP完成端口
3. 跨平台方案：libuv（Node.js底层库）或libevent
4. 内存优化：避免在事件循环中分配内存
5. 错误处理：统一封装各模型的错误处理逻辑

未来发展趋势

1. 用户态IO：如DPDK、SPDK绕过内核协议栈
2. RDMA技术：远程直接内存访问降低延迟
3. 持久内存：NVMe-oF改变存储IO模型
4. eBPF增强：可编程内核过滤提升epoll效率

本文系统梳理了五种IO模型的实现原理、性能特征和适用场景，开发者应根据具体需求（并发量、延迟要求、平台限制）选择合适方案。在实际工程中，往往需要组合使用多种模型（如epoll+线程池），并通过性能测试验证最终方案。