iocp是windows高并发服务器专用完成端口模型，需绑定句柄、堆分配overlapped、用completionkey关联上下文，严格管控各对象生命周期，依赖完成包确认i/o结果而非返回值。

IOCP 在 Windows 上不是“异步 IO”的通用解法，而是专为高并发服务器设计的完成端口模型

它不替代 ReadFile/WriteFile 的异步调用，而是把它们的完成通知统一收口到一个线程池里。你得先调用 CreateIoCompletionPort 绑定句柄，再对每个句柄发起重叠 I/O（OVERLAPPED 必须堆分配且生命周期可控），否则会立刻崩溃或静默失败。

• OVERLAPPED 结构体不能是栈变量——回调发生时栈早已销毁，必须 new 分配并随完成包一起传入 GetQueuedCompletionStatus
• 每个 socket 或文件句柄调用 CreateIoCompletionPort 时，第三个参数 CompletionKey 是你唯一能关联业务上下文的地方，建议塞入 this 指针或自定义结构体指针
• 不要在 GetQueuedCompletionStatus 返回后直接 delete OVERLAPPED——它可能被多个完成包复用，应由业务逻辑决定释放时机

启动 IOCP 线程池前，必须手动设置线程亲和性或限制并发数

Windows 默认允许任意数量线程在 IOCP 上等待，但线程切换开销会吃掉性能。真实场景中，4–8 个常驻线程通常比 CPU 核心数更多更稳，因为部分时间线程会卡在 WSARecv 等系统调用里。

• 调用 SetThreadAffinityMask 不是必须的，但若绑定到特定核心，需确保该核心不被其他高优先级进程抢占
• SetThreadPriority 设为 THREAD_PRIORITY_HIGHEST 容易引发饥饿，反而降低吞吐；保持默认或略提一级即可
• 务必用 WaitForSingleObject + 超时检测线程是否僵死，IOCP 线程一旦卡在用户代码里（比如死锁、长时间计算），整个端口就堵住

socket 使用 IOCP 前必须关闭重叠 I/O 的自动缓冲行为

Winsock 默认开启 SO_SNDBUF/SO_RCVBUF 缓冲区，这会让 WSASend 看似成功返回，实则数据还在内核队列里。你无法靠返回值判断是否真正发出去了，必须依赖完成包里的 dwNumberOfBytesTransferred。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 调用 setsockopt 关闭 SO_SNDBUF（设为 0）没用，Windows 会强制设为最小值；正确做法是接受缓冲存在，只在完成包里确认字节数
• WSARecv 的 lpBuffers 指向的内存必须全程有效——不能是局部数组，也不能在完成前被 realloc 或 free
• 断连检测不能只靠 recv 返回 0，要检查 WSAGetLastError() 是否为 WSAEDISCON 或 WSAENETRESET，否则会漏掉静默断连

错误码 ERROR_IO_PENDING 不是异常，而是 IOCP 正常流程的起点

每次调用 ReadFile、WSARecv 或 WriteFile 后返回 FALSE 并且 GetLastError() == ERROR_IO_PENDING，说明操作已进内核队列，等完成包唤醒线程处理——这是 IOCP 高效的关键，不是 bug。

• 如果没收到完成包，先检查是否忘了调用 GetQueuedCompletionStatus，或者传入了错误的 HANDLE
• GetQueuedCompletionStatus 返回 FALSE 且 GetLastError() == WAIT_TIMEOUT 是正常现象，不代表出错
• 真正危险的是 GetQueuedCompletionStatus 返回 TRUE 但 dwNumberOfBytesTransferred == 0 且操作是接收——大概率是对方关闭连接，需清理资源

IOCP 的复杂点不在 API 调用顺序，而在于所有对象（socket、OVERLAPPED、buffer 内存、completion key 关联的对象）的生命周期必须由你严格控制。没人帮你回收，错一次就内存泄漏或访问违规。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！