★ FEATURED ARTICLE 简介基于MFC开发的TCP/UDP IOCP封装类资源目标用户是需要在Windows平台实现高并发网络服务的开发者常见于即时通讯、在线游戏等长连接场景。这套代码以封装类的形式重构了完成端口模型修正了早期版本的缺陷与BUG并新增UDP IOCP能力同时加强互斥访问代码让共享资源在多线程环境下得到更完善保护有效减少并发读写冲突。压缩包共6个文件主要包含3个头文件、1个MFC扩展DLL、1个导入库lib和1个说明文件包体仅19KB轻量而聚焦。头文件对外暴露服务器、会话、UDP等核心类接口DLL和lib结合则提供了可直接投入工程调用的封装实现围绕完成端口初始化、客户端接入、数据读写与异常断开等环节组织代码。读者既可对照学习IOCP的接入流程、会话管理和收发缓冲设计也能把该套代码作为MFC网络模块的参考源码进行二次修改与排错。目前已有208人浏览学习适合具备Winsock基础、希望缩短IOCP服务端开发周期的中高级程序员参考使用可避开从零搭建完成端口的弯路。1. IOCP 不是玄学MFC 项目里抗住高并发 TCP 的典型解法到底在解决什么一个 MFC 写的 TCP 服务端最怕的不是功能写不出来而是连接一多就卡死。如果你手头有一个叫 CPP_IOCP.rar 的包里面躺着 iocp.cpp多半是前人把 IOCPInput/Output Completion Port输入输出完成端口封装到了 MFC 框架里想用少量线程扛住大量 TCP 连接。IOCP 是 Windows 平台专属的异步 I/O 模型核心思路是让操作系统帮你把“数据到达”和“处理完成”这两件事排队你用几个工作线程循环取任务就行。这套东西适合谁适合做上位机、网关、监控端、协议服务器这类桌面程序的开发者项目里 MFC 界面不能卡后面还挂着几十上百个 TCP 连接适合想把网络层和 UI 层彻底解耦的人。这篇笔记不念文档直接告诉你 IOCP 为什么是这么设计的、代码怎么写、MFC 怎么接、以及哪些坑会让你调一宿。2. IOCP 的原理与选型为什么 select 和“每连接一线程”会翻车2.1 从同步阻塞到异步完成IOCP 是“完成通知”模型不是“可读通知”模型先理解一个关键区别。select、WSAAsyncSelect这些模型是“通知你有数据可读了”至于怎么读、读完怎么处理还是你的事。而且select在 Windows 上有FD_SETSIZE的限制默认 64 个 socket就算你改宏把数组调大它每次都要线性扫描所有句柄连接数上千以后 CPU 全耗在扫描上这个账怎么算都不划算。IOCP 的模型直接换了思路你调用WSARecv把缓冲区交给操作系统系统收到数据后把“这次接收完成”这件事作为一个完成包丢进完成队列。工作线程调用GetQueuedCompletionStatus简称 GQCS去取完成包拿到的不是“哪个 socket 可以读了”而是“这次读操作已经结束了数据已经在缓冲区里”。这个区别至关重要——它把“等待”这件事从应用层搬到了内核层线程永远不会因为某个连接没数据而干等。还有一个常被忽略的点select模型下每次通知之后你还要自己判断是“有数据”还是“连接关闭”而 IOCP 的完成包本身就携带了传输字节数、错误码、操作类型这些信息。也就是说IOCP 把“事件发生”和“处理结果”打包在一起投递省掉了一次额外的系统调用和状态判断。这也是它能扛高并发的底层原因——线程数量不随连接数增长只随 CPU 核心数走。2.2 IOCP 的三个核心对象完成端口、句柄数据、操作数据写 IOCP 之前先把对象关系理顺不然代码写到一半必乱。第一是完成端口本身它由CreateIoCompletionPort创建或绑定。端口可以绑定一个监听 socket也可以绑定已接受的客户端 socket还可以再绑一个已完成的操作。第二个是设备对象通常是 socket与端口建立关联时你需要带一个PER_HANDLE_DATA指针这是“每个连接一份”的数据块里面放这个连接的 socket 句柄、远端地址、缓冲区状态等。第三个是PER_IO_DATA这是“每次操作一份”的数据块里面必须内嵌一个OVERLAPPED结构作为第一个成员或者至少包含它作为成员再加你私有的缓冲区和操作类型标志。很多新手翻车就在这里OVERLAPPED是一次操作完成后系统回填的关键结构它的生命周期必须覆盖整个异步操作期间。所以你绝对不能把OVERLAPPED分配在栈上函数一返回栈帧销毁内核还在往里面写数据必崩。常见做法是用new或者内存池分配PER_IO_DATA操作完成后在 GQCS 取回来处理完再释放。下面这张表把这几个对象拆开看对象创建/绑定方式生命周期典型内容完成端口HANDLECreateIoCompletionPort创建再用它绑定 socket进程级直到CloseHandle关联的 socket 集合完成队列PER_HANDLE_DATA每个已接受的 socket 一份绑定端口时传入socket 关闭时释放SOCKET、SOCKADDR_STORAGE、引用计数PER_IO_DATA每次 WSARecv/WSASend 一份对应操作完成并处理后释放OVERLAPPED、缓冲区、操作类型完成包内部对象内核在 I/O 完成时自动投递被 GQCS 取出即结束字节数、错误码、OVERLAPPED 指针2.3 什么时候不该用 IOCP小连接数场景的性价比账IOCP 不是银弹别上来就套。如果你的 MFC 程序只需要同时处理 5~10 个 TCP 连接数据量也不大IOCP 的代码复杂度多线程、缓冲区管理、异步生命周期反而会拖垮你的开发速度。这种场景下用WSAAsyncSelect把 socket 事件映射到窗口消息跟 MFC 的消息循环天然契合代码量小一半调试还容易。判断标准很简单连接数能不能到三位数每秒收发次数会不会超过几百次如果都是“否”别用 IOCP。但如果你做的是那种要挂几十台设备、每台设备几十毫秒就发一条数据的工业网关或者要收十几个采集终端高频推送那 IOCP 从选型上讲就是对的。我一般会建议团队用这样的阈值判断同时在线连接超过 50或消息频率超过 500 条/秒才考虑上 IOCP否则就是给维护埋雷。3. 把可跑的 IOCP TCP 服务器写出来从 CreateIoCompletionPort 到 GetQueuedCompletionStatus3.1 搭骨架监听套接字、完成端口和工作线程的最小集合先别急着把 MFC 扯进来网络层必须先独立跑通。常见做法是写一个IOCPServer类把监听、端口管理、工作线程封装在内部对外只暴露启动/停止接口和统计信息。下面是最小可用的初始化代码。// iocp_server.h 核心声明 class IOCPServer { public: bool Start(int port, int workerThreadCount); void Stop(); private: HANDLE m_hCompletionPort; // 完成端口句柄 SOCKET m_listenSocket; // 监听 socket std::vectorHANDLE m_threads; // 工作线程句柄 volatile LONG m_bRunning; // 服务状态 static DWORD WINAPI WorkerThread(LPVOID param); static DWORD WINAPI AcceptThread(LPVOID param); };// iocp_server.cpp 初始化函数 bool IOCPServer::Start(int port, int workerThreadCount) { // 1. 创建完成端口 m_hCompletionPort CreateIoCompletionPort( INVALID_HANDLE_VALUE, NULL, 0, workerThreadCount); if (m_hCompletionPort NULL) return false; // 2. 创建监听 socket绑定端口并开始监听 m_listenSocket WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0, WSA_FLAG_OVERLAPPED); if (m_listenSocket INVALID_SOCKET) return false; sockaddr_in addr {0}; addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(port); if (bind(m_listenSocket, (sockaddr*)addr, sizeof(addr)) SOCKET_ERROR) return false; if (listen(m_listenSocket, SOMAXCONN) SOCKET_ERROR) return false; // 3. 绑定监听 socket 到完成端口虽然 accept 不走 IOCP但统一入口有益 CreateIoCompletionPort((HANDLE)m_listenSocket, m_hCompletionPort, (ULONG_PTR)NULL, 0); // 4. 启动工作线程 m_bRunning TRUE; for (int i 0; i workerThreadCount; i) { HANDLE hThread CreateThread(NULL, 0, WorkerThread, this, 0, NULL); m_threads.push_back(hThread); } // 5. 单独一个线程做 Accept避免阻塞主线程 HANDLE hAccept CreateThread(NULL, 0, AcceptThread, this, 0, NULL); m_threads.push_back(hAccept); return true; }这里有两个关键点要解释。第一WSASocket必须传入WSA_FLAG_OVERLAPPED否则这个 socket 不支持重叠 I/O后面调用WSARecv就会直接报WSAEINVAL。第二监听 socket 绑定完成端口并不是必须的因为accept函数本身是阻塞的常见做法是用独立线程跑accept等新连接到来后再把客户端 socket 绑定到完成端口。我见过有人试图用AcceptEx把 accept 也做成异步重叠 I/O那是另一个优化层次刚上手时不要这么干调试复杂度会翻倍。3.2 接受连接与第一次投递 WSARecv每个客户端 socket 都要绑定端口AcceptThread负责循环 accept 新连接每个连接接受成功后要做两件事分配PER_HANDLE_DATA并绑定到完成端口紧接着投递第一次WSARecv操作。注意accept返回的 socket 默认就是支持重叠 I/O 的因为它继承了监听 socket 的属性所以绑定端口后立刻可以发起异步接收。DWORD WINAPI IOCPServer::AcceptThread(LPVOID param) { IOCPServer* pThis (IOCPServer*)param; while (pThis-m_bRunning) { SOCKADDR_IN clientAddr {0}; int addrLen sizeof(clientAddr); SOCKET clientSock accept(pThis-m_listenSocket, (sockaddr*)clientAddr, addrLen); if (clientSock INVALID_SOCKET) { // 如果服务停止中退出循环 if (!pThis-m_bRunning) break; continue; } // 给这个连接分配一块 PER_HANDLE_DATA PER_HANDLE_DATA* pPerHandle new PER_HANDLE_DATA; pPerHandle-s clientSock; memcpy(pPerHandle-addr, clientAddr, sizeof(clientAddr)); // 把客户端 socket 绑定到完成端口 CreateIoCompletionPort((HANDLE)clientSock, pThis-m_hCompletionPort, (ULONG_PTR)pPerHandle, 0); // 立即投递第一次异步接收 pThis-PostRecv(pPerHandle); } return 0; }PostRecv是每次投递WSARecv的封装代码里最容易出错的就是这里。void IOCPServer::PostRecv(PER_HANDLE_DATA* pHandle) { // 分配本次操作的数据块内嵌 OVERLAPPED PER_IO_DATA* pIo new PER_IO_DATA; ZeroMemory(pIo-ov, sizeof(OVERLAPPED)); pIo-operType OP_RECV; pIo-wsaBuf.len sizeof(pIo-buf); pIo-wsaBuf.buf pIo-buf; DWORD flags 0; // WSARecv 是异步的函数返回后操作可能尚未完成 int ret WSARecv(pHandle-s, pIo-wsaBuf, 1, NULL, flags, pIo-ov, NULL); if (ret SOCKET_ERROR) { int err WSAGetLastError(); if (err ! WSA_IO_PENDING) { // 非“挂起”错误属于致命错误关闭连接 CloseConnection(pHandle, pIo); return; } } // 如果返回 0 或 WSA_IO_PENDING操作已被内核接管 // 完成后会投递到完成队列工作线程去取。 }注意WSARecv的返回值有两种“正常”状态返回 0 表示数据已经同步进缓冲区了极少数情况比如数据在内部缓冲区立即可用返回SOCKET_ERROR且WSAGetLastError()等于WSA_IO_PENDING表示操作正在内核中异步执行。这两种情况都可以等着后续的完成通知。如果错误码不是WSA_IO_PENDING才说明这次投递本身失败了需要主动关闭连接并释放资源。3.3 工作线程里的状态机GQCS 返回后处理“收、发、错误、退出”四类情况工作线程是 IOCP 的心脏它做的事只有一件循环调用GetQueuedCompletionStatus拿到完成包后根据操作类型分发处理。这里有一个理解误区完成包回来不代表数据已经处理完只代表 I/O 操作本身结束了你还需要把缓冲区里的数据按协议解析、组装、分发。DWORD WINAPI IOCPServer::WorkerThread(LPVOID param) { IOCPServer* pThis (IOCPServer*)param; DWORD bytesTransferred 0; ULONG_PTR completionKey 0; // 就是 PER_HANDLE_DATA 的指针 OVERLAPPED* pOverlapped NULL; // 展开后就是 PER_IO_DATA 的 ov 成员 while (pThis-m_bRunning) { BOOL ok GetQueuedCompletionStatus( pThis-m_hCompletionPort, bytesTransferred, completionKey, pOverlapped, INFINITE); // 阻塞等待工作线程因此不会空转 PER_HANDLE_DATA* pHandle (PER_HANDLE_DATA*)completionKey; if (!pHandle || !pOverlapped) { // 完成端口被 PostQueuedCompletionStatus 关闭退出循环 if (!ok) break; continue; } PER_IO_DATA* pIo CONTAINING_RECORD(pOverlapped, PER_IO_DATA, ov); if (!ok || bytesTransferred 0) { // 连接被对端关闭或出错释放资源 CloseConnection(pHandle, pIo); continue; } if (pIo-operType OP_RECV) { // 处理收到的数据这里交给上层协议解析 pThis-OnDataReceived(pHandle, pIo-buf, bytesTransferred); // 投递下一次接收形成“接收-处理-再接收”循环 pThis-PostRecv(pHandle); // 注意pIo 的缓冲区已经被 copy 走了这里可以安全释放 delete pIo; } else if (pIo-operType OP_SEND) { // 发送完成释放发送缓冲区 delete pIo; } } return 0; }GetQueuedCompletionStatus的四个输出参数是理解整个模型的关键在代码里同时体现——completionKey是绑定 socket 时传入的那个PER_HANDLE_DATA*pOverlapped是投递操作时传入的那个OVERLAPPED*用CONTAINING_RECORD宏可以把指针逆向算回PER_IO_DATA的头地址这是内核里常用的技巧你直接类型强转也行因为ov是第一个成员。调用PostRecv重新投递接收操作时要注意你必须在使用完旧缓冲区之后再做这件事否则可能出现两个接收操作同时写同一个缓冲区的情况。这里OnDataReceived是同步调用数据已经拷贝到上层了所以删掉旧pIo再发起新PostRecv是安全的。4. MFC 界面与 IOCP 线程的协作用 PostMessage 把网络状态搬上对话框4.1 MFC 里启动和停止 IOCP 服务对话框按钮绑定与线程生命周期把 IOCP 网络层接到 MFC 界面上第一原则就是“网络线程绝不碰 UI 控件”。MFC 的控件操作必须在主线程UI 线程执行否则会出现两种后果轻则控件状态刷新不及时重则直接在SetWindowText里崩溃这是SendMessage跨线程时造成的死锁或断言失败。启动服务的标准做法是在按钮响应函数里创建 IOCP 服务对象并让它跑在独立线程中。常见做法是让IOCPServer自己管理内部线程就像前面代码那样对外只暴露Start和Stop。Start内部创建的 worker 线程会立即运行因此Start应当是一个不阻塞的调用返回后界面继续响应。// MFC 对话框按钮启动服务 void CMyDialog::OnBnClickedBtnStart() { if (m_pIocpServer) { AfxMessageBox(_T(服务已在运行)); return; } m_pIocpServer new IOCPServer(); // 工作线程数见下方解释 int workerCount GetWorkerThreadCount(); if (!m_pIocpServer-Start(9527, workerCount)) { AfxMessageBox(_T(服务启动失败请检查端口占用)); delete m_pIocpServer; m_pIocpServer NULL; return; } // UI 反馈 GetDlgItem(IDC_EDIT_PORT)-EnableWindow(FALSE); GetDlgItem(IDC_BTN_START)-EnableWindow(FALSE); GetDlgItem(IDC_BTN_STOP)-EnableWindow(TRUE); SetWindowText(m_hStatusWnd, _T(服务运行中)); }workerCount取多少才合理这是 IOCP 一个非常核心的参数工作线程数量不应该等于连接数而应该接近于 CPU 核心数或核心数乘以 2。因为 IOCP 的设计目标就是“少线程高并发”每个工作线程阻塞在GetQueuedCompletionStatus上不占 CPU当有大量 I/O 完成时线程会被自动唤醒并分配完成包。取CPU核心数 * 2是常见起步值跑不满再调但如果设成 50 个线程上下文切换的开销会抵消 IOCP 的优势。4.2 用自定义消息把连接数、收发字节数回传 UIPostMessage 是跨线程唯一的安全通道工作线程里产生了统计信息比如新连接建立、连接断开、收到多少数据不直接改 UI而是通过PostMessage把消息投递到主窗口。注意必须用PostMessage而不是SendMessage理由很简单SendMessage会等待主线程处理完才返回如果主线程正忙比如弹了模态框工作线程就被卡住IOCP 的完成队列越积越多最终线程池耗尽、连接超时。// 自定义消息 ID放在对话框头文件里 #define WM_NET_STAT_UPDATE (WM_APP 101) #define WM_NET_CONNECTED (WM_APP 102) #define WM_NET_DISCONNECTED (WM_APP 103) // 在对话框类中声明处理函数 afx_msg LRESULT OnNetStatUpdate(WPARAM wParam, LPARAM lParam); afx_msg LRESULT OnNetConnected(WPARAM wParam, LPARAM lParam); afx_msg LRESULT OnNetDisconnected(WPARAM wParam, LPARAM lParam);// 消息映射 BEGIN_MESSAGE_MAP(CMyDialog, CDialogEx) ON_MESSAGE(WM_NET_STAT_UPDATE, CMyDialog::OnNetStatUpdate) ON_MESSAGE(WM_NET_CONNECTED, CMyDialog::OnNetConnected) ON_MESSAGE(WM_NET_DISCONNECTED, CMyDialog::OnNetDisconnected) END_MESSAGE_MAP()// 工作线程中调用IOCPServer 内部持有主窗口句柄 void IOCPServer::OnDataReceived(PER_HANDLE_DATA* pHandle, char* data, DWORD len) { // 统计字节数使用 Interlocked 系列函数保证多线程正确性 InterlockedExchangeAdd(m_totalBytesRecv, len); // 通知主窗口刷新状态栏和统计区 PostMessage(m_hNotifyWnd, WM_NET_STAT_UPDATE, 0, 0); // 把数据交给协议层处理 if (m_protocolHandler) { m_protocolHandler-OnData(pHandle-s, data, len); } }PostMessage传wParam和lParam是定长的能传递的信息量有限但传递“连接数变化了”这种事件是够用的。如果你要传复杂结构体比如对端地址常见做法是在工作线程里new一个结构体把指针作为lParam传给主线程主线程处理完再delete。我要强调一个容易踩的边界工作线程里把指针PostMessage给主线程之后不能再碰这个指针所有权已经转移。否则主线程还在用工作线程这边一个delete那边就变成悬空指针。4.3 状态栏实时刷新把连接数、收包速率显示出来的实现细节不少 MFC 新手会把网络信息刷新放在定时器里每秒用SetTimer主动去查一次变量。这样做能工作但不是最优解——定时器刷新存在延迟而且即使没有任何事件发生也会空转 CPU。更贴近 IOCP 思路的做法是“事件驱动刷新”只有收到WM_NET_STAT_UPDATE消息时才去更新状态栏文本。LRESULT CMyDialog::OnNetStatUpdate(WPARAM wParam, LPARAM lParam) { // 从 IOCPServer 取统计信息需要加锁或使用原子变量 CString csInfo; csInfo.Format(_T(在线连接: %d 总接收: %lld 字节 总发送: %lld 字节), m_pIocpServer-GetClientCount(), m_pIocpServer-GetTotalRecvBytes(), m_pIocpServer-GetTotalSendBytes()); // m_wndStatusBar 是 CStatusBar 成员变量 m_wndStatusBar.SetPaneText(0, csInfo); return 0; }这段代码里我假设GetClientCount和GetTotalRecvBytes内部用了Interlocked原子操作。这里有一个极大的坑如果你用普通的int变量来计数工作线程写、UI 线程读读到脏数据的概率不高但long long类型的读写在 32 位程序里不是原子的可能读到“一半新一半旧”的 8 字节数据。既然用了 MFC 多线程跨线程读共享变量就必须加锁或者用原子操作没有例外。5. IOCP 实战避坑指南五个能让你调一晚上的问题5.1 现象客户端一多就丢数据CPU 却打满现象连接数涨到 200 左右时客户端偶发收不到完整包但服务端进程 CPU 占用率却接近 100%。原因工作线程数设多了或者每次收到数据后处理协议的时间太久导致PostRecv重新投递不及时内核缓冲区被写满后开始丢包。另一种可能WSARecv投递时缓冲区只有 4KB而实际数据包超过 4KB一次接收不完整你没有做粘包处理就把数据断了。解决先把工作线程数压到CPU核心数 * 2然后加大接收缓冲区我会用 8KB 起步单包上限 1MB 时直接给 64KB最关键的是套接字底层接收缓冲区也要调大用setsockopt(SO_RCVBUF)设置为 64KB 或更大。协议层必须实现“收包头-算长度-收完整包”的粘包逻辑不能假设一次WSARecv就收到一个完整应用层包。5.2 现象客户端频繁报 10053 / 10054连接像被鬼切断现象程序跑几分钟后客户端不断收到WSAECONNABORTED10053或WSAECONNRESET10054。原因最常见的是服务端在某个分支里直接closesocket了还没完成 I/O 操作的 socket。closesocket对仍有未完成的重叠 I/O 的 socket 会强制中止连接对端收到的就是连接重置。另一个常见来源是你发了数据之后没等发送完成就释放了缓冲区内核写到了非法内存行为随机且丑陋。解决在服务器主动断开连接时先调用shutdown(socket, SD_BOTH)等确认所有挂起的 I/O 操作都完成之后或者等一个短暂超时再closesocket。另外PER_IO_DATA的释放必须在操作完成后由 GQCS 返回时处理绝不能在投递后立刻删除。5.3 现象内存持续增长像泄漏一样涨到几百 MB现象任务管理器里看到进程内存曲线只涨不跌跑一晚上最终 OOM。原因PER_IO_DATA在每次PostRecv时new一次在“操作完成-处理-再投递”的循环里如果某条路径忘了delete每次连接每秒收发几十次泄漏速度会非常可观。还有一种隐蔽情况短连接场景下客户端连上发一条数据就断开PER_HANDLE_DATA释放了但如果该连接还有未完成的发送操作发送完成后在 GQCS 里按completionKey取到的pHandle已经是悬空指针。解决不要在每条逻辑路径里手动纠错直接在CloseConnection里统一做清理先移除所有未完成的 I/O 操作的引用再释放PER_HANDLE_DATA。更稳妥的方案是把PER_IO_DATA放进内存池连接级引用计数。在项目早期就做内存计数记录new和delete的总次数是省下调试时间最值的一笔投入。5.4 现象程序退出时卡死或崩溃在 GetQueuedCompletionStatus 返回的指针上现象点关闭按钮进程不退必须任务管理器强杀或者退出过程中偶发崩溃。原因服务停止时直接CloseHandle(m_hCompletionPort)此时工作线程还在阻塞在 GQCS 上。完成端口句柄被关闭后阻塞的 GQCS 会收到FALSE返回值GetLastError()等于ERROR_INVALID_HANDLE。但你如果还挂着一个AcceptThread阻塞在accept上监听 socket 没关这个线程就永远出不来。接受线程出不来服务对象就没办法安全析构。解决标准停止顺序是先关监听 socket 让 accept 返回失败再调用PostQueuedCompletionStatus往完成队列投递若干退出包每个工作线程收到一个特殊包后自行退出。然后才CloseHandle完成端口。注意PostQueuedCompletionStatus投递时completionKey传 NULLpOverlapped也传 NULL工作线程里看到这个组合就知道该退出了。5.5 现象MFC 界面卡死只有网络线程在跑现象服务跑起来后网络收发正常但点界面按钮没反应拖动窗口出现“未响应”。原因工作线程里直接调用了SetDlgItemText、AfxMessageBox或者SendMessage这类 UI 调用。这些调用会向 UI 线程投递同步消息如果 UI 线程恰好也在等某个网络状态锁典型如某段代码里WaitForSingleObject等网络线程的事件就形成互相等待的跨线程死锁。解决红线只有一条工作线程永远只调用PostMessage绝不调用SendMessage绝不直接触碰控件。如果需要弹窗提示错误用PostMessage把错误码发给主线程让主线程AfxMessageBox。调试这条坑时我会在程序里对SendMessage做个全局断点谁踩线一眼就能定位。6. 把这套 IOCP 代码投入生产前先做这三件验证代码写完能跑只是第一步我每次把 IOCP 服务端交给项目组之前至少要过三关验证。第一关是单连接大量数据压力测用一个小工具向服务端持续发送 10 万条固定格式的报文验证服务端协议解析的正确性出错率必须为 0。第二关是并发连接测试模拟 500 个客户端同时连接、同时收发观察服务端内存是否稳定、CPU 是否在不同核心之间均衡、有没有连接被异常断开。第三关是长稳测试跑 24 小时以上记录内存曲线和句柄数曲线任何单调增长都说明有泄漏。压测工具不必自己写连接池我会用一个多线程的 Python 脚本或者现成的TcPing工具批量发数据重点是把“测试数据长度固定”和“完整包校验”这两件事做扎实否则你没法区分是客户端压力不够还是服务端处理出错。看数据时不要只看吞吐量用 Process Explorer 观察两类指标一是线程数是否稳定在工作线程数附近二是非分页池内存是否持续增长。如果线程数像在跳舞一样上下跳动说明完成端口被反复开关连接生命周期管理有问题。还有一个参数我必须提一下netsh int tcp set global timestampsenabled这类的 TCP 全局参数会影响长连接空闲检测。Windows 默认开启了 TCP 时间戳但对某些工业设备协议栈兼容性不好客户端长时间不发数据时服务端可能由于时间戳校验失败而误断连接。遇到“客户端不主动断开服务端却把连接关了”的诡异问题先查netsh interface tcp show global里的时间戳和初始 RTO 设置再考虑代码逻辑。我自己的习惯是每个PER_IO_DATA里预留一个magic number成员初始化为固定值在删除之前断言它没有被破坏。这个习惯帮我抓到了至少三次缓冲区越界成本极低但非常值。另外所有跨线程传给 UI 的指针我都会在传递后立刻把本地引用置空防止误用。这套 IOCP 方案调试最痛苦的阶段是异步回调里资源释放的顺序但只要把「谁分配、谁释放」用注释在代码里标清楚整个架构是稳定、可靠、能托付的。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
