从阻塞IO到Reactor协程：高性能并发模型演进

1. 从阻塞IO到现代并发模型的演进之路

第一次接触服务器编程时，我像大多数新手一样从最简单的阻塞式socket开始写起。那个经典的accept+read循环看起来如此直观，直到某天压测时发现连接数超过100后性能直线下降——这就是著名的C10K问题给我的当头一棒。传统阻塞IO模型就像超市单收银台，每个顾客(连接)必须排队等待完全服务完毕后才能处理下一个，这种同步阻塞的特性注定了其无法应对高并发场景。

现代高性能服务通常采用Reactor模式配合协程实现，这种组合就像开设了自助收银区：Reactor相当于红外扫描器(事件分发器)，快速识别哪些商品(IO事件)需要处理；协程则像灵活的收银员，可以随时暂停当前交易去处理其他顾客的请求。我的mini epoll demo实测显示，在4核机器上这种模型可以轻松支撑2万+的并发连接，而线程数始终保持在CPU核心数附近。

2. 阻塞IO的本质与性能瓶颈

2.1 同步阻塞的底层原理

在传统的阻塞IO模型中，当线程执行read/accept等系统调用时，内核会将线程状态设置为TASK_INTERRUPTIBLE，并将其移出运行队列。这个看似简单的操作背后隐藏着昂贵的上下文切换开销：

cpp复制// 典型阻塞式服务端代码
while(true) {
    int client_fd = accept(server_fd, NULL, NULL); // 阻塞点1
    char buffer[1024];
    int n = read(client_fd, buffer, sizeof(buffer)); // 阻塞点2
    process(buffer);
    write(client_fd, response, response_len); // 阻塞点3
}

每个阻塞操作都导致线程从用户态陷入内核态（约0.5-2μs），再伴随着可能的线程切换（约1-10μs）。当并发连接数N上升时，性能损耗呈O(N)增长，这就是为什么简单的echo服务器在1000并发时QPS可能不足1000。

2.2 线程池方案的局限性

为缓解阻塞问题，开发者常采用线程池方案：

cpp复制ThreadPool pool(4);
while(true) {
    int client_fd = accept(server_fd, NULL, NULL);
    pool.enqueue([client_fd]{
        // 处理逻辑
    });
}

这种方案虽然提升了吞吐量，但面临三个本质问题：

1. 线程上下文切换成本随线程数增加而上升（约1-3μs/次）
2. 每个线程需要预分配栈空间（默认2-8MB），内存消耗大
3. 线程数超过CPU核心数时会产生调度竞争

在我的压力测试中，4核机器上线