写网络编程绕不开这三个字I/O多路复用。而在 Linux 下聊 I/O 多路复用select和poll是绕不开的两个老古董。很多人刚开始看这两兄弟觉得 API 很简单一查文档也就几个函数但真到写代码、调 bug、看性能的时候才发现里面藏着不少门道。网上介绍这俩机制的文章不少但大多停留在“select 有 1024 限制、poll 解决了”这种表面层次。今天我从一个常年跟并发连接打交道的开发者视角把这两个机制掰开揉碎讲清楚底层数据结构长什么样、内核帮你干了什么、坑在哪里、什么场景选谁最后还会给一套能直接跑起来参考的核心逻辑框架。这套内容适合刚入门网络编程的初学者也适合写过几年业务代码但没仔细抠过底层的开发者。搞清楚 select 和 poll你才能更深刻地理解 epoll 为什么后来者居上也才能在面对“能不能用 select 撑住一万个连接”这类问题时给出有理有据的判断而不是拍脑袋。1. 整体设计与思路拆解为什么要用 I/O 多路复用select 和 poll 在解决什么问题2. select 机制核心细节fd_set 位图、超时参数、三类事件与三大坑3. poll 机制核心细节pollfd 数组、事件掩码、改进与遗留问题4. 完整实操两个机制分别实现简易 TCP 回显服务5. 两者的量化对比与选型建议6. 常见问题与排查技巧实录1. 整体设计与思路拆解为什么要用 I/O 多路复用select 和 poll 在解决什么问题1.1 从阻塞 I/O 说起为什么并发连接会让新手崩溃假设你要写一个服务器最朴素的想法是 accept 一个连接就创建一个线程去处理。这个方案的代码确实好写早期很多项目也真这么干。但它有两个绕不开的痛点一是线程是有成本的创建、切换、销毁都消耗资源一个线程默认栈空间就有 8MB虽然是虚拟内存一万个并发连接共用一个进程、一个线程去逐个等待数据你加再多线程也只是把问题往后拖。这时 I/O 多路复用就登场了。核心思想一句话让内核替我们监视一堆连接哪个连接有数据来了内核告诉用户程序用户程序再统一处理“这些有事件的连接”。select 和 poll 就是内核向用户态提供的两种“监视员”接口。1.2 婴儿期的多路复用select 的设计初衷select 诞生得特别早从 4.2BSD 时代就有了距今超过四十年。设计者当时的思路是用户程序先把需要监视的文件描述符放进一个叫fd_set的结构里然后调用 select 告诉内核“你帮我盯着这些人”内核把有事件的描述符标记出来用户程序再遍历所有描述符逐个检查。这个把描述符集合交给内核、再拿回来检查的交互方式奠定了 select 的 API 形态每次调用前要设置集合调用后集合会被内核改写你无法知道具体是哪个描述符触发了事件只能全部检查一遍。这套交互一直延续到今天理解它才算理解了 select 的骨子里带着的缺点。1.3 poll 的出场换数据结构继承轮询思想poll 出现在 System V 时代属于后代对 select 缺点的第一次矫正。开发者发现 fd_set 位图结构有上限于是把fd_set换成了struct pollfd数组——数组有多大你说了算不再有硬编码上限还把“输入事件”和“输出事件”拆开放在events和revents两个字段里内核不会改你的输入字段每次调用不用重新初始化整张表。但注意poll 的核心思想没变把一堆描述符交给内核内核把有事件的描述符标记好用户程序遍历数组检查revents。这个线性扫描、全部检查的流程和 select 一模一样。所以从设计哲学上讲poll 只是改良不是革命。1.4 为什么会有 epoll 的诞生把 select/poll 的调用流程拉出来看你会发现两个反复出现的成本每次调用都要把整个描述符集合从用户态拷贝到内核态内核要遍历整个集合找出就绪的描述符返回后用户程序还要再遍历一遍找出处理哪些连接。这三个遍历加起来复杂度是 O(n) 起步连接数一上来时间和 CPU 都烧得厉害。epoll 之所以是革命性的是因为它把“帮你盯着哪些连接”这个任务持续保留在内核里用户只需把自己关心的连接加进去一次然后等待“哪些连接有事件”的通知省掉了反复全量拷贝和全量扫描。这部分不多展开但理解了 select/poll 的痛点在哪儿就自然懂 epoll 为什么是那个样子。2. select 机制核心细节fd_set 位图、超时参数、三类事件与三大坑2.1 fd_set一个位图搞定一切先看最核心的fd_set结构。在 Linux 上它其实是一个位图bitmap每个 bit 对应一个文件描述符。比如 fd5就对应位图里第 5 个 bit。位图大小由内核宏FD_SETSIZE决定几乎所有的 Linux 发行版里都是 1024。这意味着 fd 编号从 0 到 1023 之间有对应的 bitfd 超过 1023 就是未定义行为不报错但你没法可靠地监视它。这就是大家常说的select 有 1024 限制的由来。用户程序操作位图全靠四个宏你只要记住口诀清零、设置、清除、测试就够了FD_ZERO(fds); // 把整个位图清零相当于清空监视名单 FD_SET(fd, fds); // 把 fd 加入监视名单 FD_CLR(fd, fds); // 把 fd 从监视名单移除 FD_ISSET(fd, fds); // 查询 fd 是否有事件就绪这四个宏的行为藏在 glibc 的内部实现里本质上就是位运算。FD_SET 就是把对应 bit 置 1FD_ISSET 就是读对应 bit。需要注意FD_SET和FD_CLR是宏参数里的 fds 必须是可以修改的左值。2.2 三类事件读、写、异常分三个集合select 和后来者的最大区别之一是把事件拆成了三组独立的集合readfds可读、writefds可写、exceptfds异常。int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);实际开发中readfds 用来监听新连接到达监听套接字可读和已有连接的数据到达连接套接字可读writefds 用法稍微绕一些它不表示“现在就能写”而是“现在写不会阻塞”。这个语义差别很多人理解偏了注意select 返回可写的时候对端缓冲区可能依然很小你依然要考虑写部分数据后的处理逻辑。exceptfds 是用来监视带外数据OOB或某些错误条件的实际业务场景中用得很少入门阶段完全可以先忽略传入 NULL 即可。2.3 nfds 参数不是描述符个数是最大编号 1第三个参数很多人会写错。nfds不是描述符的个数而是所有你监视的描述符里最大编号加 1。原因很简单内核检查位图时是从 bit 0 一直扫到位图结尾它不需要知道总共有几个描述符只需要知道最大扫到哪里就可以提前停下。你说帮我扫到 1023内核就扫到 1023你说帮我扫到 512内核扫到 512 就收工少扫一半。实际写的时候用一个 max_fd 变量实时维护。每次新增一个 fd就if (fd max_fd) max_fd fd;调用 select 时传入max_fd 1。这个细节虽然小但直接影响 select 的扫描范围连接数大的时候能省出不少内核时间。2.4 timeout 参数三种状态且会被内核修改timeout 是个struct timeval注意它真的是会变的。内核在 select 返回前会把它改成剩余时间。所以如果你用一个全局 timeval 反复调用 select第二次调用时看到的可能不是 3 秒而是 2.7 秒连续几次就变成负数了。标准做法是每次循环里重新填充 timeval或者在调用前复制一份。timeout 的三种取值分别对应三种行为传 NULL永远等待直到监视的 fd 中至少一个就绪或被信号打断传全 0 的 timeval完全不等待立即检查一遍后返回这就是非阻塞轮询模式传非零 timeval最多等待这么多时间超时未就绪就返回 0。返回值也好记大于 0 表示就绪的描述符总数等于 0 表示超时小于 0 表示出错比如被信号打断errno 为 EINTR。2.5 三大坑能写错一遍绝不只错一遍第一个坑fd_set 被子核修改后不能复用。select 返回时内核会把没有事件的 fd 对应的 bit 清零只保留就绪的 bit。这意味着你下一次调用之前必须重新把所有要监视的 fd 全部 FD_SET 一遍。很多人都栽在这第一次循环好好的第二次循环发现怎么啥事件都没有检查半天没发现问题其实就是在调 select 前忘记了重建 fd_set。第二个坑监听套接字的处理。select 返回可读不代表有数据可 recv。如果可读的是监听套接字应该立即 accept把新连接 fd 加入集合如果是已连接套接字可读再 recv 数据。这两件事不能混着写。第三个坑EINTR 信号打断。select 是慢系统调用被信号打断后会返回 -1errno 置为 EINTR。很多新手看到 -1 就当出错直接退出进程。正确的姿势是判断errno EINTR就继续循环重新调用 select。从 Linux 2.6 开始系统调用不会因为信号而自动重启这个判断必须你亲手加。3. poll 机制核心细节pollfd 数组、事件掩码、改进与遗留问题3.1 pollfd 数组没有上限但你需要自己维护poll 把 select 的三个集合压进了一个数组每个元素是一个struct pollfdstruct pollfd { int fd; // 要监视的描述符 short events; // 你关心哪些事件输入参数 short revents; // 哪些事件真的发生了内核填入 };数组大小由你自己决定存多少个 fd 都行没有硬编码的 1024 限制。但它要求你把 fd 管理好数组满了你得扩容fd 关闭了你要从数组里移除或者把 fd 设为 -1。poll 遇到 fd 为 -1 的元素会直接忽略不会报错这倒是给了我们一个便利删除描述符时不用挪动数组直接把 fd 置 -1 就行等下一次批量清理。3.2 事件掩码常用事件就这些events 和 revents 是位掩码你按位或组合事件。日常开发最常用的这么几个事件含义使用建议POLLIN有数据可读包括对端关闭连接必须关注POLLOUT可写写不会阻塞需要时关注POLLERR发生错误不用主动请求内核总会填POLLHUP对端挂断不用主动请求内核总会填POLLNVALfd 未打开或非法不用主动请求内核总会填有个很容易踩的细节对端关闭连接时poll 可能同时返回 POLLIN 和 POLLHUP。POLLIN 触发了你去 read读到 0 字节表示对端关闭这时候才能确定要关闭这个连接。只用 POLLHUP 判断连接断开是不对的因为有的协议栈行为下数据还没读完就可能先看到 POLLIN POLLHUP。3.3 revents 的设计优势数据分离调用更省心revents 这个字段是 poll 对 select 的重要改良。select 的 fd_set 是输入输出公用一块内存内核会改掉它所以你得每次重建poll 把 events 和 revents 分开内核只写 revents不改 events。于是你可以在循环外初始化好整个数组的 events循环内反复调用 poll不用每次重建。这个特性在写长时间运行的服务器时非常舒服少了一整类集合被改的 bug。3.4 poll 的时间参数精度更高但没有绝对时间poll 用int timeout替代了struct timeval单位是毫秒。传负数表示无限期等待传 0 表示立即返回同样非阻塞轮询模式传正数就是最多等多少毫秒。精度比 select 的 timeval微秒弱但对网络事件这级别来说完全够用。别忘了 select 那个剩余时间覆盖的问题poll 没有timeout 不会被内核改写第二次调用不用重新赋值。3.5 poll 的遗留问题O(n) 的宿命poll 解决了 select 最被吐槽的 1024 限制和事件重置问题但它没有解决最核心的 O(n) 扫描问题。每次调用 poll内核都要遍历你传进去的整个数组找出就绪的 fd返回后用户程序又把整个数组遍历一遍检查每个 revents。两个 O(n) 固定开销摆在这里fd 数量在几千个以内时这种开销基本无感一旦上到几万即使是 poll 也会喘不过气。另一个隐藏问题是内存拷贝整个 pollfd 数组每次调用都要从用户态拷贝到内核态数组越大这个拷贝越贵。这个问题 select 也有而且因为 fd_set 是位图结构即便你只监视 3 个 fd内核扫描位图的范围仍可能到 1024 位。所以说两个老家伙在规模变大这条路上天花板都很明显。4. 完整实操两个机制分别实现简易 TCP 回显服务4.1 场景设定与设计约束用一个经典场景单进程 TCP 回显服务器客户端连接后发送什么服务器原样返回什么。要求同时支持多个客户端连接不阻塞在某个客户端上。为了对比 select 和 poll 的写法差异分别实现两个版本代码逻辑完全一致只有多路复用那一层的 API 不同。先定几个通用的代码片段后面两个版本共用。创建监听套接字的代码网络上到处都是基本步骤是socket()、设置 SO_REUSEADDR、bind()、listen()。监听 fd 设为非阻塞避免 accept 时因为连接队列变化出现边缘情况下的阻塞。4.2 select 版本循环内重建 fd_set 是主旋律核心思路维护一个所有要监视的 fd 集合。每次循环开头把监听 fd 和所有客户端 fd 重新 FD_SET 进一个全新的 fd_set调用 select然后先查监听 fd再遍历所有客户端 fd。// 伪代码聚焦 select 关键用法 int max_fd listen_fd; fd_set master_set, read_set; FD_ZERO(master_set); FD_SET(listen_fd, master_set); while (1) { read_set master_set; // 复制一份因为 select 会修改 read_set int ret select(max_fd 1, read_set, NULL, NULL, NULL); if (ret 0) { if (errno EINTR) continue; perror(select); break; } if (ret 0) continue; // 超时这里传了 NULL 基本不会发生 if (FD_ISSET(listen_fd, read_set)) { int conn_fd accept(listen_fd, NULL, NULL); FD_SET(conn_fd, master_set); if (conn_fd max_fd) max_fd conn_fd; } for (int fd 0; fd max_fd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, read_set)) { char buf[1024]; ssize_t n recv(fd, buf, sizeof(buf), 0); if (n 0) { close(fd); FD_CLR(fd, master_set); } else { send(fd, buf, n, 0); } } } }注意几个细节read_set master_set这里必须用临时副本。select 会改动 read_set如果直接传 master_set下一次循环就找不到需要监视的 fd 了。fd 编号很大时for (int fd 0; fd max_fd; fd)这个遍历法很低效但你想想 fd 在操作系统里总是从小到大分配连接数不多时倒也没太大问题。想精细一些可以用一个数组自己维护活跃 fd 列表但那样代码复杂度会上升。4.3 poll 版本数组维护稍显繁琐但更直接poll 版本的代码思路更清晰初始化一个 pollfd 数组第一个元素放监听 fd后面的放客户端 fd。每次循环不需要重建数组的 events 字段因为内核不修改它只需要检查 revents。// 伪代码聚焦 poll 关键用法 struct pollfd fds[1024]; fds[0].fd listen_fd; fds[0].events POLLIN; int nfds 1; while (1) { int ret poll(fds, nfds, -1); if (ret 0) { if (errno EINTR) continue; perror(poll); break; } if (fds[0].revents POLLIN) { int conn_fd accept(listen_fd, NULL, NULL); fds[nfds].fd conn_fd; fds[nfds].events POLLIN; nfds; } for (int i 1; i nfds; i) { if (fds[i].fd 0) continue; if (fds[i].revents (POLLIN | POLLERR | POLLHUP)) { char buf[1024]; ssize_t n recv(fds[i].fd, buf, sizeof(buf), 0); if (n 0) { close(fds[i].fd); fds[i].fd -1; // 标记删除之后统一清理 } else { send(fds[i].fd, buf, n, 0); } } } }poll 版本的循环体清爽不少。事件判断用fds[i].revents (POLLIN | POLLERR | POLLHUP)这一条把所有需要处理的情况都抓进来因为不管是数据到达、对端挂断还是连接错误我们最终都是去 recv 一把看结果。数组用固定 1024 只是个示范真到项目里会把固定数组换成动态扩容的fd 多了就 realloc。4.4 两版对比差在哪一层跑起来你几乎感觉不到性能差异代码上 poll 版少了每次重建集合的动作但多了一套数组维护逻辑。select 版的for (int fd 0; fd max_fd; fd)其实也是在扫全量 fdpoll 版扫的是数组本质上没区别。真正有体感差异的是使用体验poll 不用处理fd_set 被内核改写的隐患也不怕 fd 编号超过 1023。我建议新项目直接用 poll除非你要兼容某些老掉牙的系统环境。4.5 关键坑accept 返回 -1 的分支两个版本里都要对 accept 加一层保护。试想select/poll 报告监听 fd 可读但 accept 时返回 -1常见原因是对端在连接建立前已经断开TCP 三次握手的连接队列里挤满了半连接此时 errno 往往是 ECONNABORTED 或 EMFILE。不做保护的话单次 accept 失败可能让主循环直接退出整个服务挂掉。标准处理是继续循环别让一个异常连接杀死整个进程。5. 两者的量化对比与选型建议5.1 一张表看清差异对比维度selectpoll数据结构fd_set 位图pollfd 数组描述符上限FD_SETSIZE默认 1024无硬上限受内存限制事件类型读、写、异常分成三个集合统一为 events/revents 位掩码输入输出分离否fd_set 被内核改写是内核只填 revents超时精度微秒timeval毫秒int遍历方式内核位图扫描 用户态全量遍历内核数组扫描 用户态全量遍历复杂度O(n)O(n)主要问题1024 上限、需要重建集合无上限但仍是线性扫描5.2 连接规模划分百级、千级、万级实测下来我的体感是这样的单进程管理一百个以内的连接select 和 poll 的差异你根本感知不到瓶颈通常在业务处理逻辑上。一千到三千个连接select 还行但前提是 fd 编号别太分散——如果有一堆接近 1023 的 fd内核被迫扫描整个位图时间开销就上来了。三千到一万个连接poll 能扛但 CPU 飙高select 因为 1024 上限直接出局。连接再多老老实实上 epoll否则就是浪费 CPU 在无意义的全量扫描上。5.3 跨平台场景select 的隐藏优势poll 只存在于 POSIX 系统Windows 上原生没有这接口。select 几乎所有操作系统都支持包括 Windows 的 winsock。所以如果你要写跨平台网络库select 几乎是最低公约数的必选项。很多跨平台库的做法是底层封装 select上层做出统一的 event loop 接口再根据平台能力切换不同实现。5.4 选型决策树先问自己三个问题目标平台是什么预计同时在线连接多少代码维护成本更在意哪个方向平台只考虑 Linux连接数在可控范围内用 poll 更舒服要兼容 Windows 或 macOS用 select连接数可能破万两个都不选直接用 epoll代码量不想太大、追求快出功能select 的 API 更简单资料也多但注意它的 1024 上限别成为定时炸弹。把这三个问题过一遍选择基本就清楚了。6. 常见问题与排查技巧实录6.1 现象 1select 循环跑几次后新连接 accept 不到了排查思路先把 fd_set 的填充代码打印出来对比每次循环开头和 select 返回后的 fd_set 内容大概率是 fd_set 没有重建。常见的错误写法是在循环外定义一次 fd_set循环内直接传给 select。select 返回后没有就绪的 fd 对应的 bit 会被清零下次循环时这个 fd 就消失在监视名单里。解决办法就是每次循环都用 master 副本重建 read_set。6.2 现象 2poll 返回 POLLIN读取时却 read 返回 0连接就该关闭了这不是 bug是 TCP 的正常行为。对端正常关闭时poll 的通知里会带 POLLIN 或 POLLHUP哪个先到不一定。read 返回 0 是唯一的、可靠的对端已关闭信号。判断逻辑应该做成这样只要 revents 里包含 POLLIN | POLLHUP | POLLERR 中的任何一个就执行 readread 结果决定后续动作。千万别只看到 POLLIN 就以为一定有数据可收。6.3 现象 3服务器退出了端口还占着重启报 address already in use用 select/poll 写服务器很容易忽略SO_REUSEADDR。开发调试期服务器进程经常被 CtrlC 杀掉但 TCP 连接可能处于 TIME_WAIT 状态如果没设置 REUSEADDR立刻重启就会 bind 失败提示端口被占用。这是新手最常碰到的莫名其妙问题之一。int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));加在 bind 之前老生常谈但每次都有人忘。6.4 现象 4程序卡死好像什么都没做CPU 却飙高先检查有没有把超时设成 0 又没处理好。select/poll 超时都是 0 时内核立即返回如果你的 while 循环里没有阻塞操作马上又进入下一轮 select这就变成了 busy loopCPU 瞬间打满。真实场景往往出现在超时时间由某个变量控制结果该变量在循环里被改成 0的情况。排查方法是打印每次循环的 timeout 值最好在循环里加个计数器确认每轮之间是否有过真实等待。6.5 现象 5连接数没到上限select 却报 EBADFEBADF 表示传递给 select 的 fd_set 里含有一个未打开的描述符。最常见的来源是客户端连接被关闭后你调用了 close(fd)但忘了把 fd 从 fd_set 里 FD_CLR。内核在扫描位图时发现 fd 不对直接返回错误。poll 的对应情况好一些fd 置为 -1 会跳过select 里没有跳过这个选项所以 close(fd) 和 FD_CLR(fd) 必须是一个原子操作。6.6 通用排查技巧小工具大用处调试 select/poll 程序有三个工具帮我省了无数时间。第一个是strace -p 进程号直接看系统调用情况能立刻确认 select 是不是被反复调用、超时值到底是啥第二个是ss -ant或netstat -ant看连接状态判断是不是客户端压根没发数据第三个是打日志在每次 select/poll 返回后打印一下就绪 fd 的数量和耗时粗粒度定位性能瓶颈。6.7 从 select/poll 到 epoll 的平滑迁移当你真的遇到上万连接时从 poll 迁到 epoll 是必然路径。两者的代码结构差异很大epoll 把添加到监视列表和等待事件拆成两个系统调用需要你维护一个当前活跃的事件数组。但迁移过程中很多哪些 fd 在什么条件下需要关注的逻辑是可以直接复用的。我的建议是先把 poll 版本写稳再加上一个 epoll 实现用同样的业务处理逻辑通过配置文件选底层机制。这样既能保留 select/poll 在低并发场景的优势又能在高并发时切换到 epoll 扛压。我在实际写网络服务时select 和 poll 这两个机制到现在也没完全离开我的工具箱。低配设备上、跨平台小工具里select 仍然是稳妥的选择poll 则是我日常写 Linux 原型代码的默认选项——代码结构清晰没有 1024 的暗雷调试起来比 select 省心太多。它们的确老了但你亲手把 fd_set 重建一遍、被 POLLHUP 坑过一次之后再去看 epoll 的 eventpoll 结构、红黑树和就绪链表才能真正理解事件驱动这四个字的分量。如果你正在琢磨自己的第一个多客户端服务器别急着上 epoll先拿 select 或 poll 把小流量场景跑通。把这两个老机制用熟你会更清楚网络编程里哪些开销是不可避免的、哪些是可以被优化的这种判断力比多背几个 API 有用得多。 
长河君 · 2026/10/19 4:49:30 · 阅读 1.2k select与poll深度解析：从原理到实战的I/O多路复用指南
写网络编程绕不开这三个字I/O多路复用。而在 Linux 下聊 I/O 多路复用select和poll是绕不开的两个老古董。很多人刚开始看这两兄弟觉得 API 很简单一查文档也就几个函数但真到写代码、调 bug、看性能的时候才发现里面藏着不少门道。网上介绍这俩机制的文章不少但大多停留在“select 有 1024 限制、poll 解决了”这种表面层次。今天我从一个常年跟并发连接打交道的开发者视角把这两个机制掰开揉碎讲清楚底层数据结构长什么样、内核帮你干了什么、坑在哪里、什么场景选谁最后还会给一套能直接跑起来参考的核心逻辑框架。这套内容适合刚入门网络编程的初学者也适合写过几年业务代码但没仔细抠过底层的开发者。搞清楚 select 和 poll你才能更深刻地理解 epoll 为什么后来者居上也才能在面对“能不能用 select 撑住一万个连接”这类问题时给出有理有据的判断而不是拍脑袋。1. 整体设计与思路拆解为什么要用 I/O 多路复用select 和 poll 在解决什么问题2. select 机制核心细节fd_set 位图、超时参数、三类事件与三大坑3. poll 机制核心细节pollfd 数组、事件掩码、改进与遗留问题4. 完整实操两个机制分别实现简易 TCP 回显服务5. 两者的量化对比与选型建议6. 常见问题与排查技巧实录1. 整体设计与思路拆解为什么要用 I/O 多路复用select 和 poll 在解决什么问题1.1 从阻塞 I/O 说起为什么并发连接会让新手崩溃假设你要写一个服务器最朴素的想法是 accept 一个连接就创建一个线程去处理。这个方案的代码确实好写早期很多项目也真这么干。但它有两个绕不开的痛点一是线程是有成本的创建、切换、销毁都消耗资源一个线程默认栈空间就有 8MB虽然是虚拟内存一万个并发连接共用一个进程、一个线程去逐个等待数据你加再多线程也只是把问题往后拖。这时 I/O 多路复用就登场了。核心思想一句话让内核替我们监视一堆连接哪个连接有数据来了内核告诉用户程序用户程序再统一处理“这些有事件的连接”。select 和 poll 就是内核向用户态提供的两种“监视员”接口。1.2 婴儿期的多路复用select 的设计初衷select 诞生得特别早从 4.2BSD 时代就有了距今超过四十年。设计者当时的思路是用户程序先把需要监视的文件描述符放进一个叫fd_set的结构里然后调用 select 告诉内核“你帮我盯着这些人”内核把有事件的描述符标记出来用户程序再遍历所有描述符逐个检查。这个把描述符集合交给内核、再拿回来检查的交互方式奠定了 select 的 API 形态每次调用前要设置集合调用后集合会被内核改写你无法知道具体是哪个描述符触发了事件只能全部检查一遍。这套交互一直延续到今天理解它才算理解了 select 的骨子里带着的缺点。1.3 poll 的出场换数据结构继承轮询思想poll 出现在 System V 时代属于后代对 select 缺点的第一次矫正。开发者发现 fd_set 位图结构有上限于是把fd_set换成了struct pollfd数组——数组有多大你说了算不再有硬编码上限还把“输入事件”和“输出事件”拆开放在events和revents两个字段里内核不会改你的输入字段每次调用不用重新初始化整张表。但注意poll 的核心思想没变把一堆描述符交给内核内核把有事件的描述符标记好用户程序遍历数组检查revents。这个线性扫描、全部检查的流程和 select 一模一样。所以从设计哲学上讲poll 只是改良不是革命。1.4 为什么会有 epoll 的诞生把 select/poll 的调用流程拉出来看你会发现两个反复出现的成本每次调用都要把整个描述符集合从用户态拷贝到内核态内核要遍历整个集合找出就绪的描述符返回后用户程序还要再遍历一遍找出处理哪些连接。这三个遍历加起来复杂度是 O(n) 起步连接数一上来时间和 CPU 都烧得厉害。epoll 之所以是革命性的是因为它把“帮你盯着哪些连接”这个任务持续保留在内核里用户只需把自己关心的连接加进去一次然后等待“哪些连接有事件”的通知省掉了反复全量拷贝和全量扫描。这部分不多展开但理解了 select/poll 的痛点在哪儿就自然懂 epoll 为什么是那个样子。2. select 机制核心细节fd_set 位图、超时参数、三类事件与三大坑2.1 fd_set一个位图搞定一切先看最核心的fd_set结构。在 Linux 上它其实是一个位图bitmap每个 bit 对应一个文件描述符。比如 fd5就对应位图里第 5 个 bit。位图大小由内核宏FD_SETSIZE决定几乎所有的 Linux 发行版里都是 1024。这意味着 fd 编号从 0 到 1023 之间有对应的 bitfd 超过 1023 就是未定义行为不报错但你没法可靠地监视它。这就是大家常说的select 有 1024 限制的由来。用户程序操作位图全靠四个宏你只要记住口诀清零、设置、清除、测试就够了FD_ZERO(fds); // 把整个位图清零相当于清空监视名单 FD_SET(fd, fds); // 把 fd 加入监视名单 FD_CLR(fd, fds); // 把 fd 从监视名单移除 FD_ISSET(fd, fds); // 查询 fd 是否有事件就绪这四个宏的行为藏在 glibc 的内部实现里本质上就是位运算。FD_SET 就是把对应 bit 置 1FD_ISSET 就是读对应 bit。需要注意FD_SET和FD_CLR是宏参数里的 fds 必须是可以修改的左值。2.2 三类事件读、写、异常分三个集合select 和后来者的最大区别之一是把事件拆成了三组独立的集合readfds可读、writefds可写、exceptfds异常。int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);实际开发中readfds 用来监听新连接到达监听套接字可读和已有连接的数据到达连接套接字可读writefds 用法稍微绕一些它不表示“现在就能写”而是“现在写不会阻塞”。这个语义差别很多人理解偏了注意select 返回可写的时候对端缓冲区可能依然很小你依然要考虑写部分数据后的处理逻辑。exceptfds 是用来监视带外数据OOB或某些错误条件的实际业务场景中用得很少入门阶段完全可以先忽略传入 NULL 即可。2.3 nfds 参数不是描述符个数是最大编号 1第三个参数很多人会写错。nfds不是描述符的个数而是所有你监视的描述符里最大编号加 1。原因很简单内核检查位图时是从 bit 0 一直扫到位图结尾它不需要知道总共有几个描述符只需要知道最大扫到哪里就可以提前停下。你说帮我扫到 1023内核就扫到 1023你说帮我扫到 512内核扫到 512 就收工少扫一半。实际写的时候用一个 max_fd 变量实时维护。每次新增一个 fd就if (fd max_fd) max_fd fd;调用 select 时传入max_fd 1。这个细节虽然小但直接影响 select 的扫描范围连接数大的时候能省出不少内核时间。2.4 timeout 参数三种状态且会被内核修改timeout 是个struct timeval注意它真的是会变的。内核在 select 返回前会把它改成剩余时间。所以如果你用一个全局 timeval 反复调用 select第二次调用时看到的可能不是 3 秒而是 2.7 秒连续几次就变成负数了。标准做法是每次循环里重新填充 timeval或者在调用前复制一份。timeout 的三种取值分别对应三种行为传 NULL永远等待直到监视的 fd 中至少一个就绪或被信号打断传全 0 的 timeval完全不等待立即检查一遍后返回这就是非阻塞轮询模式传非零 timeval最多等待这么多时间超时未就绪就返回 0。返回值也好记大于 0 表示就绪的描述符总数等于 0 表示超时小于 0 表示出错比如被信号打断errno 为 EINTR。2.5 三大坑能写错一遍绝不只错一遍第一个坑fd_set 被子核修改后不能复用。select 返回时内核会把没有事件的 fd 对应的 bit 清零只保留就绪的 bit。这意味着你下一次调用之前必须重新把所有要监视的 fd 全部 FD_SET 一遍。很多人都栽在这第一次循环好好的第二次循环发现怎么啥事件都没有检查半天没发现问题其实就是在调 select 前忘记了重建 fd_set。第二个坑监听套接字的处理。select 返回可读不代表有数据可 recv。如果可读的是监听套接字应该立即 accept把新连接 fd 加入集合如果是已连接套接字可读再 recv 数据。这两件事不能混着写。第三个坑EINTR 信号打断。select 是慢系统调用被信号打断后会返回 -1errno 置为 EINTR。很多新手看到 -1 就当出错直接退出进程。正确的姿势是判断errno EINTR就继续循环重新调用 select。从 Linux 2.6 开始系统调用不会因为信号而自动重启这个判断必须你亲手加。3. poll 机制核心细节pollfd 数组、事件掩码、改进与遗留问题3.1 pollfd 数组没有上限但你需要自己维护poll 把 select 的三个集合压进了一个数组每个元素是一个struct pollfdstruct pollfd { int fd; // 要监视的描述符 short events; // 你关心哪些事件输入参数 short revents; // 哪些事件真的发生了内核填入 };数组大小由你自己决定存多少个 fd 都行没有硬编码的 1024 限制。但它要求你把 fd 管理好数组满了你得扩容fd 关闭了你要从数组里移除或者把 fd 设为 -1。poll 遇到 fd 为 -1 的元素会直接忽略不会报错这倒是给了我们一个便利删除描述符时不用挪动数组直接把 fd 置 -1 就行等下一次批量清理。3.2 事件掩码常用事件就这些events 和 revents 是位掩码你按位或组合事件。日常开发最常用的这么几个事件含义使用建议POLLIN有数据可读包括对端关闭连接必须关注POLLOUT可写写不会阻塞需要时关注POLLERR发生错误不用主动请求内核总会填POLLHUP对端挂断不用主动请求内核总会填POLLNVALfd 未打开或非法不用主动请求内核总会填有个很容易踩的细节对端关闭连接时poll 可能同时返回 POLLIN 和 POLLHUP。POLLIN 触发了你去 read读到 0 字节表示对端关闭这时候才能确定要关闭这个连接。只用 POLLHUP 判断连接断开是不对的因为有的协议栈行为下数据还没读完就可能先看到 POLLIN POLLHUP。3.3 revents 的设计优势数据分离调用更省心revents 这个字段是 poll 对 select 的重要改良。select 的 fd_set 是输入输出公用一块内存内核会改掉它所以你得每次重建poll 把 events 和 revents 分开内核只写 revents不改 events。于是你可以在循环外初始化好整个数组的 events循环内反复调用 poll不用每次重建。这个特性在写长时间运行的服务器时非常舒服少了一整类集合被改的 bug。3.4 poll 的时间参数精度更高但没有绝对时间poll 用int timeout替代了struct timeval单位是毫秒。传负数表示无限期等待传 0 表示立即返回同样非阻塞轮询模式传正数就是最多等多少毫秒。精度比 select 的 timeval微秒弱但对网络事件这级别来说完全够用。别忘了 select 那个剩余时间覆盖的问题poll 没有timeout 不会被内核改写第二次调用不用重新赋值。3.5 poll 的遗留问题O(n) 的宿命poll 解决了 select 最被吐槽的 1024 限制和事件重置问题但它没有解决最核心的 O(n) 扫描问题。每次调用 poll内核都要遍历你传进去的整个数组找出就绪的 fd返回后用户程序又把整个数组遍历一遍检查每个 revents。两个 O(n) 固定开销摆在这里fd 数量在几千个以内时这种开销基本无感一旦上到几万即使是 poll 也会喘不过气。另一个隐藏问题是内存拷贝整个 pollfd 数组每次调用都要从用户态拷贝到内核态数组越大这个拷贝越贵。这个问题 select 也有而且因为 fd_set 是位图结构即便你只监视 3 个 fd内核扫描位图的范围仍可能到 1024 位。所以说两个老家伙在规模变大这条路上天花板都很明显。4. 完整实操两个机制分别实现简易 TCP 回显服务4.1 场景设定与设计约束用一个经典场景单进程 TCP 回显服务器客户端连接后发送什么服务器原样返回什么。要求同时支持多个客户端连接不阻塞在某个客户端上。为了对比 select 和 poll 的写法差异分别实现两个版本代码逻辑完全一致只有多路复用那一层的 API 不同。先定几个通用的代码片段后面两个版本共用。创建监听套接字的代码网络上到处都是基本步骤是socket()、设置 SO_REUSEADDR、bind()、listen()。监听 fd 设为非阻塞避免 accept 时因为连接队列变化出现边缘情况下的阻塞。4.2 select 版本循环内重建 fd_set 是主旋律核心思路维护一个所有要监视的 fd 集合。每次循环开头把监听 fd 和所有客户端 fd 重新 FD_SET 进一个全新的 fd_set调用 select然后先查监听 fd再遍历所有客户端 fd。// 伪代码聚焦 select 关键用法 int max_fd listen_fd; fd_set master_set, read_set; FD_ZERO(master_set); FD_SET(listen_fd, master_set); while (1) { read_set master_set; // 复制一份因为 select 会修改 read_set int ret select(max_fd 1, read_set, NULL, NULL, NULL); if (ret 0) { if (errno EINTR) continue; perror(select); break; } if (ret 0) continue; // 超时这里传了 NULL 基本不会发生 if (FD_ISSET(listen_fd, read_set)) { int conn_fd accept(listen_fd, NULL, NULL); FD_SET(conn_fd, master_set); if (conn_fd max_fd) max_fd conn_fd; } for (int fd 0; fd max_fd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, read_set)) { char buf[1024]; ssize_t n recv(fd, buf, sizeof(buf), 0); if (n 0) { close(fd); FD_CLR(fd, master_set); } else { send(fd, buf, n, 0); } } } }注意几个细节read_set master_set这里必须用临时副本。select 会改动 read_set如果直接传 master_set下一次循环就找不到需要监视的 fd 了。fd 编号很大时for (int fd 0; fd max_fd; fd)这个遍历法很低效但你想想 fd 在操作系统里总是从小到大分配连接数不多时倒也没太大问题。想精细一些可以用一个数组自己维护活跃 fd 列表但那样代码复杂度会上升。4.3 poll 版本数组维护稍显繁琐但更直接poll 版本的代码思路更清晰初始化一个 pollfd 数组第一个元素放监听 fd后面的放客户端 fd。每次循环不需要重建数组的 events 字段因为内核不修改它只需要检查 revents。// 伪代码聚焦 poll 关键用法 struct pollfd fds[1024]; fds[0].fd listen_fd; fds[0].events POLLIN; int nfds 1; while (1) { int ret poll(fds, nfds, -1); if (ret 0) { if (errno EINTR) continue; perror(poll); break; } if (fds[0].revents POLLIN) { int conn_fd accept(listen_fd, NULL, NULL); fds[nfds].fd conn_fd; fds[nfds].events POLLIN; nfds; } for (int i 1; i nfds; i) { if (fds[i].fd 0) continue; if (fds[i].revents (POLLIN | POLLERR | POLLHUP)) { char buf[1024]; ssize_t n recv(fds[i].fd, buf, sizeof(buf), 0); if (n 0) { close(fds[i].fd); fds[i].fd -1; // 标记删除之后统一清理 } else { send(fds[i].fd, buf, n, 0); } } } }poll 版本的循环体清爽不少。事件判断用fds[i].revents (POLLIN | POLLERR | POLLHUP)这一条把所有需要处理的情况都抓进来因为不管是数据到达、对端挂断还是连接错误我们最终都是去 recv 一把看结果。数组用固定 1024 只是个示范真到项目里会把固定数组换成动态扩容的fd 多了就 realloc。4.4 两版对比差在哪一层跑起来你几乎感觉不到性能差异代码上 poll 版少了每次重建集合的动作但多了一套数组维护逻辑。select 版的for (int fd 0; fd max_fd; fd)其实也是在扫全量 fdpoll 版扫的是数组本质上没区别。真正有体感差异的是使用体验poll 不用处理fd_set 被内核改写的隐患也不怕 fd 编号超过 1023。我建议新项目直接用 poll除非你要兼容某些老掉牙的系统环境。4.5 关键坑accept 返回 -1 的分支两个版本里都要对 accept 加一层保护。试想select/poll 报告监听 fd 可读但 accept 时返回 -1常见原因是对端在连接建立前已经断开TCP 三次握手的连接队列里挤满了半连接此时 errno 往往是 ECONNABORTED 或 EMFILE。不做保护的话单次 accept 失败可能让主循环直接退出整个服务挂掉。标准处理是继续循环别让一个异常连接杀死整个进程。5. 两者的量化对比与选型建议5.1 一张表看清差异对比维度selectpoll数据结构fd_set 位图pollfd 数组描述符上限FD_SETSIZE默认 1024无硬上限受内存限制事件类型读、写、异常分成三个集合统一为 events/revents 位掩码输入输出分离否fd_set 被内核改写是内核只填 revents超时精度微秒timeval毫秒int遍历方式内核位图扫描 用户态全量遍历内核数组扫描 用户态全量遍历复杂度O(n)O(n)主要问题1024 上限、需要重建集合无上限但仍是线性扫描5.2 连接规模划分百级、千级、万级实测下来我的体感是这样的单进程管理一百个以内的连接select 和 poll 的差异你根本感知不到瓶颈通常在业务处理逻辑上。一千到三千个连接select 还行但前提是 fd 编号别太分散——如果有一堆接近 1023 的 fd内核被迫扫描整个位图时间开销就上来了。三千到一万个连接poll 能扛但 CPU 飙高select 因为 1024 上限直接出局。连接再多老老实实上 epoll否则就是浪费 CPU 在无意义的全量扫描上。5.3 跨平台场景select 的隐藏优势poll 只存在于 POSIX 系统Windows 上原生没有这接口。select 几乎所有操作系统都支持包括 Windows 的 winsock。所以如果你要写跨平台网络库select 几乎是最低公约数的必选项。很多跨平台库的做法是底层封装 select上层做出统一的 event loop 接口再根据平台能力切换不同实现。5.4 选型决策树先问自己三个问题目标平台是什么预计同时在线连接多少代码维护成本更在意哪个方向平台只考虑 Linux连接数在可控范围内用 poll 更舒服要兼容 Windows 或 macOS用 select连接数可能破万两个都不选直接用 epoll代码量不想太大、追求快出功能select 的 API 更简单资料也多但注意它的 1024 上限别成为定时炸弹。把这三个问题过一遍选择基本就清楚了。6. 常见问题与排查技巧实录6.1 现象 1select 循环跑几次后新连接 accept 不到了排查思路先把 fd_set 的填充代码打印出来对比每次循环开头和 select 返回后的 fd_set 内容大概率是 fd_set 没有重建。常见的错误写法是在循环外定义一次 fd_set循环内直接传给 select。select 返回后没有就绪的 fd 对应的 bit 会被清零下次循环时这个 fd 就消失在监视名单里。解决办法就是每次循环都用 master 副本重建 read_set。6.2 现象 2poll 返回 POLLIN读取时却 read 返回 0连接就该关闭了这不是 bug是 TCP 的正常行为。对端正常关闭时poll 的通知里会带 POLLIN 或 POLLHUP哪个先到不一定。read 返回 0 是唯一的、可靠的对端已关闭信号。判断逻辑应该做成这样只要 revents 里包含 POLLIN | POLLHUP | POLLERR 中的任何一个就执行 readread 结果决定后续动作。千万别只看到 POLLIN 就以为一定有数据可收。6.3 现象 3服务器退出了端口还占着重启报 address already in use用 select/poll 写服务器很容易忽略SO_REUSEADDR。开发调试期服务器进程经常被 CtrlC 杀掉但 TCP 连接可能处于 TIME_WAIT 状态如果没设置 REUSEADDR立刻重启就会 bind 失败提示端口被占用。这是新手最常碰到的莫名其妙问题之一。int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));加在 bind 之前老生常谈但每次都有人忘。6.4 现象 4程序卡死好像什么都没做CPU 却飙高先检查有没有把超时设成 0 又没处理好。select/poll 超时都是 0 时内核立即返回如果你的 while 循环里没有阻塞操作马上又进入下一轮 select这就变成了 busy loopCPU 瞬间打满。真实场景往往出现在超时时间由某个变量控制结果该变量在循环里被改成 0的情况。排查方法是打印每次循环的 timeout 值最好在循环里加个计数器确认每轮之间是否有过真实等待。6.5 现象 5连接数没到上限select 却报 EBADFEBADF 表示传递给 select 的 fd_set 里含有一个未打开的描述符。最常见的来源是客户端连接被关闭后你调用了 close(fd)但忘了把 fd 从 fd_set 里 FD_CLR。内核在扫描位图时发现 fd 不对直接返回错误。poll 的对应情况好一些fd 置为 -1 会跳过select 里没有跳过这个选项所以 close(fd) 和 FD_CLR(fd) 必须是一个原子操作。6.6 通用排查技巧小工具大用处调试 select/poll 程序有三个工具帮我省了无数时间。第一个是strace -p 进程号直接看系统调用情况能立刻确认 select 是不是被反复调用、超时值到底是啥第二个是ss -ant或netstat -ant看连接状态判断是不是客户端压根没发数据第三个是打日志在每次 select/poll 返回后打印一下就绪 fd 的数量和耗时粗粒度定位性能瓶颈。6.7 从 select/poll 到 epoll 的平滑迁移当你真的遇到上万连接时从 poll 迁到 epoll 是必然路径。两者的代码结构差异很大epoll 把添加到监视列表和等待事件拆成两个系统调用需要你维护一个当前活跃的事件数组。但迁移过程中很多哪些 fd 在什么条件下需要关注的逻辑是可以直接复用的。我的建议是先把 poll 版本写稳再加上一个 epoll 实现用同样的业务处理逻辑通过配置文件选底层机制。这样既能保留 select/poll 在低并发场景的优势又能在高并发时切换到 epoll 扛压。我在实际写网络服务时select 和 poll 这两个机制到现在也没完全离开我的工具箱。低配设备上、跨平台小工具里select 仍然是稳妥的选择poll 则是我日常写 Linux 原型代码的默认选项——代码结构清晰没有 1024 的暗雷调试起来比 select 省心太多。它们的确老了但你亲手把 fd_set 重建一遍、被 POLLHUP 坑过一次之后再去看 epoll 的 eventpoll 结构、红黑树和就绪链表才能真正理解事件驱动这四个字的分量。如果你正在琢磨自己的第一个多客户端服务器别急着上 epoll先拿 select 或 poll 把小流量场景跑通。把这两个老机制用熟你会更清楚网络编程里哪些开销是不可避免的、哪些是可以被优化的这种判断力比多背几个 API 有用得多。