我最早被网络编程虐到怀疑人生就是因为不理解 select 模型。那时我写了一个极简的 TCP 服务端用阻塞 socket 加一个死循环处理客户端请求结果只有一个客户端连上来还好一旦第二个客户端接入第一个客户端立刻失联。后来我才明白这个问题的根源就是一个阻塞的 recv 调用会独占整个执行流服务端在同一时刻只能服务一个连接。解决这个问题的经典方案就是 I/O 多路复用模型而 select 模型就是其中最基础、几乎每个平台都支持的那一套。它让一个线程能同时监视多个 socket 的可读、可写、异常事件内核有事件发生时才通知你处理。今天这篇博文我会从问题拆解、核心 API 用法、完整可运行的代码示例、再到我实际踩过的一堆坑把 select 模型一次讲透。无论你是刚入门 socket 编程的新手还是想把阻塞式服务端改造成高并发模型的开发这篇内容都值得花十分钟读完。1. 一个客户端的连接就把服务端卡死了——select 到底解决了什么1.1 阻塞模型为什么难撑高并发先说阻塞 I/O 的问题。假设你用最原始的方式写一个 TCP 服务端每个客户端连接进来后服务端会调用 recv 阻塞等待客户端发数据。recv 在没有数据到达时会一直挂起CPU 就那么闲着函数不返回。如果一个客户端连上来后一直不发数据你的服务端就卡在那后续的连接永远进不来。你可能会想这还不简单每个客户端连上来就开一个线程去处理它主线程继续 accept 不就完了这确实能解决问题但代价很大。一个线程默认的栈空间在 Linux 上通常是 8MB虚拟内存1000 个客户端就是 8GB 的虚拟内存开销线程多了之后CPU 光在线程间切换就要消耗大量时间而且线程之间的同步、锁竞争又带来一堆新问题。这种一连接一线程模型在几十个连接的场景下还能用再往上走系统资源很快就撑不住了。1.2 select 模型的核心思路让内核帮你盯梢select 模型的做法完全不同它用一个线程同时监视多个 socket。你先把所有关心的 socket 放进一个集合里然后调用一次 select把集合交给内核。内核会一直盯着这些 socket只要有任意一个 socket 上有事件发生比如可读、可写、异常select 就会返回告诉你有动静了你在用户态再去找到底是哪个 socket然后处理它。打个比方阻塞模型像银行里一个柜员只能服务一个客户办完一个业务才能接待下一个select 模型则像一个智能叫号员他同时看着所有窗口谁的文件到了、谁需要签字他立刻叫对应客户过去办业务。柜员线程只有一个但办业务的效率却完全不一样。这也解释了为什么 select 是同步 I/O 模型——select 本身是阻塞等待事件但等到事件后数据的读写仍然是由你用户态自己完成的。它和真正异步 I/O 的差别在于异步模型是内核帮你把数据读好再通知你select 只是告诉你可以读了读数据还得你自己来。1.3 select 不是万能的一句话说明它的边界select 模型的位置很特殊。它是 I/O 多路复用家族里最简单、最老牌的一个。后来出现的 poll 解决了 select 的文件描述符数量上限问题更现代一点的 epollLinux和 kqueueBSD/macOS则解决了 select 在大规模并发下的性能瓶颈。但 select 依然值得学透因为几乎所有平台都支持它代码量小、逻辑直观理解了 select 再去看 epoll会轻松非常多。select 的最大边界一句话就能说明白它适合几十到几百个连接的场景连接数上千之后性能下降很明显原因我们后面展开。学它不是为了一直用它而是为了理解事件驱动这套底层思维。2. select 核心 API 拆解五个参数撑起整个服务器2.1 fd_set 与四个宏就是一张关注清单select 函数签名长这样int select( int nfds, // 被监视的最大文件描述符 1 fd_set *readfds, // 可读事件集合 fd_set *writefds, // 可写事件集合 fd_set *exceptfds, // 异常事件集合 struct timeval *timeout // 超时时间 );前四个参数的组合决定了你要监视哪些 socket 的哪些事件。先说最常用的 readfds。所有你想监视有没有数据可读的 socket都要放进这个集合。writefds 同理监视能不能写exceptfds 则监视带外数据等异常情况。不需要监视的传 NULL 即可。fd_set 本身是一张关注清单但你不能直接对 fd_set 做赋值或者组合操作必须用系统提供的四个宏FD_ZERO(fd_set*)清空整个集合FD_SET(fd, fd_set*)把某个 fd 加进集合FD_CLR(fd, fd_set*)把某个 fd 从集合中移除FD_ISSET(fd, fd_set*)检查某个 fd 在集合中是否就绪这四个宏是最容易忽略但最关键的。你每次调用 select 之前都需要把关心的 fd 重新加入集合——因为 select 返回时内核会把你传进去的 fd_set 原地改写只保留真正就绪的 fd。这也是为什么我们必须维护一个 masterSet主集合每次循环开始时把 masterSet 拷贝给 readSetselect 改的是 readSet而 masterSet 始终保持完整下次才能继续复制、继续用。底下实现上Linux 的 fd_set 是一个位图每一位对应一个 fd默认最多支持 1024 个 fdWindows 那边则是一个 socket 数组默认上限是 64。这个差异看起来小实际跨平台时坑很多我会在 2.3 节展开。还有一个容易被忽略的细节nfds 参数在 Linux 上有实际意义它告诉内核你只需要扫描从 0 到这个值之间的 fd所以你应该传最大 fd 加一在 Windows 上这个参数会被忽略传什么都可以惯例上传 0。如果你直接拿着 Windows 的代码去 Linux 编译不修改这部分很可能行为异常但不一定会立刻报错排查起来非常隐蔽。2.2 timeout 参数三种写法对应三种等待行为timeout 参数决定 select 的阻塞行为它指向一个 timeval 结构体struct timeval { long tv_sec; // 秒 long tv_usec; // 微秒 };三种典型写法传 NULLselect 永久阻塞直到至少有一个 fd 就绪才会返回。如果你期望程序在没有事件就一直等就选这个。传一个全 0 的 timevalselect 立即返回。这等于用 select 做一次非阻塞轮询配合循环使用可以写一个忙轮询的调度器不过 CPU 占用会比较高。传一个正数的 timevalselect 最多阻塞这么长时间超时则返回 0。适合做需要定期做其他事情的循环比如定时器、心跳检查、UI 响应。我自己写服务端循环时倾向于用非零超时 判断返回值。比如每隔 1 秒从 select 醒来一次检查一下本次是否超时超时就去执行清理逻辑。这也是一种常见的定时器 I/O 事件融合写法。特别提醒在 Linux 上select 返回后内核会修改你传入的 timeval把剩余等待时间写回去。如果你的循环里复用了同一个 timeval 变量第二次循环时超时时间会变成你剩余的时间可能越来越短甚至变 0。所以我每次循环都会重新给 tv_sec 和 tv_usec 赋值这个习惯建议你一上来就养成。2.3 Windows 与 Linux 的行为差异必须分清我在实际写代码时经常要来回切换 Windows 和 Linux 两个平台。select 模型在这两个平台上的代码兼容性并不像看起来那么好下面这张表是我踩过坑之后整理出来的差异点WindowsWinsockLinuxPOSIX socket头文件winsock2.h且需 WSAStartup 初始化sys/socket.h无需初始化socket 类型SOCKET本身就是无符号整数int关闭 socketclosesocket()close()select 第一个参数无意义传 0最大 fd 1fd_set 默认上限641024错误码获取WSAGetLastError()errno非阻塞设置ioctlsocket(sock, FIONBIO, mode)fcntl(fd, F_SETFL, flags | O_NONBLOCK)timeval 是否被 select 改写否是操作对象范围仅限 socket文件、管道、终端等一切 fd这些差异里最隐蔽的是 timeval 改写和第一个参数。我的经验是写 select 代码时从一开始就分开维护 Windows 分支和 Linux 分支的代码可以用条件编译也可以直接把平台相关部分抽成接口不要指望一份代码在两个平台无差别编译。3. 从零写一个 select 聊天服务器完整代码逐段讲透3.1 完整代码示例Windows 平台C 语言下面这段代码我实际测试过实现的是一个最简单的 广播聊天室 服务端多个客户端连接后任何一个客户端发送消息服务端都会把这个消息转发给所有其他客户端。为了聚焦 select 的核心逻辑我把错误处理中的很多打印都精简了但关键分支一个不少。#include winsock2.h #include stdio.h #pragma comment(lib, ws2_32.lib) #define PORT 8888 #define BUFFER_SIZE 1024 #define MAX_CLIENTS 64 int main(void) { WSADATA wsaData; SOCKET listenSock INVALID_SOCKET; SOCKET clientSock; struct sockaddr_in serverAddr, clientAddr; int addrLen sizeof(clientAddr); char buf[BUFFER_SIZE]; ulong ulMode 1; int i, ret, bytesRecv; // 1. 初始化 Winsock 库 if (WSAStartup(MAKEWORD(2, 2), wsaData) ! 0) { printf(WSAStartup failed\n); return -1; } // 2. 创建监听 socket listenSock socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (listenSock INVALID_SOCKET) { printf(socket failed: %d\n, WSAGetLastError()); WSACleanup(); return -1; } serverAddr.sin_family AF_INET; serverAddr.sin_addr.s_addr htonl(INADDR_ANY); serverAddr.sin_port htons(PORT); if (bind(listenSock, (struct sockaddr*)serverAddr, sizeof(serverAddr)) SOCKET_ERROR) { printf(bind failed: %d\n, WSAGetLastError()); closesocket(listenSock); WSACleanup(); return -1; } if (listen(listenSock, 10) SOCKET_ERROR) { printf(listen failed: %d\n, WSAGetLastError()); closesocket(listenSock); WSACleanup(); return -1; } // 3. 主集合初始化把监听 socket 加进去 fd_set masterSet, readSet; FD_ZERO(masterSet); FD_SET(listenSock, masterSet); SOCKET maxSock listenSock; printf(聊天服务器已启动监听端口 %d\n, PORT); // 4. select 主循环 while (1) { readSet masterSet; // 每次从主集合复制因为 select 会改写 readSet struct timeval tv; tv.tv_sec 1; tv.tv_usec 0; ret select(maxSock 1, readSet, NULL, NULL, tv); if (ret SOCKET_ERROR) { printf(select error: %d\n, WSAGetLastError()); break; } if (ret 0) { // 超时没事件可以做点例行清理 continue; } // 4.1 监听 socket 可读 有新连接 if (FD_ISSET(listenSock, readSet)) { clientSock accept(listenSock, (struct sockaddr*)clientAddr, addrLen); if (clientSock ! INVALID_SOCKET) { // 把新 socket 设为非阻塞避免一个慢客户端拖垮整个循环 ioctlsocket(clientSock, FIONBIO, ulMode); FD_SET(clientSock, masterSet); if (clientSock maxSock) { maxSock clientSock; } printf(客户端 %d 已连接\n, clientSock); } } // 4.2 遍历所有客户端处理可读事件 // 注意先在循环里收集需要关闭的 socket循环结束后再统一清理 SOCKET toClose[MAX_CLIENTS]; int closeCount 0; for (i 0; i maxSock; i) { if (i listenSock) { continue; } if (!FD_ISSET(i, readSet)) { continue; } bytesRecv recv(i, buf, BUFFER_SIZE, 0); if (bytesRecv 0) { // 收到数据广播给其他客户端 for (int j 0; j maxSock; j) { if (j listenSock || j i) { continue; } if (FD_ISSET(j, masterSet)) { send(j, buf, bytesRecv, 0); } } } else if (bytesRecv 0) { // 对端关闭连接 printf(客户端 %d 断开连接\n, i); toClose[closeCount] i; } else { int err WSAGetLastError(); if (err WSAEWOULDBLOCK) { continue; // 非阻塞模式下没数据可读跳过 } printf(客户端 %d 接收错误: %d\n, i, err); toClose[closeCount] i; } } // 统一清理已关闭的 socket for (int k 0; k closeCount; k) { closesocket(toClose[k]); FD_CLR(toClose[k], masterSet); } } closesocket(listenSock); WSACleanup(); return 0; }3.2 主循环的复制集合和重新装配逻辑很多第一次写 select 的人会有一个疑问为什么每次循环都要readSet masterSet复制一遍因为 select 内部会直接修改你传入的 fd_set——把没有就绪的 fd 从集合中清掉只保留就绪的 fd。如果你复用一个 readSet 不放回去第二次调用 select 时这个集合里只剩上次就绪的 fd其他 fd 全丢了等于失踪了一批客户端。正确做法就是我代码里的那样masterSet 永远保存所有连接的完整清单每次 select 之前把它复制一份给 readSetselect 返回后再从 readSet 里用 FD_ISSET 逐个检查谁就绪了。这个一份主清单 一份工作副本的思路是整个 select 模型代码结构的核心骨架记住它你就能看懂绝大部分 select 服务端代码。3.3 事件到来之后判断分支是关键中的关键select 返回正整数时说明至少有 n 个 fd 就绪这些 fd 都留在 readSet 里。你现在要做的事就是遍历 判断 分类处理。先说监听 socket。如果 listenSock 在 readSet 里说明有新的客户端发起了连接请求你必须调用 accept 去完成三次握手后的接入。这里有一个小细节即使 accept 失败比如客户端在刚连上就断开也不应该影响主循环继续跑所以代码里我做了 INVALID_SOCKET 检查。再说客户端 socket。遍历时遇到某个 fd 就绪就调用 recv 读取数据。返回值的处理我有三条分支bytesRecv 0拿到数据正常处理。bytesRecv 0对端主动关闭了连接走的是正常的四次挥手这个分支必须处理否则 fd 会一直留在集合里连接泄漏。bytesRecv SOCKET_ERROR出错。这里要区分暂不可读和连接真断了。非阻塞模式下如果当前没有数据可读recv 会返回 SOCKET_ERROR 并且WSAGetLastError() WSAEWOULDBLOCK这种属于正常情况跳过即可其他错误码比如 WSAECONNRESET对端强制关闭就应该当连接断开处理。有一个经验我要单独强调不要在 for 循环遍历时立刻 closesocket 并 FD_CLR。因为 closesocket 之后这个句柄可能会被系统回收如果循环还没走完新的连接可能复用了同一个句柄值导致误判。我代码里的做法是先把待关闭的 socket 收集到一个数组等遍历结束再统一处理这个习惯让我少踩了很多隐蔽 bug。3.4 非阻塞模式select 模型里不能省的配置这节代码里我给每个新接入的客户端 socket 都调用了 ioctlsocket 设置为非阻塞模式。为什么因为 select 只负责有事件的通知但它不保证你处理这批事件时不阻塞。举个例子select 告诉你 10 个 socket 都可读你开始逐个 recv。正常情况下每次 recv 都能立刻读到数据不会卡。但如果某个客户端接收窗口太小或者它连接异常了阻塞模式下 recv 可能在下一次没有数据时挂起这一挂后面 9 个客户端的数据全被耽误了。而非阻塞模式下recv 没数据会立刻返回 WSAEWOULDBLOCK你继续处理下一个就行。同理send 在阻塞模式下也可能因为发送缓冲区满而阻塞这一阻塞同样会拖死整个 select 循环。所以在新连接接入时就把 socket 设为非阻塞是我写 select 服务端的默认操作建议你也这么做。4. 说多了都是泪select 实战容易踩的 7 个坑4.1 fd 数量天花板默认 64 还是 1024fd_set 的容量限制是 select 最著名的硬伤。Windows 上用 select 最多只能同时监视 64 个 socketLinux 上默认是 1024 个 fd。超过上限的 socket 根本加不进集合select 会直接返回错误或者行为诡异。有人说我重新定义 FD_SETSIZE 不就行了在 Windows 上你必须把 FD_SETSIZE 宏定义在包含 winsock2.h 之前而且即使你定义成 1024新版本的 Winsock 内部还是按照 64 个来管理数组的某些逻辑实测并不可靠。Linux 上你可以改 FD_SETSIZE 再重新编译内核但那样会扩大位图的内存占用1000 个连接可能就要多拷贝几十字节性能反而更差。我的建议是连接数超过几百的场景就别硬撑 select 了直接考虑 poll 或 epoll。select 适合的是中小规模连接、代码要极简、跨平台需求强的场景。4.2 timeval 被内核悄悄改写后的离奇超时在 Linux 平台上select 返回后timeval 会被内核更新为剩余时间。如果循环里复用同一个 timeval 变量而不重新赋值你会发现 select 的超时时间越来短最后变成 0循环变成忙轮询CPU 占用率飙到 100%。我记得第一次遇到这个问题时找了整整一下午最后打印每个循环里 tv 的值才发现它每次都在变小。从那以后我写 select 的循环体都会先重新给 tv 的秒和微秒字段赋值只在 select 调用前才填值。4.3 recv 返回 0 和 WSAECONNRESET连接断开的两种姿势recv 返回 0 表示对端正常关闭连接走的是 FIN 包四次挥手流程说明对面主动说再见了。WSAECONNRESET 则不一样它通常意味着对端直接 RST——比如客户端进程崩溃、网络异常或者对端在收到数据前就强行关掉了 socket。你的服务端如果在 recv 时只判断bytesRecv 0不处理这两种情况那么失效的连接会永远留在 masterSet 里select 每次都会因为这个已断开的 fd 仍然就绪而疯狂返回形成死循环式的 CPU 消耗。正确的做法就是我在代码里展示的bytesRecv 0和WSAGetLastError() WSAECONNRESET都走关闭连接 移出集合的逻辑。4.4 更多坑点速查表坑点现象解决办法winsock2.h 与 windows.h 顺序冲突编译报一堆重定义错误在包含 windows.h 前定义 WIN32_LEAN_AND_MEAN或先包含 winsock2.hwritefds 集合常驻select 每次都立刻返回CPU 打满只在 send 返回 WSAEWOULDBLOCK 时临时把该 fd 加入 writefds忘记处理 EINTRLinux 下 select 被信号中断返回 -1没有作判断导致退出判断ret 0 errno EINTR时 continue对端断开后继续 sendLinux 程序因 SIGPIPE 直接退出忽略 SIGPIPE 信号或 send 时用 MSG_NOSIGNAL遍历时关闭 socket句柄被复用新连接莫名其妙被误杀延迟清理遍历结束后统一关闭多个线程同时 select 同一 fd惊群效应多个线程同时被唤醒避免多线程同时 select 同一个 fd必要时用锁或拆分为多路 select速查表里第五个坑我再展开一下。句柄复用问题在 select 里特别隐蔽你在循环里 closesocket 了一个 fd紧接着 accept 了一个新连接新连接可能拿到同一个 fd 编号。但你的 for 循环还没结束继续遍历时碰到这个 fd再执行 FD_ISSET 就可能触发错误逻辑导致新连接被误关闭。解决办法就是我在代码里用 toClose 数组做延迟清理。4.5 一个调试利器两个 telnet 模拟多客户端实际测试 select 服务端时你不需要马上写客户端代码。用系统自带的 telnet 就能模拟多个客户端连接开两个 cmd 窗口都执行telnet 127.0.0.1 8888在窗口 A 输入一行文本回车另一窗口 B 应该立刻收到直接关闭窗口 A服务端应打印客户端断开连接这个办法速度快、直观我在开发阶段反复用它验证 select 的事件循环逻辑。你也可以结合netstat -ano | findstr 8888查看当前连接状态确认 accept 和关闭操作是否符合预期。5. 写在最后的实战体会select 模型在今天看起来确实有点老古董epoll 和 io_uring 在 Linux 上明显更强但它在我的学习路径里价值极高——它把事件驱动这个思维模型完整地装进了我的脑子里。很多人一上来就啃 epoll结果被回调、就绪列表、水平触发和边缘触发的概念绕晕反而是先写一遍 select再去看 epoll理解成本直接降一半。我个人在实际操作中的体会是select 代码虽然琐碎但它逼着你把 fd 集合的维护、延迟关闭、非阻塞处理这些网络编程基本功都练扎实了。踩过的那些坑——timeval 被改、句柄复用、WSAECONNRESET——在以后写任何网络服务时都用得上。最后再分享一个小技巧在你第一次跑通 select 服务器后试着故意制造异常场景比如让客户端不按常理直接断电、让服务端连续发送大量数据。这种故意搞坏的测试方式能让你对这个模型的边界理解得更深。 
长河君 · 2026/10/20 1:54:22 · 阅读 1.2k 深入浅出select模型：从阻塞I/O到高并发TCP服务端
我最早被网络编程虐到怀疑人生就是因为不理解 select 模型。那时我写了一个极简的 TCP 服务端用阻塞 socket 加一个死循环处理客户端请求结果只有一个客户端连上来还好一旦第二个客户端接入第一个客户端立刻失联。后来我才明白这个问题的根源就是一个阻塞的 recv 调用会独占整个执行流服务端在同一时刻只能服务一个连接。解决这个问题的经典方案就是 I/O 多路复用模型而 select 模型就是其中最基础、几乎每个平台都支持的那一套。它让一个线程能同时监视多个 socket 的可读、可写、异常事件内核有事件发生时才通知你处理。今天这篇博文我会从问题拆解、核心 API 用法、完整可运行的代码示例、再到我实际踩过的一堆坑把 select 模型一次讲透。无论你是刚入门 socket 编程的新手还是想把阻塞式服务端改造成高并发模型的开发这篇内容都值得花十分钟读完。1. 一个客户端的连接就把服务端卡死了——select 到底解决了什么1.1 阻塞模型为什么难撑高并发先说阻塞 I/O 的问题。假设你用最原始的方式写一个 TCP 服务端每个客户端连接进来后服务端会调用 recv 阻塞等待客户端发数据。recv 在没有数据到达时会一直挂起CPU 就那么闲着函数不返回。如果一个客户端连上来后一直不发数据你的服务端就卡在那后续的连接永远进不来。你可能会想这还不简单每个客户端连上来就开一个线程去处理它主线程继续 accept 不就完了这确实能解决问题但代价很大。一个线程默认的栈空间在 Linux 上通常是 8MB虚拟内存1000 个客户端就是 8GB 的虚拟内存开销线程多了之后CPU 光在线程间切换就要消耗大量时间而且线程之间的同步、锁竞争又带来一堆新问题。这种一连接一线程模型在几十个连接的场景下还能用再往上走系统资源很快就撑不住了。1.2 select 模型的核心思路让内核帮你盯梢select 模型的做法完全不同它用一个线程同时监视多个 socket。你先把所有关心的 socket 放进一个集合里然后调用一次 select把集合交给内核。内核会一直盯着这些 socket只要有任意一个 socket 上有事件发生比如可读、可写、异常select 就会返回告诉你有动静了你在用户态再去找到底是哪个 socket然后处理它。打个比方阻塞模型像银行里一个柜员只能服务一个客户办完一个业务才能接待下一个select 模型则像一个智能叫号员他同时看着所有窗口谁的文件到了、谁需要签字他立刻叫对应客户过去办业务。柜员线程只有一个但办业务的效率却完全不一样。这也解释了为什么 select 是同步 I/O 模型——select 本身是阻塞等待事件但等到事件后数据的读写仍然是由你用户态自己完成的。它和真正异步 I/O 的差别在于异步模型是内核帮你把数据读好再通知你select 只是告诉你可以读了读数据还得你自己来。1.3 select 不是万能的一句话说明它的边界select 模型的位置很特殊。它是 I/O 多路复用家族里最简单、最老牌的一个。后来出现的 poll 解决了 select 的文件描述符数量上限问题更现代一点的 epollLinux和 kqueueBSD/macOS则解决了 select 在大规模并发下的性能瓶颈。但 select 依然值得学透因为几乎所有平台都支持它代码量小、逻辑直观理解了 select 再去看 epoll会轻松非常多。select 的最大边界一句话就能说明白它适合几十到几百个连接的场景连接数上千之后性能下降很明显原因我们后面展开。学它不是为了一直用它而是为了理解事件驱动这套底层思维。2. select 核心 API 拆解五个参数撑起整个服务器2.1 fd_set 与四个宏就是一张关注清单select 函数签名长这样int select( int nfds, // 被监视的最大文件描述符 1 fd_set *readfds, // 可读事件集合 fd_set *writefds, // 可写事件集合 fd_set *exceptfds, // 异常事件集合 struct timeval *timeout // 超时时间 );前四个参数的组合决定了你要监视哪些 socket 的哪些事件。先说最常用的 readfds。所有你想监视有没有数据可读的 socket都要放进这个集合。writefds 同理监视能不能写exceptfds 则监视带外数据等异常情况。不需要监视的传 NULL 即可。fd_set 本身是一张关注清单但你不能直接对 fd_set 做赋值或者组合操作必须用系统提供的四个宏FD_ZERO(fd_set*)清空整个集合FD_SET(fd, fd_set*)把某个 fd 加进集合FD_CLR(fd, fd_set*)把某个 fd 从集合中移除FD_ISSET(fd, fd_set*)检查某个 fd 在集合中是否就绪这四个宏是最容易忽略但最关键的。你每次调用 select 之前都需要把关心的 fd 重新加入集合——因为 select 返回时内核会把你传进去的 fd_set 原地改写只保留真正就绪的 fd。这也是为什么我们必须维护一个 masterSet主集合每次循环开始时把 masterSet 拷贝给 readSetselect 改的是 readSet而 masterSet 始终保持完整下次才能继续复制、继续用。底下实现上Linux 的 fd_set 是一个位图每一位对应一个 fd默认最多支持 1024 个 fdWindows 那边则是一个 socket 数组默认上限是 64。这个差异看起来小实际跨平台时坑很多我会在 2.3 节展开。还有一个容易被忽略的细节nfds 参数在 Linux 上有实际意义它告诉内核你只需要扫描从 0 到这个值之间的 fd所以你应该传最大 fd 加一在 Windows 上这个参数会被忽略传什么都可以惯例上传 0。如果你直接拿着 Windows 的代码去 Linux 编译不修改这部分很可能行为异常但不一定会立刻报错排查起来非常隐蔽。2.2 timeout 参数三种写法对应三种等待行为timeout 参数决定 select 的阻塞行为它指向一个 timeval 结构体struct timeval { long tv_sec; // 秒 long tv_usec; // 微秒 };三种典型写法传 NULLselect 永久阻塞直到至少有一个 fd 就绪才会返回。如果你期望程序在没有事件就一直等就选这个。传一个全 0 的 timevalselect 立即返回。这等于用 select 做一次非阻塞轮询配合循环使用可以写一个忙轮询的调度器不过 CPU 占用会比较高。传一个正数的 timevalselect 最多阻塞这么长时间超时则返回 0。适合做需要定期做其他事情的循环比如定时器、心跳检查、UI 响应。我自己写服务端循环时倾向于用非零超时 判断返回值。比如每隔 1 秒从 select 醒来一次检查一下本次是否超时超时就去执行清理逻辑。这也是一种常见的定时器 I/O 事件融合写法。特别提醒在 Linux 上select 返回后内核会修改你传入的 timeval把剩余等待时间写回去。如果你的循环里复用了同一个 timeval 变量第二次循环时超时时间会变成你剩余的时间可能越来越短甚至变 0。所以我每次循环都会重新给 tv_sec 和 tv_usec 赋值这个习惯建议你一上来就养成。2.3 Windows 与 Linux 的行为差异必须分清我在实际写代码时经常要来回切换 Windows 和 Linux 两个平台。select 模型在这两个平台上的代码兼容性并不像看起来那么好下面这张表是我踩过坑之后整理出来的差异点WindowsWinsockLinuxPOSIX socket头文件winsock2.h且需 WSAStartup 初始化sys/socket.h无需初始化socket 类型SOCKET本身就是无符号整数int关闭 socketclosesocket()close()select 第一个参数无意义传 0最大 fd 1fd_set 默认上限641024错误码获取WSAGetLastError()errno非阻塞设置ioctlsocket(sock, FIONBIO, mode)fcntl(fd, F_SETFL, flags | O_NONBLOCK)timeval 是否被 select 改写否是操作对象范围仅限 socket文件、管道、终端等一切 fd这些差异里最隐蔽的是 timeval 改写和第一个参数。我的经验是写 select 代码时从一开始就分开维护 Windows 分支和 Linux 分支的代码可以用条件编译也可以直接把平台相关部分抽成接口不要指望一份代码在两个平台无差别编译。3. 从零写一个 select 聊天服务器完整代码逐段讲透3.1 完整代码示例Windows 平台C 语言下面这段代码我实际测试过实现的是一个最简单的 广播聊天室 服务端多个客户端连接后任何一个客户端发送消息服务端都会把这个消息转发给所有其他客户端。为了聚焦 select 的核心逻辑我把错误处理中的很多打印都精简了但关键分支一个不少。#include winsock2.h #include stdio.h #pragma comment(lib, ws2_32.lib) #define PORT 8888 #define BUFFER_SIZE 1024 #define MAX_CLIENTS 64 int main(void) { WSADATA wsaData; SOCKET listenSock INVALID_SOCKET; SOCKET clientSock; struct sockaddr_in serverAddr, clientAddr; int addrLen sizeof(clientAddr); char buf[BUFFER_SIZE]; ulong ulMode 1; int i, ret, bytesRecv; // 1. 初始化 Winsock 库 if (WSAStartup(MAKEWORD(2, 2), wsaData) ! 0) { printf(WSAStartup failed\n); return -1; } // 2. 创建监听 socket listenSock socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (listenSock INVALID_SOCKET) { printf(socket failed: %d\n, WSAGetLastError()); WSACleanup(); return -1; } serverAddr.sin_family AF_INET; serverAddr.sin_addr.s_addr htonl(INADDR_ANY); serverAddr.sin_port htons(PORT); if (bind(listenSock, (struct sockaddr*)serverAddr, sizeof(serverAddr)) SOCKET_ERROR) { printf(bind failed: %d\n, WSAGetLastError()); closesocket(listenSock); WSACleanup(); return -1; } if (listen(listenSock, 10) SOCKET_ERROR) { printf(listen failed: %d\n, WSAGetLastError()); closesocket(listenSock); WSACleanup(); return -1; } // 3. 主集合初始化把监听 socket 加进去 fd_set masterSet, readSet; FD_ZERO(masterSet); FD_SET(listenSock, masterSet); SOCKET maxSock listenSock; printf(聊天服务器已启动监听端口 %d\n, PORT); // 4. select 主循环 while (1) { readSet masterSet; // 每次从主集合复制因为 select 会改写 readSet struct timeval tv; tv.tv_sec 1; tv.tv_usec 0; ret select(maxSock 1, readSet, NULL, NULL, tv); if (ret SOCKET_ERROR) { printf(select error: %d\n, WSAGetLastError()); break; } if (ret 0) { // 超时没事件可以做点例行清理 continue; } // 4.1 监听 socket 可读 有新连接 if (FD_ISSET(listenSock, readSet)) { clientSock accept(listenSock, (struct sockaddr*)clientAddr, addrLen); if (clientSock ! INVALID_SOCKET) { // 把新 socket 设为非阻塞避免一个慢客户端拖垮整个循环 ioctlsocket(clientSock, FIONBIO, ulMode); FD_SET(clientSock, masterSet); if (clientSock maxSock) { maxSock clientSock; } printf(客户端 %d 已连接\n, clientSock); } } // 4.2 遍历所有客户端处理可读事件 // 注意先在循环里收集需要关闭的 socket循环结束后再统一清理 SOCKET toClose[MAX_CLIENTS]; int closeCount 0; for (i 0; i maxSock; i) { if (i listenSock) { continue; } if (!FD_ISSET(i, readSet)) { continue; } bytesRecv recv(i, buf, BUFFER_SIZE, 0); if (bytesRecv 0) { // 收到数据广播给其他客户端 for (int j 0; j maxSock; j) { if (j listenSock || j i) { continue; } if (FD_ISSET(j, masterSet)) { send(j, buf, bytesRecv, 0); } } } else if (bytesRecv 0) { // 对端关闭连接 printf(客户端 %d 断开连接\n, i); toClose[closeCount] i; } else { int err WSAGetLastError(); if (err WSAEWOULDBLOCK) { continue; // 非阻塞模式下没数据可读跳过 } printf(客户端 %d 接收错误: %d\n, i, err); toClose[closeCount] i; } } // 统一清理已关闭的 socket for (int k 0; k closeCount; k) { closesocket(toClose[k]); FD_CLR(toClose[k], masterSet); } } closesocket(listenSock); WSACleanup(); return 0; }3.2 主循环的复制集合和重新装配逻辑很多第一次写 select 的人会有一个疑问为什么每次循环都要readSet masterSet复制一遍因为 select 内部会直接修改你传入的 fd_set——把没有就绪的 fd 从集合中清掉只保留就绪的 fd。如果你复用一个 readSet 不放回去第二次调用 select 时这个集合里只剩上次就绪的 fd其他 fd 全丢了等于失踪了一批客户端。正确做法就是我代码里的那样masterSet 永远保存所有连接的完整清单每次 select 之前把它复制一份给 readSetselect 返回后再从 readSet 里用 FD_ISSET 逐个检查谁就绪了。这个一份主清单 一份工作副本的思路是整个 select 模型代码结构的核心骨架记住它你就能看懂绝大部分 select 服务端代码。3.3 事件到来之后判断分支是关键中的关键select 返回正整数时说明至少有 n 个 fd 就绪这些 fd 都留在 readSet 里。你现在要做的事就是遍历 判断 分类处理。先说监听 socket。如果 listenSock 在 readSet 里说明有新的客户端发起了连接请求你必须调用 accept 去完成三次握手后的接入。这里有一个小细节即使 accept 失败比如客户端在刚连上就断开也不应该影响主循环继续跑所以代码里我做了 INVALID_SOCKET 检查。再说客户端 socket。遍历时遇到某个 fd 就绪就调用 recv 读取数据。返回值的处理我有三条分支bytesRecv 0拿到数据正常处理。bytesRecv 0对端主动关闭了连接走的是正常的四次挥手这个分支必须处理否则 fd 会一直留在集合里连接泄漏。bytesRecv SOCKET_ERROR出错。这里要区分暂不可读和连接真断了。非阻塞模式下如果当前没有数据可读recv 会返回 SOCKET_ERROR 并且WSAGetLastError() WSAEWOULDBLOCK这种属于正常情况跳过即可其他错误码比如 WSAECONNRESET对端强制关闭就应该当连接断开处理。有一个经验我要单独强调不要在 for 循环遍历时立刻 closesocket 并 FD_CLR。因为 closesocket 之后这个句柄可能会被系统回收如果循环还没走完新的连接可能复用了同一个句柄值导致误判。我代码里的做法是先把待关闭的 socket 收集到一个数组等遍历结束再统一处理这个习惯让我少踩了很多隐蔽 bug。3.4 非阻塞模式select 模型里不能省的配置这节代码里我给每个新接入的客户端 socket 都调用了 ioctlsocket 设置为非阻塞模式。为什么因为 select 只负责有事件的通知但它不保证你处理这批事件时不阻塞。举个例子select 告诉你 10 个 socket 都可读你开始逐个 recv。正常情况下每次 recv 都能立刻读到数据不会卡。但如果某个客户端接收窗口太小或者它连接异常了阻塞模式下 recv 可能在下一次没有数据时挂起这一挂后面 9 个客户端的数据全被耽误了。而非阻塞模式下recv 没数据会立刻返回 WSAEWOULDBLOCK你继续处理下一个就行。同理send 在阻塞模式下也可能因为发送缓冲区满而阻塞这一阻塞同样会拖死整个 select 循环。所以在新连接接入时就把 socket 设为非阻塞是我写 select 服务端的默认操作建议你也这么做。4. 说多了都是泪select 实战容易踩的 7 个坑4.1 fd 数量天花板默认 64 还是 1024fd_set 的容量限制是 select 最著名的硬伤。Windows 上用 select 最多只能同时监视 64 个 socketLinux 上默认是 1024 个 fd。超过上限的 socket 根本加不进集合select 会直接返回错误或者行为诡异。有人说我重新定义 FD_SETSIZE 不就行了在 Windows 上你必须把 FD_SETSIZE 宏定义在包含 winsock2.h 之前而且即使你定义成 1024新版本的 Winsock 内部还是按照 64 个来管理数组的某些逻辑实测并不可靠。Linux 上你可以改 FD_SETSIZE 再重新编译内核但那样会扩大位图的内存占用1000 个连接可能就要多拷贝几十字节性能反而更差。我的建议是连接数超过几百的场景就别硬撑 select 了直接考虑 poll 或 epoll。select 适合的是中小规模连接、代码要极简、跨平台需求强的场景。4.2 timeval 被内核悄悄改写后的离奇超时在 Linux 平台上select 返回后timeval 会被内核更新为剩余时间。如果循环里复用同一个 timeval 变量而不重新赋值你会发现 select 的超时时间越来短最后变成 0循环变成忙轮询CPU 占用率飙到 100%。我记得第一次遇到这个问题时找了整整一下午最后打印每个循环里 tv 的值才发现它每次都在变小。从那以后我写 select 的循环体都会先重新给 tv 的秒和微秒字段赋值只在 select 调用前才填值。4.3 recv 返回 0 和 WSAECONNRESET连接断开的两种姿势recv 返回 0 表示对端正常关闭连接走的是 FIN 包四次挥手流程说明对面主动说再见了。WSAECONNRESET 则不一样它通常意味着对端直接 RST——比如客户端进程崩溃、网络异常或者对端在收到数据前就强行关掉了 socket。你的服务端如果在 recv 时只判断bytesRecv 0不处理这两种情况那么失效的连接会永远留在 masterSet 里select 每次都会因为这个已断开的 fd 仍然就绪而疯狂返回形成死循环式的 CPU 消耗。正确的做法就是我在代码里展示的bytesRecv 0和WSAGetLastError() WSAECONNRESET都走关闭连接 移出集合的逻辑。4.4 更多坑点速查表坑点现象解决办法winsock2.h 与 windows.h 顺序冲突编译报一堆重定义错误在包含 windows.h 前定义 WIN32_LEAN_AND_MEAN或先包含 winsock2.hwritefds 集合常驻select 每次都立刻返回CPU 打满只在 send 返回 WSAEWOULDBLOCK 时临时把该 fd 加入 writefds忘记处理 EINTRLinux 下 select 被信号中断返回 -1没有作判断导致退出判断ret 0 errno EINTR时 continue对端断开后继续 sendLinux 程序因 SIGPIPE 直接退出忽略 SIGPIPE 信号或 send 时用 MSG_NOSIGNAL遍历时关闭 socket句柄被复用新连接莫名其妙被误杀延迟清理遍历结束后统一关闭多个线程同时 select 同一 fd惊群效应多个线程同时被唤醒避免多线程同时 select 同一个 fd必要时用锁或拆分为多路 select速查表里第五个坑我再展开一下。句柄复用问题在 select 里特别隐蔽你在循环里 closesocket 了一个 fd紧接着 accept 了一个新连接新连接可能拿到同一个 fd 编号。但你的 for 循环还没结束继续遍历时碰到这个 fd再执行 FD_ISSET 就可能触发错误逻辑导致新连接被误关闭。解决办法就是我在代码里用 toClose 数组做延迟清理。4.5 一个调试利器两个 telnet 模拟多客户端实际测试 select 服务端时你不需要马上写客户端代码。用系统自带的 telnet 就能模拟多个客户端连接开两个 cmd 窗口都执行telnet 127.0.0.1 8888在窗口 A 输入一行文本回车另一窗口 B 应该立刻收到直接关闭窗口 A服务端应打印客户端断开连接这个办法速度快、直观我在开发阶段反复用它验证 select 的事件循环逻辑。你也可以结合netstat -ano | findstr 8888查看当前连接状态确认 accept 和关闭操作是否符合预期。5. 写在最后的实战体会select 模型在今天看起来确实有点老古董epoll 和 io_uring 在 Linux 上明显更强但它在我的学习路径里价值极高——它把事件驱动这个思维模型完整地装进了我的脑子里。很多人一上来就啃 epoll结果被回调、就绪列表、水平触发和边缘触发的概念绕晕反而是先写一遍 select再去看 epoll理解成本直接降一半。我个人在实际操作中的体会是select 代码虽然琐碎但它逼着你把 fd 集合的维护、延迟关闭、非阻塞处理这些网络编程基本功都练扎实了。踩过的那些坑——timeval 被改、句柄复用、WSAECONNRESET——在以后写任何网络服务时都用得上。最后再分享一个小技巧在你第一次跑通 select 服务器后试着故意制造异常场景比如让客户端不按常理直接断电、让服务端连续发送大量数据。这种故意搞坏的测试方式能让你对这个模型的边界理解得更深。