1. 阻塞式IO：原始而直接的交互方式

在计算机发展的早期阶段，阻塞式IO（Blocking IO）是唯一的IO处理模式。其核心特征是：当进程发起系统调用（如read()）时，内核会暂停该进程的执行，直到数据就绪并完成拷贝。这种模式的典型代码结构如下：

int fd = open("/dev/sda1", O_RDONLY);
char buffer[1024];
ssize_t n = read(fd, buffer, sizeof(buffer)); // 阻塞直到数据到达
if (n > 0) {
    // 处理数据
}

阻塞式IO的优点在于实现简单直观，但存在致命缺陷：资源利用率极低。例如在Web服务器场景中，每个连接都需要一个独立线程，当并发量达到千级时，线程切换开销会吞噬大部分CPU资源。Linux 2.4内核时期，Apache的prefork模型就深受此问题困扰。

2. 非阻塞式IO：从被动等待到主动轮询

为解决阻塞问题，非阻塞式IO（Non-blocking IO）应运而生。通过设置文件描述符为非阻塞模式（O_NONBLOCK），系统调用会立即返回：

int fd = open("/dev/sda1", O_RDONLY | O_NONBLOCK);
char buffer[1024];
while (1) {
    ssize_t n = read(fd, buffer, sizeof(buffer));
    if (n == -1 && errno == EAGAIN) {
        // 数据未就绪，执行其他任务
        usleep(1000);
        continue;
    }
    // 处理数据
    break;
}

这种模式虽然避免了进程挂起，但引入了新问题：忙等待（Busy Waiting）。开发者需要手动实现轮询逻辑，当并发连接数增加时，CPU会浪费大量周期在无效的read()调用上。2003年Java NIO推出时，其Selector机制正是为了解决这个痛点。

3. IO多路复用：高效的事件驱动模型

IO多路复用（IO Multiplexing）通过一个线程监控多个文件描述符，将事件通知与业务处理解耦。其发展经历了三个阶段：

3.1 select/poll：基础多路复用

fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(sockfd, &read_fds);
struct timeval timeout = {5, 0};
int n = select(sockfd+1, &read_fds, NULL, NULL, &timeout);

select存在两个严重缺陷：文件描述符数量限制（通常1024）和每次调用需要重置fd_set。poll通过动态数组解决了数量限制，但内核-用户空间的数据拷贝开销仍然存在。

3.2 epoll：Linux的革命性创新

2002年引入的epoll通过三个系统调用构建高效机制：

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

epoll的核心优势在于：

• 红黑树管理：高效的事件注册/注销
• 就绪列表：避免遍历所有文件描述符
• 边缘触发（ET）：减少事件通知次数

在Nginx的架构中，epoll使得单个工作进程可以处理数万并发连接，相比Apache性能提升10倍以上。

3.3 kqueue/iocp：其他系统的解决方案

BSD系统的kqueue通过EVFILT_READ等过滤器实现类似功能，而Windows的IO完成端口（IOCP）则采用完成队列模型：

HANDLE hIOCP = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);
// 为每个socket绑定IOCP
CreateIoCompletionPort((HANDLE)sockfd, hIOCP, (ULONG_PTR)sockfd, 0);
while (1) {
    ULONG_PTR key;
    LPOVERLAPPED pOverlapped;
    LPDWORD bytes;
    GetQueuedCompletionStatus(hIOCP, bytes, &key, &pOverlapped, INFINITE);
    // 处理完成事件
}

IOCP的优势在于将异步操作与完成通知解耦，特别适合高吞吐场景。

4. 异步IO：真正的非阻塞体验

异步IO（Asynchronous IO）的核心特征是：操作发起后立即返回，内核在完成时通过回调或信号通知应用。POSIX AIO和Linux的io_uring是其典型实现。

4.1 POSIX AIO的局限性

struct aiocb cb = {0};
cb.aio_fildes = fd;
cb.aio_buf = buffer;
cb.aio_nbytes = sizeof(buffer);
cb.aio_offset = 0;
aio_read(&cb);
while (aio_error(&cb) == EINPROGRESS) {
    // 等待完成
}
ssize_t n = aio_return(&cb);

POSIX AIO存在两个主要问题：线程池实现导致性能波动，以及信号通知机制复杂。

4.2 io_uring：现代Linux的终极方案

2019年推出的io_uring通过两个环形缓冲区（提交队列SQ和完成队列CQ）实现零拷贝通信：

struct io_uring ring;
io_uring_queue_init(32, &ring, 0);
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, fd, buffer, sizeof(buffer), 0);
io_uring_submit(&ring);
struct io_uring_cqe *cqe;
io_uring_wait_cqe(&ring, &cqe);
// 处理完成事件
io_uring_cqe_seen(&ring, cqe);

io_uring的创新点在于：

• 无系统调用开销：通过内存映射直接与内核交互
• 多操作批处理：单个submit可包含多个请求
• SQPOLL模式：内核线程主动轮询，彻底消除用户态等待

在数据库场景测试中，io_uring相比epoll+线程池方案，延迟降低60%，吞吐量提升3倍。

5. 演进规律与选型建议

IO模型的演进呈现明显规律：

1. 从同步到异步：减少进程/线程阻塞
2. 从用户态轮询到内核通知：降低CPU浪费
3. 从单次操作到批量处理：提升吞吐量

开发者选型时应考虑：

• 延迟敏感型应用：优先选择io_uring或IOCP
• 高并发场景：epoll/kqueue仍是最佳选择
• 简单性需求：现代语言提供的异步API（如Go的net.Listener）可能更合适

未来发展方向包括：

• 硬件辅助IO：如DPDK的用户态驱动
• 统一抽象层：如Linux的liburing对多种IO机制的封装
• AI预测调度：通过机器学习优化事件处理顺序

IO模型的演进史本质上是操作系统与应用程序协作效率的优化史。从最初的简单阻塞到如今的零拷贝异步通知，每次技术突破都伴随着系统吞吐量和响应速度的质变。理解这些演进脉络，能帮助开发者在复杂场景中做出最优技术选型。