4. IO多路复用技术选型

当单机需要同时承载成千上万条连接时，最朴素的做法是“一连接一线程”，但线程栈、上下文切换和内核调度开销会迅速压垮系统。IO多路复用正是为了解决“一个线程如何同时管理大量文件描述符（fd）”这一问题而出现的。它把“等待哪些 fd 可读/可写”的决策交给内核，应用线程只需在事件就绪时被唤醒并处理。理解 select、poll、epoll、kqueue、IOCP 的差异，本质上是在理解三件事：内核如何保存你关心的 fd 集合、内核如何通知你哪些 fd 就绪、以及每次等待是否需要重复传递整个集合。

一、五种机制的机制差异

select 使用位图（fd_set）表示关注的 fd 集合，受 FD_SETSIZE 限制（Linux 默认 1024）。每次调用都要把整个集合从用户态拷贝到内核态，内核线性扫描所有 fd，返回后应用还需再次遍历判断哪个 fd 就绪。它的优点是跨平台极好，几乎所有 Unix 都支持。

poll 用 pollfd 数组替代位图，去掉了 1024 的数量限制，但“每次拷贝整个数组 + 内核线性扫描 + 返回后应用遍历”的模式没有改变。当连接数达到数万时，O(n) 的扫描成本成为瓶颈。

epoll 是 Linux 的改进方案，核心是三个系统调用：epoll_create 创建内核事件表，epoll_ctl 增删改关注的 fd（只需注册一次），epoll_wait 等待事件。内核用红黑树管理 fd，用就绪链表保存已触发的事件，因此 epoll_wait 只返回真正就绪的 fd，复杂度接近 O(1)。它支持水平触发（LT）和边缘触发（ET）两种模式。

kqueue 是 FreeBSD/macOS 的等价机制，通过 kevent 一次性提交变更并获取事件，同样避免了重复拷贝，且能统一处理文件、信号、定时器等多种事件源。

IOCP（Windows 完成端口）走的是完全不同的路线：它不是“就绪通知”，而是“完成通知”。应用先投递一个异步 IO 请求，内核完成读写后把结果放入完成队列，工作线程通过 GetQueuedCompletionStatus 取结果。它天然与线程池结合，没有“就绪后还要自己 read/write”的二次系统调用。

二、触发模式：LT 与 ET 的取舍

epoll 和 kqueue 都支持水平触发（Level Triggered）与边缘触发（Edge Triggered）。LT 模式下，只要 fd 缓冲区还有数据，epoll_wait 就会持续返回该事件，编程模型接近 select，不容易漏读；ET 模式只在状态变化时通知一次，应用必须循环 read 直到返回 EAGAIN，否则剩余数据会“沉默”在缓冲区里。ET 的优点是减少事件通知次数、降低系统调用频率，但要求 fd 必须是非阻塞的，且读写逻辑必须写完整。实践中，若团队对非阻塞编程不熟练，优先用 LT；追求极致吞吐且能保证读干净时再用 ET。

三、选型决策与适用场景

选型不能只看“谁最快”，而要看运行平台、连接规模、编程模型和团队能力四者的交集。下面给出一个可直接对照的决策表：

四、一个可运行的 epoll 骨架示例

下面这段 C 代码展示了 epoll 的典型使用方式：创建实例、注册监听 fd、在事件循环中只处理就绪事件。注意 listen_fd 用 LT 模式即可，已连接 fd 若用 ET 必须配合非阻塞读循环。

int epfd = epoll_create1(0);
struct epoll_event ev, events[1024];

ev.events = EPOLLIN;          // 监听可读
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

while (1) {
    int n = epoll_wait(epfd, events, 1024, -1);
    for (int i = 0; i < n; i++) {
        int fd = events[i].data.fd;
        if (fd == listen_fd) {
            int conn = accept(listen_fd, NULL, NULL);
            set_nonblocking(conn);
            ev.events = EPOLLIN | EPOLLET;   // 边缘触发
            ev.data.fd = conn;
            epoll_ctl(epfd, EPOLL_CTL_ADD, conn, &ev);
        } else {
            // ET 模式：必须循环读到 EAGAIN
            char buf[4096];
            while (read(fd, buf, sizeof(buf)) > 0) { /* 处理数据 */ }
        }
    }
}

五、常见误区与排障要点

• “epoll 一定比 select 快”：连接数很少时，epoll_ctl 的注册开销反而可能让总耗时略高，只是差异在微秒级，通常不影响选型。
• “ET 模式更高级所以必须用”：ET 对代码正确性要求高，漏读会导致连接假死；LT 在多数业务中已经足够。
• “IOCP 和 epoll 可以互相替代”：IOCP 是完成通知模型，移植到 Linux 需改用 io_uring 或 epoll + 线程池模拟，语义并不等价。
• “select 的 1024 限制改编译参数就行”：FD_SETSIZE 改动会影响整个进程的 fd_set 布局，风险高，不如直接换 poll/epoll。

综合来看，Linux 生产环境的高并发网络服务应默认选择 epoll；需要跨 Unix 时用 epoll/kqueue 双后端封装；Windows 平台用 IOCP；只有在连接规模小、可移植性优先或教学演示时，才退回 select/poll。选型的核心不是记住“谁最好”，而是清楚每种机制在 fd 管理、通知语义和每次等待成本上的真实差异，再与业务规模匹配。