简介：在Windows平台上，用C++实现单线程同时监听多个端口，是一种基于IOCP的高性能网络编程思路，面向需要减少线程切换、提升并发吞吐量的socket开发者。资源以zip压缩包提供，共2个文件，包括1个cpp与1个h源码，压缩包仅3KB，代码量精简，便于快速定位核心逻辑。已有1649人学习下载。IocpAccept.cpp与IocpAccept.h完整展示了创建IOCP、将多个监听套接字关联到同一完成端口、通过GetQueuedCompletionStatus循环分发事件等关键流程；同时涉及WSARecvFrom/WSAConnect异步接收设置、OVERLAPPED结构体管理I/O状态、错误处理与内存管理细节，可帮助读者在真实项目中避开常见坑。适合已掌握基本socket编程、希望深入理解Windows异步I/O模型的开发者参考。
1. 一个反直觉的问题：单线程怎么同时等住多个端口
先把结论放在前面：Windows 平台上，一个线程确实可以同时监听多个端口，而且代码量比你想象的小得多。核心不是把 accept 变成非阻塞，而是换一套等待机制——select。很多第一次写 socket 服务的开发者都会卡在这里：accept 明明是阻塞的，调了第一个就卡死，后面的端口怎么等？如果把 accept 放到多线程里，每个端口一个线程，又觉得太重了。其实 C++ 里用 select 这套 API，可以做到一个线程同时盯住多个监听 socket，哪个端口来了连接就处理哪个。
这系列代码适合谁？适合正在写 Windows 下的网络服务、想避免「一个端口一个线程」这种笨办法的开发者；也适合想弄懂 select 到底怎么用、fd_set 到底是什么的人。看完你会得到一个能直接编译运行的多端口监听骨架，还能学会怎么把它改造成实际能用的服务框架。
2. 技术底座：为什么是 select 而不是其他模型
2.1 核心矛盾：accept 是阻塞的，怎么同时等多个端口
问题的根源在于 accept 的阻塞特性。当你对一个监听 socket 调用 accept 时，如果当前没有客户端连接进来，这个调用会卡住，直到有连接到达才返回。单线程下连续调用两次 accept，只会处理第一个端口，第二个端口永远等不到。
这是一个「事件等待」的问题，而不是「连接处理」的问题。既然 accept 会阻塞，那就不能直接在主逻辑里调用它，需要有一个机制让线程同时等待多个 socket 上是否有「可接受」事件。select 就是干这个的：你把一堆 socket 交给它，它帮你盯着，一旦其中有任何一个变得「可读」，它就返回告诉你哪个 socket 有动静。
放在多端口监听的场景里，「可读」的含义对监听 socket 来说是「有新的连接请求到达」；对已连接的 socket 来说是「对端发来了数据」。select 一次调用能同时处理这两种情况。
2.2 Windows 上为什么选择 select 而不是 IOCP 或 WSAEventSelect
提到 Windows 高性能网络编程，很多人第一反应是 IOCP（完成端口）。但 IOCP 是重量级方案，适合几千上万个连接的服务端，代码复杂度高，涉及完成键、工作者线程、重叠 I/O 这些概念。对于「同时监听几个端口」这个需求，IOCP 是杀鸡用牛刀。
WSAEventSelect 是把 socket 事件绑定到事件对象上，然后用 WaitForMultipleObjects 等待事件。这套模型比 select 精细，但有个限制：WaitForMultipleObjects 最多同时等待 64 个事件对象，超过就麻烦。而且代码里要管理事件对象数组和 socket 的映射关系，复杂度不低。
select 的取舍很明确：上限是 FD_SETSIZE（默认 64）个 socket，对「同时监听多个端口」够用；代码短，可读性强；调试时通过 WSAGetLastError 拿错误码，心智负担小。注意一点：Windows 的 select 和 Linux 的 select 行为基本一致，但 Windows 上 select 的第一个参数会被忽略，传 0 就行，不需要像 Linux 那样传最大 fd 加一。
2.3 打开非阻塞模式：让 accept 不会傻等
select 能告诉我们「有连接来了」，但调用 accept 时还是可能因为竞态条件而阻塞。常见做法是把监听 socket 设为非阻塞模式，这样即使 select 返回了但连接已经被别的线程（或别的 select 轮次）取走，accept 也会立即返回失败，而不是卡死线程。
代码块：设置非阻塞模式
#include <winsock2.h> #include <windows.h> bool SetNonBlocking(SOCKET s) { u_long mode = 1; // 1 表示非阻塞，0 表示阻塞 int ret = ioctlsocket(s, FIONBIO, &mode); if (ret == SOCKET_ERROR) { // 这里要立刻用 WSAGetLastError 拿错误码，常见的是 WSAENOTSOCK return false; } return true; }先用ioctlsocket配合FIONBIO指令把 socket 切到非阻塞模式。mode = 1是非阻塞，mode = 0是恢复阻塞。这个调用失败时，多半是 socket 句柄已经失效，或者传入的不是 socket 而是普通文件句柄。设置失败不要继续往下走，否则后面 accept 会不可控地卡住。
3. 核心实现：select + fd_set 的单线程监听器
3.1 基础结构：用数组维护多个监听 socket
既然要监听多个端口，首先得把这些 socket 放在一个统一的地方管理。同时，为了复用同一个 select 循环，我习惯把「监听 socket」和「已接受的客户端 socket」放在同一个 socket 数组里，统一交给 select 去盯。
代码块：初始化监听 socket 数组
#include <winsock2.h> #include <stdio.h> #pragma comment(lib, "ws2_32.lib") #define MAX_SOCKETS 64 // 数组上限，必须 <= FD_SETSIZE #define LISTEN_PORTS_COUNT 3 SOCKET g_sockets[MAX_SOCKETS] = {0}; // 0 是无效 socket 句柄 int g_socketCount = 0; SOCKET CreateListenSocket(int port) { SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (s == INVALID_SOCKET) return INVALID_SOCKET; // 允许端口重用，避免 TIME_WAIT 状态下重启失败 BOOL opt = TRUE; setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&opt, sizeof(opt)); sockaddr_in addr = {0}; addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); // 监听所有网卡 addr.sin_port = htons((u_short)port); if (bind(s, (sockaddr*)&addr, sizeof(addr)) == SOCKET_ERROR) { closesocket(s); return INVALID_SOCKET; } if (listen(s, SOMAXCONN) == SOCKET_ERROR) { closesocket(s); return INVALID_SOCKET; } return s; }g_sockets数组里的元素 0 表示空位，这是我自己约定的无效值。Windows 的 socket 句柄从 1 开始分配，所以可以用 0 当占位。SO_REUSEADDR这个选项值得说一下：服务端程序如果不设置它，重启时如果旧连接还处在 TIME_WAIT 状态，bind 可能失败。开发调试阶段这个选项能省掉很多「明明关了程序却起不来」的莫名其妙的报错。
3.2 主循环：select 返回后怎么判断是哪个端口
核心的监听循环分为三步：清空并重建 fd_set，调用 select 等待，遍历 fd_set 找到有事件的 socket 并处理。注意每次循环都要重建 fd_set，因为 select 返回时会把没有事件的 socket 从集合中剔除。
代码块：select 多端口监听主循环
void RunLoop() { while (true) { fd_set readSet; FD_ZERO(&readSet); // 把当前所有 socket 加入 select 集合 for (int i = 0; i < g_socketCount; i++) { FD_SET(g_sockets[i], &readSet); } // Windows 下第一个参数忽略，timeout 为 NULL 表示永久等待 int ret = select(0, &readSet, nullptr, nullptr, nullptr); if (ret == SOCKET_ERROR) { int err = WSAGetLastError(); // 常见原因是 WSAENOTSOCK：集合里混进了已关闭的句柄 printf("select error: %d\n", err); break; } if (ret == 0) { continue; // 超时返回，实际上 timeout 为 NULL 时不会发生 } // 遍历所有 socket，检查哪个有事件 for (int i = 0; i < g_socketCount; i++) { if (!FD_ISSET(g_sockets[i], &readSet)) { continue; // 这个 socket 没有事件 } HandleSocketEvent(i); } } }这段循环的执行流程是：每次先清空readSet，再把所有管理的 socket 重新塞进去。select返回后，readSet里只保留了「有事发生」的 socket，然后逐个用FD_ISSET判断。
这里有个最常见的坑：不能在每次 select 前把所有 socket 重新加入集合后，还用上一次 select 返回后的readSet继续判断。因为你加入的readSet是全新的，上一次返回结果已经被覆盖了。continue的分支就是防止这种错误。
3.3 accept 与数据读取：区分监听端口与已连接 socket
select 只负责「通知」，真正干活的是HandleSocketEvent函数。它需要区分两类 socket：监听 socket 出现可读事件意味着有新连接；已连接 socket 出现可读事件意味着有数据到达，或对端关闭了连接。
代码块：事件分发处理
void HandleSocketEvent(int index) { SOCKET s = g_sockets[index]; // 判断是不是监听 socket：记录监听 socket 的起始下标范围 // 这里有简化：约定前 LISTEN_PORTS_COUNT 个是监听 socket if (index < LISTEN_PORTS_COUNT) { // 新连接到达，接受它 sockaddr_in clientAddr = {0}; int addrLen = sizeof(clientAddr); SOCKET client = accept(s, (sockaddr*)&clientAddr, &addrLen); if (client == INVALID_SOCKET) { int err = WSAGetLastError(); // 非阻塞模式下，这里常见 WSAEWOULDBLOCK，表示连接已被抢走，可忽略 printf("accept failed: %d\n", err); return; } // 把新客户端 socket 加入数组 if (g_socketCount < MAX_SOCKETS) { g_sockets[g_socketCount] = client; g_socketCount++; printf("new connection from %d.%d.%d.%d:%d, assigned index %d\n", (clientAddr.sin_addr.S_un.S_addr >> 0) & 0xFF, (clientAddr.sin_addr.S_un.S_addr >> 8) & 0xFF, (clientAddr.sin_addr.S_un.S_addr >> 16) & 0xFF, (clientAddr.sin_addr.S_un.S_addr >> 24) & 0xFF, ntohs(clientAddr.sin_port), g_socketCount - 1); } else { // 数组满了，直接关闭连接 closesocket(client); } } else { // 已连接 socket：尝试读取数据 char buf[1024] = {0}; int n = recv(s, buf, sizeof(buf) - 1, 0); if (n > 0) { printf("recv from client: %s\n", buf); // 回显给客户端 send(s, buf, n, 0); } else if (n == 0) { // 对端正常关闭 printf("client closed, index %d\n", index); closesocket(s); g_sockets[index] = 0; // 标记空位 } else { int err = WSAGetLastError(); if (err != WSAEWOULDBLOCK) { printf("recv error: %d\n", err); closesocket(s); g_sockets[index] = 0; } } } }逻辑上，index < LISTEN_PORTS_COUNT的是监听 socket，否则是客户端 socket。当客户端关闭连接时，recv返回 0，这时就要关闭 socket 并清理数组位置。
清理后的空位我没有做数组压缩，直接改成 0。这样做的问题是：下次 select 循环会把 0 也加进 fd_set。所以主循环里要加一个判断，跳过为 0 的元素，这一步很多人会漏掉。
3.4 修正：让主循环跳过空位
上面代码中g_sockets里的 0 元素如果不处理，select 调用时FD_SET(0, &readSet)会出错，因为 0 不是合法 socket。修正的方式很简单：在主循环里检查值是否为 0。
代码块：剔除空位后的安全重建
FD_ZERO(&readSet); for (int i = 0; i < g_socketCount; i++) { if (g_sockets[i] != 0) { FD_SET(g_sockets[i], &readSet); } }这个细节不显眼，但实际跑起来很容易翻车：如果你在前面关闭了一个客户端 socket 但没有清零，select 会直接返回WSAENOTSOCK。把g_sockets[i] != 0作为前置条件后，关闭连接和事件分发两个环节都安全了。
select 默认最多管理 64 个 socket。如果你的监听端口 + 客户端连接总数会超过 64，有两种处理方式：一是接受这个上限，客户端连接满了就拒绝新的；二是重新定义FD_SETSIZE，Windows 的 winsock2.h 是允许在包含头文件之前自行定义这个宏来扩大的，但最大不建议超过 512。
4. 避坑指南：单线程多端口开发的常见问题与排查
4.1 崩溃在 select：集合里混进了失效 socket
现象：程序运行一段时间后突然select返回SOCKET_ERROR，错误码是WSAENOTSOCK。之前明明好好的，也没改动代码。
原因：某个客户端断开时，代码只调用了closesocket，没有把数组里的值重置为 0。于是下一次 select 把一个已关闭的句柄塞进了 fd_set，内核直接不想理你。
解决：关闭 socket 后立即把数组元素置 0，同时循环重建时加g_sockets[i] != 0的保护判断。这一步是必须的，不是可选的。
4.2 只能监听一个端口：select 永远只在第一个端口返回
现象：起了三个监听端口，但只有第一个端口的连接能被 accept，其他端口的连接一点反应都没有。
原因：大概率没有设置非阻塞模式。在第一次 accept 时，如果用的是默认阻塞 socket，又没有 select 通知（或通知了但 accept 卡住），线程就阻塞在那里了。加上监听 socket 是非阻塞后，即使事件丢失，accept 也会立刻返回WSAEWOULDBLOCK而不是卡住主循环。
解决：对每个监听 socket 在 listen 之后立刻调用SetNonBlocking。并且 accept 失败时，把WSAEWOULDBLOCK当作正常情况处理，不要当成致命错误打印一堆日志。
4.3 压测发现接不住连接：fd_set 被 select 改动过
现象：写了个压测脚本同时开 20 个连接，但服务器只 accept 了十几个，剩下的连接没有响应。断开几个后再连，又有几个能进来。
原因：select 返回后，readSet会把没有事件的 socket 清除掉。如果你在 select 返回后直接复用同一个readSet再次调用 select，某些没有事件的 socket 会永久性地从集合里「消失」，它们的连接永远等不到触发。
解决：每次 select 前必须重新从零构建fd_set。不要在进入循环前建一次，然后循环里一直复用。这是 select 模型里最经典的认知差，我在自己项目里就踩过这个坑。
4.4 WSAStartup 版本协商不彻底
现象：在 Windows 老版本系统上运行，WSAStartup返回成功，但某些 socket 操作直接返回错误。
原因：请求版本号是 2.2，但系统只支持 1.1。老系统会返回一个可接受的降级版本，程序没检查这个版本号就直接往下走，用到了 2.2 才有的 API。
解决：调用WSAStartup后要检查返回的wVersionRequested字段，如果系统给出的主版本号小于 2，直接报错退出。代码很简单，但很多示例代码都没写这一层保护。
4.5 退出时卡死：主循环无法及时终止
现象：想要优雅退出程序，把 while(true) 改成了 while(running)，但关闭监听 socket 后 select 依然阻塞在等待中。
原因：select 在没有任何事件时会一直等下去。把 socket 关闭并不会让已经阻塞的 select 立即返回（Windows 上它会等到超时或下一个事件）。如果你的代码不打算做超时控制，退出时只能靠外部强行终止线程。
解决：给 select 设置一个超时时间，比如 500ms，超时返回 0 之后检查 running 标志位。这样「响应退出」和「等待事件」就能兼得。超时参数用timeval{0, 500000}这类结构体传入。
5. 从监听器到服务框架：扩展与二次开发思路
5.1 把单线程模型扩展成「单线程监听 + 工作线程处理」
上面的代码是纯单线程：select 到事件后直接在当前线程里 recv、发回显。这样做的缺点是：如果某个客户端发来一条超大消息，recv 要循环很多次才能收完，期间其他端口的连接全部被晾着。
常见的改造思路是：主线程只负责 accept 然后把新 socket 放进一个队列，工作线程从队列里取 socket 做完整的数据收发。但这样做，「单线程监听」这个标题就不成立了。更贴合原意、同时又能提升吞吐的做法是：保留单线程事件循环，在 recv 事件到达后，把数据处理部分投递到一个小型线程池。
代码块：事件循环 + 投递任务
// 投递方式示意：把 socket 交给线程池处理 void HandleSocketEvent(int index) { SOCKET s = g_sockets[index]; if (index < LISTEN_PORTS_COUNT) { // 接受新连接后只入队，不做业务 SOCKET client = accept(s, nullptr, nullptr); if (client != INVALID_SOCKET) { g_sockets[g_socketCount++] = client; } } else { // 委托给线程池，避免阻塞事件循环 g_threadPool->PostTask([s]() { char buf[4096]; int n = recv(s, buf, sizeof(buf), 0); if (n > 0) { // 业务处理：解析协议、存储、响应 } else if (n == 0) { closesocket(s); } }); } }这种改造下，select 循环只负责「监测事件 + 快速分发」，每个 socket 里的数据读取和业务逻辑在别的线程完成。注意线程池里的 recv 也应该是非阻塞的，或者做好完整的阻塞式读取循环，否则 socket 可能被并发读到。
5.2 支持更多的端口：从 64 到 256 的调整
如果你要监听超过 64 个端口或者预期并发连接超过 64，可以考虑在包含 winsock2.h 之前重新定义宏：
// 在代码文件最顶部，养成习惯先定义这个宏 #define FD_SETSIZE 256 #include <winsock2.h>FD_SETSIZE决定了fd_set的容量。Windows 的实现里 fd_set 使用了SOCKET数组来存句柄，所以调大这个宏只会增加内存占用，不会限制性能。把MAX_SOCKETS也同步改成 256，数组就不会越界。这个自由度是 select 模型留给你的最大的优化空间。
5.3 数据结构升级：用 vector 代替固定数组
固定数组SOCKET g_sockets[MAX_SOCKETS]写起来直观，但维护成本高。关闭一个 socket 后留下空位，每次循环都要跳过 0。更顺手的做法是用std::vector<SOCKET>，关闭时用erase直接移除，配合一个std::unordered_map<SOCKET, int>反向索引判断 socket 类型。
代码块：vector 管理 socket 集合
std::vector<SOCKET> listenSockets; // 监听 socket std::vector<SOCKET> clientSockets; // 客户端 socket void RemoveClient(SOCKET s) { auto it = std::find(clientSockets.begin(), clientSockets.end(), s); if (it != clientSockets.end()) { closesocket(s); clientSockets.erase(it); // 真正的移除，不留空位 } }用vector管理后，遍历 select 集合时只需要for (SOCKET s : clientSockets) FD_SET(s, &readSet)。移除时也不用留 0 占位，因为erase已经把元素彻底删掉。要注意的是：select 返回后readSet依然会改变你传入的集合，所以每次循环还是要重建，这一点和数组版本完全一致。
5.4 增加超时管理：防止连接堆积
单线程模型里，如果某个客户端连接上了却从不发数据，这个 socket 会一直占着fd_set的名额。连接一多，名额很快被睡着的连接占满，新的监听端口就等不到了。
解决办法是在事件循环里周期性扫描所有客户端 socket，记录每张 socket 的最后活跃时间，超过 30 秒没有数据的就主动关闭。这个逻辑用 select 的 timeval 参数驱动：每次 select 超时返回 0 时就做一次清理扫描，不会打断正常的事件处理。这就是上面提到设置超时时间的实用的场景之一。
5.5 关于优雅关闭的一个重要习惯
服务端需要退出时，不能直接 return 跳出主循环让进程结束。Windows 下进程结束后 socket 会被系统回收，但如果代码里还有工作线程正在读写，突然结束可能造成数据丢失或句柄泄漏。
我习惯的做法是三步：第一步，把每个监听 socket 用shutdown(sd, SD_BOTH)禁止收发，这一下 select 就会感知到异常并快速返回；第二步，遍历所有客户端 socket，用同样的方式关闭；第三步，最后统一closesocket，并把 vector 清空。这样事件循环不会卡死，工作线程也能正确退出。
6. 最后一层：跑起来之前必做的验证清单
写完了代码，别急着交付，先按下面步骤自测一遍。这套流程是我自己每次写 Windows socket 服务都用熟了的，能拦住大部分问题。
第一步，用netstat -ano确认三个端口都在监听状态。如果只有第一个端口在监听，说明监听循环写的问题多半出在 select 的 fd_set 复用上，回查第 3 节的重建逻辑。
第二步，开三个终端窗口，分别用 telnet 连接三个端口。连接成功后，除了第一个端口，另外两个端口如果没有任何反应，检查监听 socket 有没有设置非阻塞，以及 accept 之后的 socket 有没有正常加入管理数组。
第三步，在一个端口里输入数据，服务端要能原样回显。如果收不到回显，但连接没断，看 recv 的返回值和 WSAGetLastError，最常见的WSAEWOULDBLOCK（10035）说明非阻塞模式下暂时没有数据可读，这是正常的，不是错误。
第四步，断开某个客户端连接，观察服务端事件循环是否还能继续处理其他端口的连接。如果其他端口跟着失灵，就说明清理逻辑有漏洞，socket 数组里有残留句柄，回查关闭连接后的清理代码。
第五步，反复快速开关连接二十次，然后在任务管理器里看进程句柄数是否持续增长。如果只增不减，说明closesocket被跳过了，很可能是 recv 返回 0 的分支没有走到清理逻辑。
第六步，验证服务端重启不能 bind 失败。如果每次都报WSAEADDRINUSE，检查SO_REUSEADDR是否真的设置在了 bind 之前。
最后有个习惯性的建议：在面对 Windows socket 编程时，别把SocketError和SOCKET_ERROR混为一谈去比较。select返回SOCKET_ERROR是灾难性的，但accept返回INVALID_SOCKET之后再去查WSAEWOULDBLOCK才是正常流程。很多调试半天都找不到原因的问题，最后都出在这两种返回值的判断混乱上。从那以后我每次写完 socket 代码，都会强制自己把每个调用的返回类型和错误码判断走到一块儿。希望帮到你。
本文还有配套的精品资源，点击获取
