41、IO多路复用：select、poll、epoll的原理与使用，高并发服务器

说到高并发服务器，IO多路复用是绕不开的话题。很多初学者一上来就学select，然后发现poll，最后发现epoll才是王者。嗯，这个演进过程其实很有意思，它反映了操作系统对IO模型不断优化的思路。

我个人习惯把IO多路复用比作「一个接待员同时服务多个客户」。单线程阻塞IO就像一对一服务，来一个客户就开一个窗口，人多了就排队。而多路复用呢？一个接待员可以同时盯着多个客户，谁有事就处理谁，没事就等着。

为什么需要IO多路复用？

先看一个最简单的场景。你写了一个TCP服务器，要同时处理多个客户端连接。最原始的做法是每个连接开一个线程。但线程多了，上下文切换的开销就上来了。我记得有一次在嵌入式设备上测试，开了200个线程后，CPU全耗在切换上了，业务逻辑几乎跑不动。

IO多路复用的核心思想是：一个线程监控多个文件描述符（fd），当某个fd就绪（可读/可写/异常）时，再去处理它。这样就把「等待」和「处理」分开了。

核心概念：IO多路复用允许一个进程同时监控多个IO事件，避免阻塞在单个IO上。它解决的是「如何高效等待多个IO」的问题。

select：老当益壮，但力不从心

select是最早出现的多路复用函数。它的原型长这样：

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

使用select时，你需要把关心的fd放到三个集合里（读、写、异常），然后调用select。内核会帮你检查这些fd，哪个就绪了就标记上。你遍历所有fd，找到被标记的，然后处理。

听起来挺合理对吧？但select有几个硬伤：

  • fd数量有限制：默认最大1024个，改内核参数可以调大，但本质上是数组，大了效率下降
  • 每次都要重新设置fd集合：select会修改你传入的集合，所以每次调用前都要重新填一遍
  • O(n)的遍历复杂度：不管有多少fd就绪，你都得遍历全部fd才能找到就绪的
  • 内核态和用户态之间拷贝数据：每次调用都要把整个fd集合从用户态拷贝到内核态

我曾经在一个项目中用select管理500个连接，每次select返回后遍历全部500个fd，CPU占用率直接飙到30%。后来换成epoll，同样的连接数，CPU降到5%以下。

避坑指南：select的timeout参数在Linux上会被修改，返回剩余时间。如果你在循环中调用select，每次都要重新设置timeout。我曾经因为这个bug导致服务器间歇性超时，查了两天才发现。

poll：改进了，但没完全改

poll的出现解决了select的fd数量限制问题。它用链表来管理fd，理论上没有上限。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

struct pollfd {
    int   fd;         /* 文件描述符 */
    short events;     /* 关注的事件 */
    short revents;    /* 实际发生的事件 */
};

poll比select好在哪里？

  • 没有1024的限制，可以监控更多fd
  • 不需要重新设置events字段，因为revents是单独返回的
  • 事件类型更丰富（POLLRDHUP等）

但poll的底层实现和select其实差不多——仍然是O(n)的遍历，仍然有用户态和内核态的数据拷贝。说白了，poll只是把select的「数组」换成了「链表」，核心问题没解决。

我个人的看法是：poll适合连接数不多（几百个以内）的场景。如果你只是写个简单的聊天室或者小工具，poll完全够用。但要做高并发服务器，还是得看epoll。

epoll：Linux下的王者

epoll是Linux特有的IO多路复用机制，它彻底解决了select和poll的性能问题。它的核心思想是：事件驱动，回调通知。

epoll有三个关键函数：

int epoll_create(int size);  // 创建epoll实例
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);  // 注册/修改/删除fd
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);  // 等待事件

epoll为什么快？

  • O(1)的事件通知：只返回就绪的fd，不需要遍历全部
  • mmap共享内存：内核和用户态共享一块内存，避免了数据拷贝
  • 红黑树管理fd：增删改查都是O(log n)，比select的数组和poll的链表快得多
  • 边缘触发（ET）和水平触发（LT）：提供了更灵活的事件处理模式

个人经验：我建议新手先用水平触发（LT），它更安全，不容易漏事件。边缘触发（ET）效率更高，但需要配合非阻塞IO和循环读取，否则容易丢数据。我刚开始用ET时，就因为没读完数据导致客户端一直等响应，排查了半天。

三种机制的对比

特性 select poll epoll
最大fd数 1024（可调） 无上限 无上限
遍历方式 全部遍历 全部遍历 只返回就绪的
数据拷贝 每次拷贝全部 每次拷贝全部 mmap共享内存
触发模式 水平触发 水平触发 水平+边缘触发
跨平台 几乎所有平台 几乎所有平台 仅Linux
适用场景 连接数少，简单场景 连接数中等 高并发，大量连接

一个简单的epoll服务器骨架

下面是一个用epoll实现的TCP服务器核心代码。嗯，这里只展示关键部分，完整的错误处理和生产级代码会更复杂。

#include <sys/epoll.h>
#include <unistd.h>
#include <fcntl.h>

#define MAX_EVENTS 1024
#define PORT 8080

int main() {
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    // ... bind, listen ...

    // 创建epoll实例
    int epoll_fd = epoll_create1(0);
    
    // 注册监听fd
    struct epoll_event ev;
    ev.events = EPOLLIN;
    ev.data.fd = listen_fd;
    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev);

    struct epoll_event events[MAX_EVENTS];
    
    while (1) {
        int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        
        for (int i = 0; i < nfds; i++) {
            if (events[i].data.fd == listen_fd) {
                // 新连接来了
                int conn_fd = accept(listen_fd, NULL, NULL);
                // 设置为非阻塞
                fcntl(conn_fd, F_SETFL, O_NONBLOCK);
                // 注册到epoll
                ev.events = EPOLLIN | EPOLLET;  // 边缘触发
                ev.data.fd = conn_fd;
                epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, &ev);
            } else {
                // 处理客户端数据
                handle_client(events[i].data.fd);
            }
        }
    }
    
    close(epoll_fd);
    close(listen_fd);
    return 0;
}

注意：使用边缘触发（EPOLLET）时，一定要把fd设置为非阻塞。否则如果数据没读完，epoll不会再通知你，导致数据丢失。我见过不少新手在这里栽跟头。

高并发服务器的设计要点

有了epoll，是不是就能轻松写出高并发服务器了？没那么简单。epoll只是工具，真正的挑战在于如何用好它。

我总结了几点经验：

  • 非阻塞IO是必须的：epoll配合非阻塞IO，才能发挥最大效率
  • 合理使用线程池：epoll负责事件分发，具体的业务逻辑交给线程池处理
  • 注意内存管理：每个连接都有缓冲区，要设计好内存池，避免频繁malloc/free
  • 超时处理：用定时器管理空闲连接，防止资源泄漏
  • 惊群问题：多个线程同时epoll_wait同一个fd时，只有一个能成功。可以用EPOLLEXCLUSIVE标志解决

我记得有一次优化一个网关服务器，原来的实现是每个连接一个线程，撑到1000连接就卡死了。改成epoll+线程池后，同样的硬件跑了5000连接，CPU占用率还降了20%。

知识体系图

下面这张图展示了IO多路复用的核心知识结构，从基础概念到具体实现，再到高并发设计：

IO多路复用知识体系 IO多路复用 select poll epoll 特点 • 最大1024个fd • 全部遍历，O(n) 特点 • 无fd上限 • 全部遍历，O(n) 特点 • 事件驱动，O(1) • mmap共享内存 高并发服务器设计 非阻塞IO + 线程池 + 内存池 + 定时器 ⚠ 注意：边缘触发需非阻塞IO，惊群问题需EPOLLEXCLUSIVE

总结

select、poll、epoll这三兄弟，代表了IO多路复用技术的演进历程。select简单但有限制，poll改进了限制但没解决性能问题，epoll才是Linux高并发场景下的正确选择。

我个人建议：

  • 写跨平台程序或连接数很少时，用select
  • 连接数几百个，且不需要极致性能时，用poll
  • 做高并发服务器，尤其是上千连接时，必须用epoll

最后说一句：工具再好，也要会用。epoll本身不难，难的是如何设计好整个服务器的架构——内存怎么管理、线程怎么分配、超时怎么处理、协议怎么解析。这些才是真正考验功力的地方。

一句话总结：IO多路复用是「一个线程等多个IO」的技术，epoll是Linux下的最优解，但用好它需要理解事件驱动、非阻塞IO和并发设计。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →