上周有个朋友跟我诉苦说他的Linux网络编程项目出了问题客户端一多服务端就用多进程硬扛结果内存毫无征兆地涨CPU也跟着乱跳。我让他先去把I/O模型理顺从select和poll开始动手。这两个接口算是Linux网络编程里历史最悠久的多路转接I/O方案哪怕今天epoll已经成了高性能服务的标配select和poll依然是绕不开的基础功——不理解它们的设计缺陷你就没法真正理解epoll为什么长成现在这个样子。这篇文章适合谁正在学Linux网络编程、看到select和poll函数一头雾水的初学者或者已经在项目里用多线程硬扛连接、想换个思路的开发者。我会把API拆开讲把原理讲明白最后把当年踩过的坑也一并倒出来。看完你至少能把select和poll的代码骨架默写出来也能在方案选型的时候说出个一二三。1. 为什么需要多路转接I/O一个老问题的新解法1.1 传统阻塞模型到底卡在哪先看最原始的阻塞式socket编程。服务器accept之后每来一个客户端连接就开一个线程或者进程专门去recv这个连接上的数据。这种“一连接一线程”的模型在连接少时完全没问题但一旦连接多起来问题就暴露得很明显。第一线程是有成本的。每个线程默认栈空间可能是8MB创建线程本身也需要时间10000个连接开10000个线程光栈空间就是80GB这还没算线程切换带来的CPU开销。第二大部分连接其实不活跃。长连接场景里比如聊天服务、推送服务同一时刻真正在传输数据的可能只有百分之几剩下的线程全在阻塞等待白白占着资源睡大觉。第三频繁的线程切换会让系统非常难受。阻塞线程被唤醒、挂起、又唤醒内核调度器忙得团团转但有效工作产出很低。我之前接过一个业务连接数到了1500左右进程数直接逼近系统上限然后开始出现“connect: Cannot assign requested address”这种莫名其妙的问题。排查到后面才明白根本不是端口不够是线程资源被耗尽了。这就是传统阻塞模型的死穴——资源是配给“等待”而不是配给“工作”的。1.2 非阻塞加轮询另一个极端有人会想那我不用多线程把所有socket都设置成O_NONBLOCK然后主循环挨个去读不就好了这个思路确实解决了线程开销的问题但引入了新的麻烦怎么知道哪个fd有数据你只能从头到尾把所有fd循环一遍调用read或者recv去试探。绝大多数fd没有数据read会返回EAGAIN然后你继续下一个。这个循环可能空转几千次CPU一直处于忙等状态但实际没干一点有用的活。连接少还能忍连接一多CPU时间全花在无效的系统调用上了。轮询的本质是用CPU换内存多线程的本质是用内存换CPU。这两个方案都没找到真正的平衡点——问题不在于怎么读数据而在于怎么知道哪个fd有数据。1.3 交给内核去盯多路转接的核心select和poll给出的答案是我们把关心的fd都交给内核内核帮我们盯着一旦某个fd有事件发生内核负责通知我们。没有事件的时候进程可以安心睡眠不浪费CPU。这个思想就像你去图书馆借书不需要自己跑遍所有书架看有没有新书上架而是登记一个“有新书通知我”的条子管理员到货了自然会打电话给你。select和poll就是最早落地的两套“管理员通知”机制。准备好把sleep让给内核换回真正高效的网络处理方式。不过我得提前泼一盆冷水select和poll解决了“谁来通知”的问题但并没有把通知这件事做到最高效。它们的短板恰恰就是下一代epoll登场的理由。2. select深度拆解API、原理与代码骨架2.1 先看懂这四个关键参数select的函数签名长这样#include sys/select.h #include sys/time.h int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);很多初学者第一个懵的就是nfds。它的意思是“最大的文件描述符编号加1”不是fd的总数。为什么要加1因为内核要扫描的是0到nfds-1之间的所有fd。假设你最大的fd是监听socket编号是5那nfds就传6内核会检查0、1、2、3、4、5这六个位置。readfds、writefds、exceptfds是三个fd_set类型的指针分别用来表示“哪些fd我想读”、“哪些fd我想写”、“哪些fd我想关注异常”。不关心某类事件对应的参数就传NULL。这里有个容易忽略的点select能同时监听三类事件这个能力在特定场景下非常有用比如你想在同一个循环里既处理新连接又回显数据给旧连接readfds里同时放进listen_fd和各个socket的fd就行。timeout是等待时间的上限。三种传法对应三种行为传NULL无限期阻塞直到有fd就绪。传指向timeval的指针但两个字段都是0立即返回相当于非阻塞探测。其他值最多等待这么多时间超时后返回0。坑就在这里Linux内核会把这个timeval改成“剩余时间”所以你不能复用一个timeval每次调用select前都必须重新赋值。2.2 fd_set与五个宏一张位图考勤表fd_set到底是个什么结构把它想成一张位图bitmap每一位对应一个文件描述符。如果某一位是1表示“这个fd我在关注”是0表示“不关注”。对fd_set的操作靠五个宏完成FD_ZERO(fd_set *set); // 把整个位图清零 FD_SET(int fd, fd_set *set); // 把fd对应的位置1表示加入关注 FD_CLR(int fd, fd_set *set); // 把fd对应的位清0表示取消关注 FD_ISSET(int fd, fd_set *set); // 检查fd对应的位是不是1返回非0表示就绪这五个宏里你实际用的最多的就是FD_SET和FD_ISSET。前者在每次有新连接加入时把fd放进集合后者在select返回后逐个检查到底谁就绪了。fd_set能容纳的最大fd编号由FD_SETSIZE决定Linux下通常是1024。也就是说用select管理文件描述符编号超过1023的fd就用不了这是select最著名的天花板。2.3 select服务端代码骨架照着写就能跑直接把核心循环写出来这是我看过无数遍自己也写过无数遍的结构fd_set all_fds, read_fds; int max_fd listen_fd; FD_ZERO(all_fds); FD_SET(listen_fd, all_fds); while (1) { read_fds all_fds; // 每次都要重新拷贝因为select会修改read_fds struct timeval tv {5, 0}; // 5秒超时每次都要重新赋值 int ret select(max_fd 1, read_fds, NULL, NULL, tv); if (ret 0 errno EINTR) { continue; // 被信号打断重新select } if (ret 0) { printf(select timeout...\n); continue; } // 先检查listen_fd有新的连接进来 if (FD_ISSET(listen_fd, read_fds)) { struct sockaddr_in client_addr; socklen_t addr_len sizeof(client_addr); int conn_fd accept(listen_fd, (struct sockaddr *)client_addr, addr_len); if (conn_fd 0) { FD_SET(conn_fd, all_fds); if (conn_fd max_fd) max_fd conn_fd; } } // 遍历检查所有fd处理读写 for (int fd 0; fd max_fd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, read_fds)) { char buf[1024]; ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { write(fd, buf, n); // 回显 } else if (n 0) { close(fd); FD_CLR(fd, all_fds); // 对端关闭必须从集合中移除 } else { if (errno ! EAGAIN) { close(fd); FD_CLR(fd, all_fds); } } } } }这段代码能跑但它只是一个骨架离生产级还差很远。最大的问题在于每次select返回后你要从0遍历到max_fd全部检查一遍。我后面会专门讲这个O(n)扫描为什么是性能杀手。2.4 select的四个硬伤一个都躲不掉四个硬伤每个都是在生产环境里实打实踩过的第一fd数量上限。FD_SETSIZE通常就是1024一个进程用select最多监视1024个fd。在连接数超过一千的服务里这个限制非常致命。有人会说可以改FD_SETSIZE编译但改了之后fd_set占用的内存成倍增长而且需要重新编译整个内核的libc相关部分工程上得不偿失。第二集合全量拷贝。每次调用select内核都要把三个fd_set从用户态拷贝到内核态这本身就是一次不小的开销。更糟糕的是select返回后内核会修改这个集合——把没有就绪的fd对应的位清掉只保留就绪的。所以你必须备份原始集合下次再重新拷贝。一来一回白白做了两遍全量复制。第三O(n)遍历。select返回只是一句“有n个fd就绪了”但它不会告诉你具体是哪几个。你得自己从0到max_fd扫一遍再配合FD_ISSET判断。连接越多遍历的代价越大。要是大多数连接都不活跃每次循环都是在为“沉默的大多数”买单。第四触发模式单一。select和poll都只支持水平触发Level-Triggered意思是只要fd上还有数据没读完每次select返回时这个fd就一定是“就绪”状态。如果没有及时把数据读完下次select还会继续通知你导致一个连接反复触发抢占处理时间。这四个问题核心就是上限低、拷贝重、扫描慢、状态会被内核破坏。poll解决了其中一部分但远远没有全部解决。3. poll继承者解决了什么还剩什么3.1 poll API与pollfd结构更清晰的参数设计poll的头文件和函数签名如下#include poll.h int poll(struct pollfd *fds, nfds_t nfds, int timeout);核心数据结构是pollfd数组struct pollfd { int fd; // 要监视的文件描述符 short events; // 期望关注的事件调用前由用户设置 short revents; // 实际发生的事件调用后由内核填写 };看到events和revents分离你就能感觉到设计上的进步。select把“输入”和“输出”混在同一个fd_set里内核会把输入集合改得面目全非所以你得重新拷贝poll则是输入归输入、输出归输出调用poll之后events字段纹丝不动revents字段由内核负责填写。你拿着同一个fds数组反复调用poll都可以不需要重建省去了select里最烦人的那步操作。poll的nfds直接就是数组长度不用再传“最大fd加1”参数语义清楚了很多。timeout单位是毫秒传入-1表示无限等待0表示立即返回。3.2 poll事件类型别只盯着POLLINpoll的事件类型是通过位掩码组合的常用的几个POLLIN有数据可读。注意对端关闭连接时也会触发POLLIN因为read能读到0字节EOF你需要自己判断。POLLOUT可以写入数据不会阻塞。这个对于非阻塞发送的场景很关键。POLLERRfd发生错误。POLLHUP对端挂断连接。POLLNVALfd未打开或者本身无效。实际写代码时只判断POLLIN远远不够。对端异常断开、半关闭、fd出错这些情况很多时候会表现为POLLERR或POLLHUP。你如果不处理fd会一直留在数组里每次都参与遍历但永远等不到数据这就是一个隐藏的bug。通常推荐一个组合写法if (fds[i].revents (POLLIN | POLLERR | POLLHUP | POLLNVAL)) { // 要么有数据要么连接出问题统一处理 }然后在数据读取分支里用read的返回值区分正常数据、EOF和错误。3.3 poll服务端代码骨架数组管理是关键struct pollfd fds[1024]; int nfds 1; fds[0].fd listen_fd; fds[0].events POLLIN; while (1) { int ret poll(fds, nfds, 5000); // 5秒超时毫秒 if (ret 0 errno EINTR) continue; if (ret 0) continue; // 处理新连接 if (fds[0].revents POLLIN) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd 0) { 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 read(fds[i].fd, buf, sizeof(buf)); if (n 0) { close(fds[i].fd); fds[i].fd -1; // 标记为可复用槽位 } else if (n 0) { write(fds[i].fd, buf, n); } else { close(fds[i].fd); fds[i].fd -1; } } } }这里有个细节很多人会忽略数组里删除fd时不能只是把fd关掉还要把数组里的fd置为-1做标记后续遍历时要跳过。如果你直接把数组元素往前搬移下标会乱逻辑容易出错。用空闲标记法牺牲一点点空间换来的是代码简单和稳定。3.4 poll比select强在哪板子还剩下什么强的地方是实实在在的没有FD_SETSIZE的固定上限理论上能监视的fd数量只受系统允许打开的文件描述符上限约束可以ulimit -n调整不需要重新构建输入集合events和revents分离API干净事件类型更丰富能区分挂断和错误排查问题的时候信息更有价值。但板子并没有消失。poll依然需要把整个pollfd数组从用户态拷贝到内核态内核还是要遍历一遍所有fd来判断有没有事件返回后用户还要再遍历整个数组来确认哪些fd就绪了。也就是说O(n)的全量拷贝和O(n)的全量扫描poll一个都没少。当监视的fd数量从几千涨到几万poll照样会被拖垮。4. 场景选型select还是poll这是个真问题4.1 五个维度的对比速查直接从实战角度整理一张对比表拿去就能用对比维度selectpollfd数量上限FD_SETSIZELinux下通常1024无固定上限受系统rlimit约束输入集合维护内核会修改fd_set每次需重新拷贝events和revents分离无需重建超时精度微秒级timeval毫秒级int可移植性Windows、Linux、Unix都支持主要支持Unix/Linux风格系统就绪检查方式FD_ISSET遍历0~max_fd遍历pollfd数组触发模式水平触发水平触发时间精度看起来select更好但在实际网络编程里微秒级的超时价值不大。你可以把select当成一个微秒精度的睡眠器来用比如sleep 10ms这种需求select都能做到但这个优势在监听网络事件时体现不出来。4.2 我实际会怎么选根据我的项目经验给出一套简单直接的决策标准连接数在几十个以内程序还可能在Windows上跑那没得说用select。Windows也提供了select接口几乎一致跨平台省事。连接数几百到几千环境锁定Linux对遍历开销可以接受那用poll。poll少了重建集合的麻烦代码写起来清爽很多。连接数上到万级或者连接虽没那么多但活跃连接占比较高那我建议直接考虑epoll。不要在有高性能需求的地方硬用select/poll。有一种场景select反而更适合你同时要等网络事件和定时器。select的timeval是微秒级你完全可以用它来实现精确定时一个调用同时搞定网络和定时很省事。4.3 为什么说弄懂它们才能理解epoll有朋友问我既然epoll那么强我直接从epoll开始学不行吗我的建议是最好不要。因为epoll每一个设计亮点几乎都对应着select/poll的一个具体痛点。epoll用红黑树保存fd解决了select/poll大量fd每次都全量拷贝的问题epoll让内核直接告诉我们哪些fd就绪了返回的是一个“就绪列表”解决了O(n)遍历的问题epoll还支持边缘触发Edge-Triggered解决了水平触发下反复唤醒的问题。你要是不知道select/poll的痛点在哪儿就无法真正体会epoll这些设计是在解决什么。所以这篇文章虽然是讲select和poll的其实也是在为epoll打地基。下一篇我会写epoll的完整拆解但建议你先把手头的select/poll代码跑通理解透了再往上走。5. 踩坑实录这些Bug我帮你们踩过了5.1 忘掉重新拷贝fd_set连接全部失效这是我早期写select时第一个抓狂的bug。fd_set是会被内核修改的select返回后未就绪的fd对应的位会被清除。如果你下次循环不重新拷贝一份原始的all_fds而是直接复用上一次的read_fds那集合会越来越“瘦”到最后只剩一两个fd还在里面连接莫名其妙的就全断了。排查方法很笨但有效每次select调用前把read_fds打印出来看看对比一下就知道是不是被内核改了。记住这句口诀select有副作用服用前必重拷。5.2 nfds传错新连接悄无声息地失踪nfds要传最大fd加1不是FD_SETSIZE也不是最大fd本身。有个经典场景你的listen_fd是3后来accept的client fd是4那max_fd更新成4nfds传5。如果你忘了更新max_fd一直传3那fd4的连接就永远不在内核的检查范围里新连接即使有数据select也永远不会返回它。结果表现就是客户端明明发数据了服务端却像是瞎了一样。排查方法很简单用strace看一眼系统调用的实际参数strace -p pid -e traceselect你会清清楚楚看到select()的参数写的是什么一眼就能看出nfds传错没有。5.3 read返回0不清理触发Busy Loop对端关闭连接时read返回0。如果你只写了“n 0”才处理数据忽略了n 0的情况那这个fd会一直保持“可读”状态——因为EOF永远不会被消费掉。于是select每次返回都包含这个fd你每次循环都会走到它面前但read又立刻返回0形成一个死循环。更隐蔽的是poll里的POLLHUP和POLLNVAL。如果你没有把这些事件纳入处理分支fd会一直留在数组里反复参与遍历。我建议的处理方式是处理事件时不要只判断POLLIN把POLLERR、POLLHUP、POLLNVAL都归入“需要处理”的分支然后统一用read的返回来决定下一步。5.4 EMFILEaccept失败引发的灾难连接数到达系统文件描述符上限时accept会失败返回EMFILE。如果你的代码只写了“if (conn_fd 0)加入集合”没有处理失败分支那accept会一直尝试每次都返回EMFILE每次都触发select里listen_fd的读事件主循环直接原地打转。这是个非常经典的坑。解决办法有几种最推荐的是在accept之前先调用一次select只监听listen_fd确认没有其他fd就绪后再处理新连接或者干脆优先关闭一个空闲连接再accept。总之EMFILE处理不当后果比想象中严重得多。5.5 EINTR信号一来白等一次进程只要注册了信号处理函数select和poll在阻塞等待时被信号打断就会返回-1同时errno被设为EINTR。如果你不处理直接把返回-1当成致命错误退出那程序会隔三差五地“意外退出”。正确的姿势是检查errno如果等于EINTR就continue重新调用。这个坑在用了SIGURG、SIGALRM之类的信号后特别容易踩到别问我怎么知道的。5.6 poll数组删除元素时的槽位管理poll的数组不像select有位图删除时如果直接搬移元素会让下标和fd的对应关系错乱。我推荐的做法是关闭fd后把fds[i].fd置为-1遍历时跳过。处理新连接时优先复用这些空闲槽位。这种做法虽然多占几个数组位置但胜在稳定。生产环境中数组长度预留到连接上限的两倍左右基本不会出问题。5.7 踩坑速查表把上面的坑汇总成一张速查表方便你排查时对照现象可能原因解决办法连接全部断掉 / fd越来越少select修改fd_set未重新拷贝每次select前重新赋值新连接一直没响应nfds没更新为max_fd1维护max_fd并正确传参CPU占用100%read返回0但未清理fd关闭fd并从集合/数组移除程序莫名其妙退出未处理EINTRerrnoEINTR时continue大量连接被拒文件描述符上限耗尽处理EMFILE预留或淘汰空闲连接poll数组越用越乱删除时未标记/未跳过fd置为-1遍历时跳过最后分享一个小建议学习select和poll时不用急着追求“最优解”先把这两套API彻底弄透用strace观察系统调用行为用代码复现每个坑。我的体会是很多面试里问select和poll区别的人其实真正想考察的是你有没有把这些基础机制内化成自己的工程直觉。理解了它们的上限和不足你才真正具备了在生产环境里做技术选型的能力。
上周有个朋友跟我诉苦说他的Linux网络编程项目出了问题客户端一多服务端就用多进程硬扛结果内存毫无征兆地涨CPU也跟着乱跳。我让他先去把I/O模型理顺从select和poll开始动手。这两个接口算是Linux网络编程里历史最悠久的多路转接I/O方案哪怕今天epoll已经成了高性能服务的标配select和poll依然是绕不开的基础功——不理解它们的设计缺陷你就没法真正理解epoll为什么长成现在这个样子。这篇文章适合谁正在学Linux网络编程、看到select和poll函数一头雾水的初学者或者已经在项目里用多线程硬扛连接、想换个思路的开发者。我会把API拆开讲把原理讲明白最后把当年踩过的坑也一并倒出来。看完你至少能把select和poll的代码骨架默写出来也能在方案选型的时候说出个一二三。1. 为什么需要多路转接I/O一个老问题的新解法1.1 传统阻塞模型到底卡在哪先看最原始的阻塞式socket编程。服务器accept之后每来一个客户端连接就开一个线程或者进程专门去recv这个连接上的数据。这种“一连接一线程”的模型在连接少时完全没问题但一旦连接多起来问题就暴露得很明显。第一线程是有成本的。每个线程默认栈空间可能是8MB创建线程本身也需要时间10000个连接开10000个线程光栈空间就是80GB这还没算线程切换带来的CPU开销。第二大部分连接其实不活跃。长连接场景里比如聊天服务、推送服务同一时刻真正在传输数据的可能只有百分之几剩下的线程全在阻塞等待白白占着资源睡大觉。第三频繁的线程切换会让系统非常难受。阻塞线程被唤醒、挂起、又唤醒内核调度器忙得团团转但有效工作产出很低。我之前接过一个业务连接数到了1500左右进程数直接逼近系统上限然后开始出现“connect: Cannot assign requested address”这种莫名其妙的问题。排查到后面才明白根本不是端口不够是线程资源被耗尽了。这就是传统阻塞模型的死穴——资源是配给“等待”而不是配给“工作”的。1.2 非阻塞加轮询另一个极端有人会想那我不用多线程把所有socket都设置成O_NONBLOCK然后主循环挨个去读不就好了这个思路确实解决了线程开销的问题但引入了新的麻烦怎么知道哪个fd有数据你只能从头到尾把所有fd循环一遍调用read或者recv去试探。绝大多数fd没有数据read会返回EAGAIN然后你继续下一个。这个循环可能空转几千次CPU一直处于忙等状态但实际没干一点有用的活。连接少还能忍连接一多CPU时间全花在无效的系统调用上了。轮询的本质是用CPU换内存多线程的本质是用内存换CPU。这两个方案都没找到真正的平衡点——问题不在于怎么读数据而在于怎么知道哪个fd有数据。1.3 交给内核去盯多路转接的核心select和poll给出的答案是我们把关心的fd都交给内核内核帮我们盯着一旦某个fd有事件发生内核负责通知我们。没有事件的时候进程可以安心睡眠不浪费CPU。这个思想就像你去图书馆借书不需要自己跑遍所有书架看有没有新书上架而是登记一个“有新书通知我”的条子管理员到货了自然会打电话给你。select和poll就是最早落地的两套“管理员通知”机制。准备好把sleep让给内核换回真正高效的网络处理方式。不过我得提前泼一盆冷水select和poll解决了“谁来通知”的问题但并没有把通知这件事做到最高效。它们的短板恰恰就是下一代epoll登场的理由。2. select深度拆解API、原理与代码骨架2.1 先看懂这四个关键参数select的函数签名长这样#include sys/select.h #include sys/time.h int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);很多初学者第一个懵的就是nfds。它的意思是“最大的文件描述符编号加1”不是fd的总数。为什么要加1因为内核要扫描的是0到nfds-1之间的所有fd。假设你最大的fd是监听socket编号是5那nfds就传6内核会检查0、1、2、3、4、5这六个位置。readfds、writefds、exceptfds是三个fd_set类型的指针分别用来表示“哪些fd我想读”、“哪些fd我想写”、“哪些fd我想关注异常”。不关心某类事件对应的参数就传NULL。这里有个容易忽略的点select能同时监听三类事件这个能力在特定场景下非常有用比如你想在同一个循环里既处理新连接又回显数据给旧连接readfds里同时放进listen_fd和各个socket的fd就行。timeout是等待时间的上限。三种传法对应三种行为传NULL无限期阻塞直到有fd就绪。传指向timeval的指针但两个字段都是0立即返回相当于非阻塞探测。其他值最多等待这么多时间超时后返回0。坑就在这里Linux内核会把这个timeval改成“剩余时间”所以你不能复用一个timeval每次调用select前都必须重新赋值。2.2 fd_set与五个宏一张位图考勤表fd_set到底是个什么结构把它想成一张位图bitmap每一位对应一个文件描述符。如果某一位是1表示“这个fd我在关注”是0表示“不关注”。对fd_set的操作靠五个宏完成FD_ZERO(fd_set *set); // 把整个位图清零 FD_SET(int fd, fd_set *set); // 把fd对应的位置1表示加入关注 FD_CLR(int fd, fd_set *set); // 把fd对应的位清0表示取消关注 FD_ISSET(int fd, fd_set *set); // 检查fd对应的位是不是1返回非0表示就绪这五个宏里你实际用的最多的就是FD_SET和FD_ISSET。前者在每次有新连接加入时把fd放进集合后者在select返回后逐个检查到底谁就绪了。fd_set能容纳的最大fd编号由FD_SETSIZE决定Linux下通常是1024。也就是说用select管理文件描述符编号超过1023的fd就用不了这是select最著名的天花板。2.3 select服务端代码骨架照着写就能跑直接把核心循环写出来这是我看过无数遍自己也写过无数遍的结构fd_set all_fds, read_fds; int max_fd listen_fd; FD_ZERO(all_fds); FD_SET(listen_fd, all_fds); while (1) { read_fds all_fds; // 每次都要重新拷贝因为select会修改read_fds struct timeval tv {5, 0}; // 5秒超时每次都要重新赋值 int ret select(max_fd 1, read_fds, NULL, NULL, tv); if (ret 0 errno EINTR) { continue; // 被信号打断重新select } if (ret 0) { printf(select timeout...\n); continue; } // 先检查listen_fd有新的连接进来 if (FD_ISSET(listen_fd, read_fds)) { struct sockaddr_in client_addr; socklen_t addr_len sizeof(client_addr); int conn_fd accept(listen_fd, (struct sockaddr *)client_addr, addr_len); if (conn_fd 0) { FD_SET(conn_fd, all_fds); if (conn_fd max_fd) max_fd conn_fd; } } // 遍历检查所有fd处理读写 for (int fd 0; fd max_fd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, read_fds)) { char buf[1024]; ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { write(fd, buf, n); // 回显 } else if (n 0) { close(fd); FD_CLR(fd, all_fds); // 对端关闭必须从集合中移除 } else { if (errno ! EAGAIN) { close(fd); FD_CLR(fd, all_fds); } } } } }这段代码能跑但它只是一个骨架离生产级还差很远。最大的问题在于每次select返回后你要从0遍历到max_fd全部检查一遍。我后面会专门讲这个O(n)扫描为什么是性能杀手。2.4 select的四个硬伤一个都躲不掉四个硬伤每个都是在生产环境里实打实踩过的第一fd数量上限。FD_SETSIZE通常就是1024一个进程用select最多监视1024个fd。在连接数超过一千的服务里这个限制非常致命。有人会说可以改FD_SETSIZE编译但改了之后fd_set占用的内存成倍增长而且需要重新编译整个内核的libc相关部分工程上得不偿失。第二集合全量拷贝。每次调用select内核都要把三个fd_set从用户态拷贝到内核态这本身就是一次不小的开销。更糟糕的是select返回后内核会修改这个集合——把没有就绪的fd对应的位清掉只保留就绪的。所以你必须备份原始集合下次再重新拷贝。一来一回白白做了两遍全量复制。第三O(n)遍历。select返回只是一句“有n个fd就绪了”但它不会告诉你具体是哪几个。你得自己从0到max_fd扫一遍再配合FD_ISSET判断。连接越多遍历的代价越大。要是大多数连接都不活跃每次循环都是在为“沉默的大多数”买单。第四触发模式单一。select和poll都只支持水平触发Level-Triggered意思是只要fd上还有数据没读完每次select返回时这个fd就一定是“就绪”状态。如果没有及时把数据读完下次select还会继续通知你导致一个连接反复触发抢占处理时间。这四个问题核心就是上限低、拷贝重、扫描慢、状态会被内核破坏。poll解决了其中一部分但远远没有全部解决。3. poll继承者解决了什么还剩什么3.1 poll API与pollfd结构更清晰的参数设计poll的头文件和函数签名如下#include poll.h int poll(struct pollfd *fds, nfds_t nfds, int timeout);核心数据结构是pollfd数组struct pollfd { int fd; // 要监视的文件描述符 short events; // 期望关注的事件调用前由用户设置 short revents; // 实际发生的事件调用后由内核填写 };看到events和revents分离你就能感觉到设计上的进步。select把“输入”和“输出”混在同一个fd_set里内核会把输入集合改得面目全非所以你得重新拷贝poll则是输入归输入、输出归输出调用poll之后events字段纹丝不动revents字段由内核负责填写。你拿着同一个fds数组反复调用poll都可以不需要重建省去了select里最烦人的那步操作。poll的nfds直接就是数组长度不用再传“最大fd加1”参数语义清楚了很多。timeout单位是毫秒传入-1表示无限等待0表示立即返回。3.2 poll事件类型别只盯着POLLINpoll的事件类型是通过位掩码组合的常用的几个POLLIN有数据可读。注意对端关闭连接时也会触发POLLIN因为read能读到0字节EOF你需要自己判断。POLLOUT可以写入数据不会阻塞。这个对于非阻塞发送的场景很关键。POLLERRfd发生错误。POLLHUP对端挂断连接。POLLNVALfd未打开或者本身无效。实际写代码时只判断POLLIN远远不够。对端异常断开、半关闭、fd出错这些情况很多时候会表现为POLLERR或POLLHUP。你如果不处理fd会一直留在数组里每次都参与遍历但永远等不到数据这就是一个隐藏的bug。通常推荐一个组合写法if (fds[i].revents (POLLIN | POLLERR | POLLHUP | POLLNVAL)) { // 要么有数据要么连接出问题统一处理 }然后在数据读取分支里用read的返回值区分正常数据、EOF和错误。3.3 poll服务端代码骨架数组管理是关键struct pollfd fds[1024]; int nfds 1; fds[0].fd listen_fd; fds[0].events POLLIN; while (1) { int ret poll(fds, nfds, 5000); // 5秒超时毫秒 if (ret 0 errno EINTR) continue; if (ret 0) continue; // 处理新连接 if (fds[0].revents POLLIN) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd 0) { 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 read(fds[i].fd, buf, sizeof(buf)); if (n 0) { close(fds[i].fd); fds[i].fd -1; // 标记为可复用槽位 } else if (n 0) { write(fds[i].fd, buf, n); } else { close(fds[i].fd); fds[i].fd -1; } } } }这里有个细节很多人会忽略数组里删除fd时不能只是把fd关掉还要把数组里的fd置为-1做标记后续遍历时要跳过。如果你直接把数组元素往前搬移下标会乱逻辑容易出错。用空闲标记法牺牲一点点空间换来的是代码简单和稳定。3.4 poll比select强在哪板子还剩下什么强的地方是实实在在的没有FD_SETSIZE的固定上限理论上能监视的fd数量只受系统允许打开的文件描述符上限约束可以ulimit -n调整不需要重新构建输入集合events和revents分离API干净事件类型更丰富能区分挂断和错误排查问题的时候信息更有价值。但板子并没有消失。poll依然需要把整个pollfd数组从用户态拷贝到内核态内核还是要遍历一遍所有fd来判断有没有事件返回后用户还要再遍历整个数组来确认哪些fd就绪了。也就是说O(n)的全量拷贝和O(n)的全量扫描poll一个都没少。当监视的fd数量从几千涨到几万poll照样会被拖垮。4. 场景选型select还是poll这是个真问题4.1 五个维度的对比速查直接从实战角度整理一张对比表拿去就能用对比维度selectpollfd数量上限FD_SETSIZELinux下通常1024无固定上限受系统rlimit约束输入集合维护内核会修改fd_set每次需重新拷贝events和revents分离无需重建超时精度微秒级timeval毫秒级int可移植性Windows、Linux、Unix都支持主要支持Unix/Linux风格系统就绪检查方式FD_ISSET遍历0~max_fd遍历pollfd数组触发模式水平触发水平触发时间精度看起来select更好但在实际网络编程里微秒级的超时价值不大。你可以把select当成一个微秒精度的睡眠器来用比如sleep 10ms这种需求select都能做到但这个优势在监听网络事件时体现不出来。4.2 我实际会怎么选根据我的项目经验给出一套简单直接的决策标准连接数在几十个以内程序还可能在Windows上跑那没得说用select。Windows也提供了select接口几乎一致跨平台省事。连接数几百到几千环境锁定Linux对遍历开销可以接受那用poll。poll少了重建集合的麻烦代码写起来清爽很多。连接数上到万级或者连接虽没那么多但活跃连接占比较高那我建议直接考虑epoll。不要在有高性能需求的地方硬用select/poll。有一种场景select反而更适合你同时要等网络事件和定时器。select的timeval是微秒级你完全可以用它来实现精确定时一个调用同时搞定网络和定时很省事。4.3 为什么说弄懂它们才能理解epoll有朋友问我既然epoll那么强我直接从epoll开始学不行吗我的建议是最好不要。因为epoll每一个设计亮点几乎都对应着select/poll的一个具体痛点。epoll用红黑树保存fd解决了select/poll大量fd每次都全量拷贝的问题epoll让内核直接告诉我们哪些fd就绪了返回的是一个“就绪列表”解决了O(n)遍历的问题epoll还支持边缘触发Edge-Triggered解决了水平触发下反复唤醒的问题。你要是不知道select/poll的痛点在哪儿就无法真正体会epoll这些设计是在解决什么。所以这篇文章虽然是讲select和poll的其实也是在为epoll打地基。下一篇我会写epoll的完整拆解但建议你先把手头的select/poll代码跑通理解透了再往上走。5. 踩坑实录这些Bug我帮你们踩过了5.1 忘掉重新拷贝fd_set连接全部失效这是我早期写select时第一个抓狂的bug。fd_set是会被内核修改的select返回后未就绪的fd对应的位会被清除。如果你下次循环不重新拷贝一份原始的all_fds而是直接复用上一次的read_fds那集合会越来越“瘦”到最后只剩一两个fd还在里面连接莫名其妙的就全断了。排查方法很笨但有效每次select调用前把read_fds打印出来看看对比一下就知道是不是被内核改了。记住这句口诀select有副作用服用前必重拷。5.2 nfds传错新连接悄无声息地失踪nfds要传最大fd加1不是FD_SETSIZE也不是最大fd本身。有个经典场景你的listen_fd是3后来accept的client fd是4那max_fd更新成4nfds传5。如果你忘了更新max_fd一直传3那fd4的连接就永远不在内核的检查范围里新连接即使有数据select也永远不会返回它。结果表现就是客户端明明发数据了服务端却像是瞎了一样。排查方法很简单用strace看一眼系统调用的实际参数strace -p pid -e traceselect你会清清楚楚看到select()的参数写的是什么一眼就能看出nfds传错没有。5.3 read返回0不清理触发Busy Loop对端关闭连接时read返回0。如果你只写了“n 0”才处理数据忽略了n 0的情况那这个fd会一直保持“可读”状态——因为EOF永远不会被消费掉。于是select每次返回都包含这个fd你每次循环都会走到它面前但read又立刻返回0形成一个死循环。更隐蔽的是poll里的POLLHUP和POLLNVAL。如果你没有把这些事件纳入处理分支fd会一直留在数组里反复参与遍历。我建议的处理方式是处理事件时不要只判断POLLIN把POLLERR、POLLHUP、POLLNVAL都归入“需要处理”的分支然后统一用read的返回来决定下一步。5.4 EMFILEaccept失败引发的灾难连接数到达系统文件描述符上限时accept会失败返回EMFILE。如果你的代码只写了“if (conn_fd 0)加入集合”没有处理失败分支那accept会一直尝试每次都返回EMFILE每次都触发select里listen_fd的读事件主循环直接原地打转。这是个非常经典的坑。解决办法有几种最推荐的是在accept之前先调用一次select只监听listen_fd确认没有其他fd就绪后再处理新连接或者干脆优先关闭一个空闲连接再accept。总之EMFILE处理不当后果比想象中严重得多。5.5 EINTR信号一来白等一次进程只要注册了信号处理函数select和poll在阻塞等待时被信号打断就会返回-1同时errno被设为EINTR。如果你不处理直接把返回-1当成致命错误退出那程序会隔三差五地“意外退出”。正确的姿势是检查errno如果等于EINTR就continue重新调用。这个坑在用了SIGURG、SIGALRM之类的信号后特别容易踩到别问我怎么知道的。5.6 poll数组删除元素时的槽位管理poll的数组不像select有位图删除时如果直接搬移元素会让下标和fd的对应关系错乱。我推荐的做法是关闭fd后把fds[i].fd置为-1遍历时跳过。处理新连接时优先复用这些空闲槽位。这种做法虽然多占几个数组位置但胜在稳定。生产环境中数组长度预留到连接上限的两倍左右基本不会出问题。5.7 踩坑速查表把上面的坑汇总成一张速查表方便你排查时对照现象可能原因解决办法连接全部断掉 / fd越来越少select修改fd_set未重新拷贝每次select前重新赋值新连接一直没响应nfds没更新为max_fd1维护max_fd并正确传参CPU占用100%read返回0但未清理fd关闭fd并从集合/数组移除程序莫名其妙退出未处理EINTRerrnoEINTR时continue大量连接被拒文件描述符上限耗尽处理EMFILE预留或淘汰空闲连接poll数组越用越乱删除时未标记/未跳过fd置为-1遍历时跳过最后分享一个小建议学习select和poll时不用急着追求“最优解”先把这两套API彻底弄透用strace观察系统调用行为用代码复现每个坑。我的体会是很多面试里问select和poll区别的人其实真正想考察的是你有没有把这些基础机制内化成自己的工程直觉。理解了它们的上限和不足你才真正具备了在生产环境里做技术选型的能力。
