select、poll 和 epoll

我来用最直观的方式解析 select、poll 和 epoll 这三代 I/O 多路复用技术，结合生活案例和底层原理，让你彻底明白它们的差异和演进逻辑。

先看生活化比喻：快递站取快递

想象你是一个快递站管理员，要处理大量包裹（网络请求）：

• select/poll：你站在货架前，逐个检查每个包裹（文件描述符）是否有人来取。即使只有1个包裹待取，你也要检查所有货架。

• epoll：每个包裹绑定一个提醒器。当有人取包裹时，提醒器自动响铃，你只需要处理响铃的包裹。

💡 核心矛盾：如何高效知道“哪些快递被取走”（哪些fd就绪）？

一、select：初代轮询监控器

1. 工作流程

c

fd_set read_fds;  // 创建监控集合
FD_ZERO(&read_fds);
FD_SET(sock1, &read_fds);  // 添加sock1
FD_SET(sock2, &read_fds);  // 添加sock2while(1) {fd_set tmp = read_fds;  // 必须复制（select会破坏原集合）int ret = select(max_fd+1, &tmp, NULL, NULL, NULL);  // 阻塞等待if (FD_ISSET(sock1, &tmp)) {  // 检查sock1是否就绪recv(sock1, buf, sizeof(buf), 0);  // 读取数据}if (FD_ISSET(sock2, &tmp)) {// 处理sock2...}
}

2. 底层原理

• 数据结构：位图（bitmap），长度固定（通常1024位）

• 内核操作：

  1. 将fd_set从用户态拷贝到内核态

  2. 线性扫描所有fd（0~max_fd），检查是否就绪

  3. 将就绪fd集合拷贝回用户态

  4. 用户再次线性扫描所有fd，找出就绪项

3. 致命缺陷

二、poll：改进的轮询器

1. 工作流程

c

struct pollfd fds[2];
fds[0].fd = sock1; fds[0].events = POLLIN;  // 监控读事件
fds[1].fd = sock2; fds[1].events = POLLIN;while(1) {int ret = poll(fds, 2, -1);  // 阻塞等待for(int i=0; i<2; i++) {if (fds[i].revents & POLLIN) {  // 直接遍历检查// 处理就绪的fds[i].fd}}
}

2. 底层优化

• 数据结构：pollfd结构体数组（突破数量限制），链表  

  c

  struct pollfd {int fd;         // 文件描述符short events;   // 监控的事件（输入）short revents;  // 返回的事件（输出）
  };

• 内核操作：

  1. 拷贝pollfd数组到内核

  2. 线性扫描所有fd

  3. 拷贝回用户态

  4. 用户遍历数组检查revents

3. 进步与局限

三、epoll：事件驱动的王者

1. 核心工作流

c

int epfd = epoll_create1(0);  // 创建epoll实例struct epoll_event ev, events[10];
ev.events = EPOLLIN;          // 监控读事件
ev.data.fd = sock1;           // 携带自定义数据
epoll_ctl(epfd, EPOLL_CTL_ADD, sock1, &ev);  // 注册sock1ev.data.fd = sock2;
epoll_ctl(epfd, EPOLL_CTL_ADD, sock2, &ev);  // 注册sock2while(1) {// 等待事件就绪（只返回就绪的fd）int n = epoll_wait(epfd, events, 10, -1);  for(int i=0; i<n; i++) {  // n是就绪数量，直接处理int fd = events[i].data.fd;recv(fd, buf, sizeof(buf), 0);}
}

2. 底层架构（三大组件）

plaintext

┌──────────────┐       ┌──────────────┐       ┌──────────────┐
│  红黑树       │       │  就绪队列     │       │  回调函数     │
│ (存储所有fd)  │◄─────│ (存放就绪fd) │◄─────│ (事件触发时   │
└──────────────┘       └──────────────┘       │ 自动填充队列) │▲                                      └──────────────┘│           epoll_wait()│          ┌───────────┐
用户调用 │          ▼           │
epoll_ctl()   ┌──────────────┐  │└─────►│  epoll实例    │──┘└──────────────┘

3. 核心优势

四、性能对比实验（100万连接）

1. CPU占用对比

2. 响应延迟对比（1000并发）

📈 数据来源：Cloudflare 生产环境测试报告

五、触发模式详解

1. 水平触发（LT）

c

ev.events = EPOLLIN;  // 默认模式（LT）

• 行为：只要fd还有数据可读，每次epoll_wait都返回

• 优点：编程简单，不易遗漏事件

• 场景：传统网络编程

2. 边缘触发（ET）

c

ev.events = EPOLLIN | EPOLLET;  // 启用ET模式

• 行为：仅当fd状态从无数据变为有数据时触发一次

• 要求：

  • 必须非阻塞读取（直到EAGAIN）

  • 必须一次性处理完所有数据

• 优势：减少系统调用次数

• 案例：Nginx、Redis高性能场景

c

// ET模式正确读取方式
while (true) {ssize_t count = read(fd, buf, BUF_SIZE);if (count == -1) {if (errno == EAGAIN) break; // 数据读完else { /* 处理错误 */ }}// 处理数据...
}

六、适用场景选择指南

七、内核实现差异图解

plaintext

select/poll 内核流程：用户调用│▼复制fd集合到内核│▼┌───────────┐│ 遍历所有fd │←─── 性能瓶颈！└───────────┘│▼标记就绪fd│▼复制结果回用户epoll 内核流程：用户注册fd│▼┌────────────┐│ 加入红黑树 │└────────────┘│▼设备驱动触发回调 ◄── 网卡数据到达时触发│▼┌────────────┐│ 加入就绪队列│└────────────┘│用户调用epoll_wait│▼返回就绪队列内容

八、历史演进总结

💎 终极结论：

• <1000连接：select/poll够用

• >10000连接：必须epoll

• 极致性能：epoll + 边缘触发 + 非阻塞IO

• 未来方向：io_uring（Linux 5.1+）