1. 为什么需要异步IO以及Windows给出的答案聊到Windows系统编程异步IO算是一座绕不过去的大山。同步IO其实很简单——你调一个ReadFile线程就卡在那儿直到数据从磁盘或者网卡上读进来才返回。这个过程在单线程程序里没什么问题但放到高并发服务器上就成了灾难。你想象一下一个进程要同时处理几千个客户端连接每个客户端都在做读写操作如果每来一个连接就开一个线程去伺候它操作系统光是切换线程上下文就能把CPU吃干净更别提每个线程默认还要占用1MB的地址空间作为栈。我做过的某跨平台系统里早期就是这种“一连接一线程”的模型跑到几百个并发连接时CPU占用率已经过半了内存也肉眼可见地往上涨。后来改成IO完成端口IOCP模型同样的机器扛下了几千个连接CPU反而更空闲。这就是异步IO最直观的价值它把“等待IO完成”这件事从线程手里抽出来交给操作系统内部去调度线程不用死等一个IO结果而是可以忙别的事情等IO完成了再回来收拾结果。在Windows平台上异步IO并不是一个单一的技术而是一整套方案。它至少有三种实现形态基于OVERLAPPED结构加事件对象的方式、基于完成例程APC回调的方式、以及基于IO完成端口IOCP的方式。三者底层机制不同适用场景也不同。这份笔记就围绕这三条线索展开把原理讲明白再给出可以直接抄的代码骨架。适合正在学Windows系统编程、想做高并发网络服务、或者被同步IO的性能瓶颈卡住的朋友参考。2. 核心概念拆解从OVERLAPPED到完成端口2.1 OVERLAPPED结构是整个异步IO的基石无论你用哪种方式做异步IO都绕不开一个叫OVERLAPPED的结构。它的本质是描述一次异步操作的“上下文”。你在调ReadFile、WriteFile、WSARecv这些函数时如果传入这个结构系统就知道你不想让线程傻等而是希望操作在后台进行完成后通过某种机制通知你。OVERLAPPED里有几个关键字段。Offset和OffsetHigh成员用于指定文件读写的偏移位置这在高位宽文件操作时特别重要因为普通的文件指针是线程级的共享状态异步场景下不能依赖它。hEvent字段可以放一个事件句柄也可以放完成例程或完成端口所需的额外标识。从Windows Vista开始系统还支持在OVERLAPPED前面塞一个用户自定义结构体用来标记操作类型、管理对象生命周期之类的元数据这也是我在工程里最常用的技巧。要注意一个容易混淆的点异步IO的参数里缓冲区指针和长度都是“借用”给你的——不是复制。也就是说在操作完成之前那块缓冲区你必须保证它一直有效不能提前释放否则就会产生内存访问冲突。踩过这个坑的人都知道崩溃现场常常是随机的排查起来特别费劲。2.2 事件通知、完成例程与完成端口的本质区别三者的区别可以这样理解事件通知是“有人敲门你去看”完成例程是“别人替你把事办了再告诉你”完成端口是“你雇了一群员工谁有空谁处理来活”。事件通知模式最简单你发起ReadFile传入一个OVERLAPPED结构结构的hEvent指向一个事件对象。你的线程可以继续做别的也可以调用WaitForSingleObject等这个事件等到了说明IO完成了再用GetOverlappedResult取出实际传输的字节数。它适合同一时刻IO操作数量不多的场景。每个IO都要对应一个事件对象如果同时挂起几千个IO光管理这些事件句柄就够你头疼的。完成例程模式稍微进了一步你调用ReadFileEx同时传入一个回调函数指针。当IO完成时系统把这个回调排队到你的线程的APC队列里只要你的线程进入可唤醒等待状态alertable wait比如调用SleepEx、WaitForSingleObjectEx回调函数就会在本线程上下文执行。它的好处是不需要为每个IO维护事件对象但坏处是APC队列是线程私有的发起的线程和处理的线程必须是同一个在对称多处理器的机器上容易被锁死在一个核心里扩展性受限。完成端口模式才是Windows异步IO的终极形态。它本质上是一个内核对象负责把IO完成事件分发到一组线程上去处理。你可以把任意数量的文件句柄或套接字句柄绑定到一个完成端口上系统内部做了队列优化IO完成时不会立刻唤醒线程而是以小批量、平衡负载的方式交给空闲的线程去处理。线程池的大小和IO数量完全解耦这才是高并发服务器的正确打开方式。2.3 三种方案到底怎么选我个人的建议是分场景如果你只是做小工具比如写一个异步读取大文件的命令行程序事件通知模式就够了代码逻辑直白不容易出错。如果你在做并发量中等比如几百路的网络服务又不想把完成端口那套复杂度引进来完成例程模式可以考虑但要注意APC队列的问题。如果你在做数千路甚至上万路并发连接的服务端别犹豫直接上完成端口。它是Windows下公认的高性能IO方案IOCP这个名字本身在这个领域就是权威。这就像搬家东西少自己拎两趟就行东西中等找两个朋友帮忙东西多得搬家公司都得排长队那就必须找调度系统统一指挥。3. 实操事件通知、完成例程、IOCP三段式Demo3.1 准备开发环境先说环境。我用的是Visual Studio创建一个空的C控制台工程Windows SDK版本默认即可不需要额外链接库。注意编译选项里把“使用Unicode字符集”勾上因为这年头大家写代码都用宽字符后面涉及文件名的地方省去转换的麻烦。整个Demo围绕一个文件异步读取的场景展开。先准备一个文本文件比如叫data.bin放一些内容进去保证文件大小足够大几MB这样异步操作的“时间窗口”才体现得出来。3.2 事件通知模式异步读取文件直接看代码。下面这段演示了如何用FILE_FLAG_OVERLAPPED打开文件异步发起读取然后用事件对象等待完成。#include windows.h #include iostream #include vector int main() { // 打开文件指定FILE_FLAG_OVERLAPPED才能走异步IO HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, // 关键这个标志决定文件句柄是否支持异步操作 nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } // 准备缓冲区 std::vectorchar buffer(4 * 1024 * 1024); // 创建事件对象 HANDLE hEvent CreateEventW(nullptr, TRUE, FALSE, nullptr); OVERLAPPED ov {}; ov.hEvent hEvent; // 事件对象的句柄放进OVERLAPPED里 ov.Offset 0; ov.OffsetHigh 0; // 发起异步读 BOOL bRet ReadFile(hFile, buffer.data(), static_castDWORD(buffer.size()), nullptr, ov); if (!bRet GetLastError() ! ERROR_IO_PENDING) { // 注意ERROR_IO_PENDING不是错误而是“操作正在进行”的信号 std::cerr ReadFile failed, error: GetLastError() std::endl; CloseHandle(hFile); CloseHandle(hEvent); return 1; } // 干点别的事情... std::cout 异步读已发起先做点别的... std::endl; // 等待IO完成 DWORD dwWait WaitForSingleObject(hEvent, INFINITE); if (dwWait WAIT_OBJECT_0) { DWORD bytesRead 0; BOOL bOk GetOverlappedResult(hFile, ov, bytesRead, FALSE); if (bOk) { std::cout 读取完成共读入 bytesRead 字节 std::endl; } else { std::cerr GetOverlappedResult failed, error: GetLastError() std::endl; } } CloseHandle(hEvent); CloseHandle(hFile); return 0; }几个关键点说细一点。第一CreateFile里如果不带FILE_FLAG_OVERLAPPED后续ReadFile传OVERLAPPED参数是无效的系统还是会走同步路径。这个标志一旦设置该句柄上的所有IO操作都必须用OVERLAPPED结构不能再做同步调用了。第二ReadFile返回FALSE不代表失败了。当返回值是FALSE并且GetLastError()返回ERROR_IO_PENDING时说明IO请求已经成功投递到内核正在后台执行线程可以继续跑。只有GetLastError()返回其他值才是真正的失败。第三GetOverlappedResult的最后一个参数bWait设为FALSE时表示“不等待立即查询结果”。如果IO还没完成函数返回FALSE并设置ERROR_IO_INCOMPLETE。这里因为我们已经等到事件了所以传入FALSE没问题。如果还没等到就调用它等于白查了一次。事件通知模式的局限在这里已经暴露了如果有几十个文件同时读你就得为每个文件创建事件对象然后调用WaitForMultipleObjects去监听多个事件。这个函数一次最多支持64个事件再多就得分组轮询代码变得复杂且低效。3.3 完成例程模式异步读写与Alertable等待完成例程模式的代码结构有些不同。它不再使用普通ReadFile而是用ReadFileEx。这个函数多了一个参数完成回调函数的指针。当IO完成时系统会把回调函数排入发起线程的APC队列然后由该线程在“可唤醒等待”期间执行。#include windows.h #include iostream #include vector // 完成例程注意签名必须是这个格式 VOID CALLBACK FileIOCompletionRoutine( DWORD dwErrorCode, DWORD dwNumberOfBytesTransfered, LPOVERLAPPED lpOverlapped ) { std::cout 完成例程被调用传输字节数: dwNumberOfBytesTransfered std::endl; // 在这里更新用户上下文状态比如标记事件已完成 } int main() { HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } std::vectorchar buffer(4 * 1024 * 1024); OVERLAPPED ov {}; // 完成例程模式不需要hEvent这里可以留空或者自己用来存信息 BOOL bRet ReadFileEx( hFile, buffer.data(), static_castDWORD(buffer.size()), ov, FileIOCompletionRoutine // 回调函数 ); if (!bRet) { std::cerr ReadFileEx failed, error: GetLastError() std::endl; CloseHandle(hFile); return 1; } std::cout 异步读已发起进入alertable等待... std::endl; // 关键必须进入alertable等待回调才会执行 // SleepEx的第二个参数bAlertable必须为TRUE SleepEx(INFINITE, TRUE); // 如果回调里面没有设置状态这里可以继续做别的事 CloseHandle(hFile); return 0; }这里最容易踩的坑就是那个“alertable等待”。完成例程不是随随便便在哪个线程上被调用的它只会调度到发起IO的那个线程而且该线程必须处于一个“允许APC执行”的等待状态。SleepEx、WaitForSingleObjectEx、WaitForMultipleObjectsEx这些带Ex后缀的等待函数第二个参数设为TRUE才会让线程进入这种状态。普通的Sleep、WaitForSingleObject做不到这一点回调永远不会被调用。另外注意完成例程的执行时机。如果你发起了一个ReadFileEx之后线程不进入alertable等待而是继续做密集的计算即使IO已经完成了回调也只能排队等着。这其实也提示了它的一个天然缺陷发起线程必须反复进入可唤醒等待才能及时处理完成事件这在纯计算密集型的线程模型里很不友好。实战里你还可以利用APC队列的特性做点小花活比如用QueueUserAPC主动往线程的APC队列塞一个自定义函数。这个函数不依赖任何IO操作纯粹由线程执行可以用作线程间协作。不过这个用法属于进阶操作先在笔记本上记一笔。3.4 IOCP完成端口高并发服务器的主干完成端口的使用套路基本是固定的创建完成端口对象、把句柄关联到端口、投递异步操作、等待完成、处理结果、再投递新的操作。网上有很多版本我这里写一个最精简的可运行骨架用来演示底层逻辑。#include windows.h #include iostream #include vector // IO上下文把操作类型、缓冲区、OVERLAPPED打包在一起 struct IOCPContext { OVERLAPPED ov; std::vectorchar buffer; enum { OP_READ, OP_WRITE } opType; }; int main() { HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } // 1. 创建完成端口对象 HANDLE hIOCP CreateIoCompletionPort( INVALID_HANDLE_VALUE, nullptr, 0, 0 // 并发线程数传0表示系统默认CPU核心数 ); if (!hIOCP) { std::cerr CreateIoCompletionPort failed, error: GetLastError() std::endl; CloseHandle(hFile); return 1; } // 2. 关联文件句柄到完成端口 // 这里把文件的句柄关联进去completionKey可以放一个自定义值 HANDLE hNewIOCP CreateIoCompletionPort(hFile, hIOCP, 12345, 0); if (hNewIOCP ! hIOCP) { std::cerr Associate file with IOCP failed std::endl; CloseHandle(hIOCP); CloseHandle(hFile); return 1; } // 3. 投递一个异步读 IOCPContext* ctx new IOCPContext(); ctx-opType IOCPContext::OP_READ; ctx-buffer.resize(4 * 1024 * 1024); memset(ctx-ov, 0, sizeof(OVERLAPPED)); BOOL bRet ReadFile( hFile, ctx-buffer.data(), static_castDWORD(ctx-buffer.size()), nullptr, ctx-ov ); if (!bRet GetLastError() ! ERROR_IO_PENDING) { std::cerr ReadFile failed, error: GetLastError() std::endl; delete ctx; CloseHandle(hIOCP); CloseHandle(hFile); return 1; } std::cout 异步读已投递到完成端口等待完成... std::endl; // 4. 等待完成事件 DWORD bytesTransferred 0; ULONG_PTR completionKey 0; OVERLAPPED* pOv nullptr; BOOL bOk GetQueuedCompletionStatus( hIOCP, bytesTransferred, completionKey, pOv, INFINITE ); if (bOk) { // 通过CONTAINING_RECORD从OVERLAPPED还原上下文 IOCPContext* completedCtx CONTAINING_RECORD(pOv, IOCPContext, ov); std::cout IO完成completionKey completionKey , 字节数 bytesTransferred std::endl; delete completedCtx; } else { std::cerr GetQueuedCompletionStatus failed, error: GetLastError() std::endl; } CloseHandle(hIOCP); CloseHandle(hFile); return 0; }这个骨架虽然功能很少但体现了IOCP工作的完整闭环。CreateIoCompletionPort这个函数身兼两职第一次调用传INVALID_HANDLE_VALUE时它创建一个全新的完成端口对象第二次传文件句柄时它把句柄“绑定”到端口上。一个端口可以绑定成千上万个句柄所有句柄的IO完成事件都会集中投递到同一个队列里。GetQueuedCompletionStatus就是那个阻塞等待线程。真正的高并发服务器里这个函数会被多个线程同时调用形成一个线程池从完成队列里取任务处理。系统内部会做负载均衡线程多了也不会互相抢到崩溃。那个并发线程数参数在创建时传0系统默认按CPU核心数来调度实际项目里我习惯根据压测结果微调通常设置为核心数加一到两倍。IOCP模型的精髓在于内存管理因为操作是异步的上下文需要自己new出来完成后再自己delete。常见的设计是给每个连接维护一个上下文结构里面放OVERLAPPED、缓冲区、套接字句柄和状态标志一次投递一个“读”操作等读完成后处理数据再投递一个“写”操作。周而复始这就是高性能网络服务器的核心循环。4. 常见问题与排查技巧实录4.1 ERROR_IO_PENDING到底怎么处理新手最常见的问题就是把ERROR_IO_PENDING当成错误码上报程序提前退出然后一脸懵。记住一个铁律凡是发起异步操作的函数ReadFile、WriteFile、WSARecv、AcceptEx等返回FALSE时先GetLastError()判断如果错误码是ERROR_IO_PENDING那说明操作正常进行中不是失败。只有其他错误码才是真的失败。还有一种情况是在异步操作进行中直接关闭句柄。某些程序在发起IO后因为逻辑错误提前CloseHandle导致后续完成事件成为野指针引用。正确做法是等所有挂起操作完成后确保完成回调或完成队列已经收集了对应的完成包再释放上下文和句柄。4.2 缓冲区生命周期“借用”而非“拷贝”的代价前面说过异步IO的缓冲区是借给你的。操作系统内核在读写磁盘或网卡时直接访问这块内存如果你的逻辑在操作完成前把这些内存释放了或者让它被重分配了内核写入时就会踩到无效内存。典型崩溃表现为随机访问违例地址还不固定。工程上我习惯用一个小技巧给每个IO操作包一个“引用计数”的对象。发起一次操作就加一次引用完成后在回调里减引用并检查计数归零才真正析构缓冲区。命令行Demo里可以用简单的new/delete但服务器项目里就必须认真管理生命周期了。4.3 完成例程为什么不回调如果你用的是完成例程方式Octocallback没有执行九成原因是线程没有进入alertable等待。另一个原因是发起IO的线程已经退出了APC队列整个被销毁回调无从谈起。还有一个小概率同一时刻APC队列里有大量别的APC在排队你的回调排在后面看起来就像“没被调用”。这种情况可以通过在回调里加日志来确认。补充一个容易忽略的细节如果你在DLL里发起异步IO并使用完成例程必须特别注意DLL卸载时机。如果DLL已经卸载了而APC回调的代码地址指向了已卸载的DLL进程会直接崩溃。解决方法是使用DLL的引用计数或者确保所有操作完成后才卸载。4.4 IOCP上下文指针丢失怎么排查用IOCP时GetQueuedCompletionStatus返回的pOv参数只提供了OVERLAPPED指针。如果你只分配了一个裸的OVERLAPPED结构没有把它塞进更大的上下文结构里那么处理完成事件时你完全不知道这个IO属于哪条连接、哪个缓冲区。这就是为什么必须用CONTAINING_RECORD来从OVERLAPPED地址倒推出整个context结构。还有个排查技巧如果GetQueuedCompletionStatus返回FALSE不要急着把它当错误处理。还有一种情况是PostQueuedCompletionStatus投递的用户自定义包它的pOv可以是空指针bytesTransferred和completionKey携带你自定义的数据。这是IOCP模型里用来“通知线程池退出”或“传递控制指令”的标准手段。你在接收端要区分pOv是否为null。4.5 线程池开多少线程合适网上看多了会看到各种公式比如“CPU核心数乘以2”或者“核心数加1”。实际项目中线程数取决于IO操作的类型和延迟。对于网络IO由于涉及网络栈的调度和延迟我通常从核心数的两倍开始压测逐步增加直到吞吐不再提升为止。对于磁盘IO线程数不宜过多因为磁盘本身有队列深度限制线程过多只会增加上下文切换开销。还有一种经验如果你的服务既有IO密集型又有CPU密集型任务可以把工作线程分成两组一组专门跑GetQueuedCompletionStatus一组跑计算任务。中间用无锁队列衔接。这个分层设计能大幅降低IO线程的阻塞概率但实现复杂度会上升不少。4.6 调试异步IO的辅助工具调试异步IO比同步IO难得多传统断点思路经常失效。我习惯在几个关键位置打日志发起操作时记录上下文地址和参数完成回调/完成队列取出时记录上下文地址和字节数释放上下文时记录地址。如果上下文被重复释放或遗漏释放日志里能看到重复地址或者永不出现的地址。Windows自带的性能监视器里有一项“IO完成端口”相关的计数器可以观察完成端口的队列长度、线程数等指标。还有系统事件追踪ETW功能能详细记录IO请求从发起到完成的全过程定位内核层面的延迟非常有帮助。5. 最后分享一点个人经验这套异步IO的东西我刚接触时也绕了很大一圈。现在回头看最大的经验教训就是不要迷信某个技术“银弹”。事件通知、完成例程、IOCP各有各的位置选型前先把业务形态想清楚。代码写出来只是开始真正吃透是在并发量上来、各种诡异问题开始冒头的时候。我记得有一次压测某跨平台系统的IOCP服务端发现连接数到3000左右吞吐上不去排查了很久才发现是线程池里有个线程在做阻塞型的日志写入把整个IO线程池都拖慢了。后来把所有日志IO从工作线程里拆出去用单独的后台线程批量刷盘吞吐立刻翻倍。这种问题在教科书里根本学不到只有亲手压测排查才能积累经验。另一点建议是做异步IO的代码优先级第一是正确性第二是清晰度。宁可多写几行注释画出每个IO上下文的生命周期也不要在代码里玩弄各种奇技淫巧。异步IO出bug的时候问题往往不在单点而在状态流转。多花时间把状态机画清楚比什么都管用。这篇笔记写到这里正文的技术内容已经完整了。最后再留一个小提示如果你打算深入IOCP做网络服务强烈建议把“套接字与完成端口的绑定方式”单独研究一下尤其是AcceptEx和WSARecv的配合使用那是另一个可以写一整篇笔记的话题。
1. 为什么需要异步IO以及Windows给出的答案聊到Windows系统编程异步IO算是一座绕不过去的大山。同步IO其实很简单——你调一个ReadFile线程就卡在那儿直到数据从磁盘或者网卡上读进来才返回。这个过程在单线程程序里没什么问题但放到高并发服务器上就成了灾难。你想象一下一个进程要同时处理几千个客户端连接每个客户端都在做读写操作如果每来一个连接就开一个线程去伺候它操作系统光是切换线程上下文就能把CPU吃干净更别提每个线程默认还要占用1MB的地址空间作为栈。我做过的某跨平台系统里早期就是这种“一连接一线程”的模型跑到几百个并发连接时CPU占用率已经过半了内存也肉眼可见地往上涨。后来改成IO完成端口IOCP模型同样的机器扛下了几千个连接CPU反而更空闲。这就是异步IO最直观的价值它把“等待IO完成”这件事从线程手里抽出来交给操作系统内部去调度线程不用死等一个IO结果而是可以忙别的事情等IO完成了再回来收拾结果。在Windows平台上异步IO并不是一个单一的技术而是一整套方案。它至少有三种实现形态基于OVERLAPPED结构加事件对象的方式、基于完成例程APC回调的方式、以及基于IO完成端口IOCP的方式。三者底层机制不同适用场景也不同。这份笔记就围绕这三条线索展开把原理讲明白再给出可以直接抄的代码骨架。适合正在学Windows系统编程、想做高并发网络服务、或者被同步IO的性能瓶颈卡住的朋友参考。2. 核心概念拆解从OVERLAPPED到完成端口2.1 OVERLAPPED结构是整个异步IO的基石无论你用哪种方式做异步IO都绕不开一个叫OVERLAPPED的结构。它的本质是描述一次异步操作的“上下文”。你在调ReadFile、WriteFile、WSARecv这些函数时如果传入这个结构系统就知道你不想让线程傻等而是希望操作在后台进行完成后通过某种机制通知你。OVERLAPPED里有几个关键字段。Offset和OffsetHigh成员用于指定文件读写的偏移位置这在高位宽文件操作时特别重要因为普通的文件指针是线程级的共享状态异步场景下不能依赖它。hEvent字段可以放一个事件句柄也可以放完成例程或完成端口所需的额外标识。从Windows Vista开始系统还支持在OVERLAPPED前面塞一个用户自定义结构体用来标记操作类型、管理对象生命周期之类的元数据这也是我在工程里最常用的技巧。要注意一个容易混淆的点异步IO的参数里缓冲区指针和长度都是“借用”给你的——不是复制。也就是说在操作完成之前那块缓冲区你必须保证它一直有效不能提前释放否则就会产生内存访问冲突。踩过这个坑的人都知道崩溃现场常常是随机的排查起来特别费劲。2.2 事件通知、完成例程与完成端口的本质区别三者的区别可以这样理解事件通知是“有人敲门你去看”完成例程是“别人替你把事办了再告诉你”完成端口是“你雇了一群员工谁有空谁处理来活”。事件通知模式最简单你发起ReadFile传入一个OVERLAPPED结构结构的hEvent指向一个事件对象。你的线程可以继续做别的也可以调用WaitForSingleObject等这个事件等到了说明IO完成了再用GetOverlappedResult取出实际传输的字节数。它适合同一时刻IO操作数量不多的场景。每个IO都要对应一个事件对象如果同时挂起几千个IO光管理这些事件句柄就够你头疼的。完成例程模式稍微进了一步你调用ReadFileEx同时传入一个回调函数指针。当IO完成时系统把这个回调排队到你的线程的APC队列里只要你的线程进入可唤醒等待状态alertable wait比如调用SleepEx、WaitForSingleObjectEx回调函数就会在本线程上下文执行。它的好处是不需要为每个IO维护事件对象但坏处是APC队列是线程私有的发起的线程和处理的线程必须是同一个在对称多处理器的机器上容易被锁死在一个核心里扩展性受限。完成端口模式才是Windows异步IO的终极形态。它本质上是一个内核对象负责把IO完成事件分发到一组线程上去处理。你可以把任意数量的文件句柄或套接字句柄绑定到一个完成端口上系统内部做了队列优化IO完成时不会立刻唤醒线程而是以小批量、平衡负载的方式交给空闲的线程去处理。线程池的大小和IO数量完全解耦这才是高并发服务器的正确打开方式。2.3 三种方案到底怎么选我个人的建议是分场景如果你只是做小工具比如写一个异步读取大文件的命令行程序事件通知模式就够了代码逻辑直白不容易出错。如果你在做并发量中等比如几百路的网络服务又不想把完成端口那套复杂度引进来完成例程模式可以考虑但要注意APC队列的问题。如果你在做数千路甚至上万路并发连接的服务端别犹豫直接上完成端口。它是Windows下公认的高性能IO方案IOCP这个名字本身在这个领域就是权威。这就像搬家东西少自己拎两趟就行东西中等找两个朋友帮忙东西多得搬家公司都得排长队那就必须找调度系统统一指挥。3. 实操事件通知、完成例程、IOCP三段式Demo3.1 准备开发环境先说环境。我用的是Visual Studio创建一个空的C控制台工程Windows SDK版本默认即可不需要额外链接库。注意编译选项里把“使用Unicode字符集”勾上因为这年头大家写代码都用宽字符后面涉及文件名的地方省去转换的麻烦。整个Demo围绕一个文件异步读取的场景展开。先准备一个文本文件比如叫data.bin放一些内容进去保证文件大小足够大几MB这样异步操作的“时间窗口”才体现得出来。3.2 事件通知模式异步读取文件直接看代码。下面这段演示了如何用FILE_FLAG_OVERLAPPED打开文件异步发起读取然后用事件对象等待完成。#include windows.h #include iostream #include vector int main() { // 打开文件指定FILE_FLAG_OVERLAPPED才能走异步IO HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, // 关键这个标志决定文件句柄是否支持异步操作 nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } // 准备缓冲区 std::vectorchar buffer(4 * 1024 * 1024); // 创建事件对象 HANDLE hEvent CreateEventW(nullptr, TRUE, FALSE, nullptr); OVERLAPPED ov {}; ov.hEvent hEvent; // 事件对象的句柄放进OVERLAPPED里 ov.Offset 0; ov.OffsetHigh 0; // 发起异步读 BOOL bRet ReadFile(hFile, buffer.data(), static_castDWORD(buffer.size()), nullptr, ov); if (!bRet GetLastError() ! ERROR_IO_PENDING) { // 注意ERROR_IO_PENDING不是错误而是“操作正在进行”的信号 std::cerr ReadFile failed, error: GetLastError() std::endl; CloseHandle(hFile); CloseHandle(hEvent); return 1; } // 干点别的事情... std::cout 异步读已发起先做点别的... std::endl; // 等待IO完成 DWORD dwWait WaitForSingleObject(hEvent, INFINITE); if (dwWait WAIT_OBJECT_0) { DWORD bytesRead 0; BOOL bOk GetOverlappedResult(hFile, ov, bytesRead, FALSE); if (bOk) { std::cout 读取完成共读入 bytesRead 字节 std::endl; } else { std::cerr GetOverlappedResult failed, error: GetLastError() std::endl; } } CloseHandle(hEvent); CloseHandle(hFile); return 0; }几个关键点说细一点。第一CreateFile里如果不带FILE_FLAG_OVERLAPPED后续ReadFile传OVERLAPPED参数是无效的系统还是会走同步路径。这个标志一旦设置该句柄上的所有IO操作都必须用OVERLAPPED结构不能再做同步调用了。第二ReadFile返回FALSE不代表失败了。当返回值是FALSE并且GetLastError()返回ERROR_IO_PENDING时说明IO请求已经成功投递到内核正在后台执行线程可以继续跑。只有GetLastError()返回其他值才是真正的失败。第三GetOverlappedResult的最后一个参数bWait设为FALSE时表示“不等待立即查询结果”。如果IO还没完成函数返回FALSE并设置ERROR_IO_INCOMPLETE。这里因为我们已经等到事件了所以传入FALSE没问题。如果还没等到就调用它等于白查了一次。事件通知模式的局限在这里已经暴露了如果有几十个文件同时读你就得为每个文件创建事件对象然后调用WaitForMultipleObjects去监听多个事件。这个函数一次最多支持64个事件再多就得分组轮询代码变得复杂且低效。3.3 完成例程模式异步读写与Alertable等待完成例程模式的代码结构有些不同。它不再使用普通ReadFile而是用ReadFileEx。这个函数多了一个参数完成回调函数的指针。当IO完成时系统会把回调函数排入发起线程的APC队列然后由该线程在“可唤醒等待”期间执行。#include windows.h #include iostream #include vector // 完成例程注意签名必须是这个格式 VOID CALLBACK FileIOCompletionRoutine( DWORD dwErrorCode, DWORD dwNumberOfBytesTransfered, LPOVERLAPPED lpOverlapped ) { std::cout 完成例程被调用传输字节数: dwNumberOfBytesTransfered std::endl; // 在这里更新用户上下文状态比如标记事件已完成 } int main() { HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } std::vectorchar buffer(4 * 1024 * 1024); OVERLAPPED ov {}; // 完成例程模式不需要hEvent这里可以留空或者自己用来存信息 BOOL bRet ReadFileEx( hFile, buffer.data(), static_castDWORD(buffer.size()), ov, FileIOCompletionRoutine // 回调函数 ); if (!bRet) { std::cerr ReadFileEx failed, error: GetLastError() std::endl; CloseHandle(hFile); return 1; } std::cout 异步读已发起进入alertable等待... std::endl; // 关键必须进入alertable等待回调才会执行 // SleepEx的第二个参数bAlertable必须为TRUE SleepEx(INFINITE, TRUE); // 如果回调里面没有设置状态这里可以继续做别的事 CloseHandle(hFile); return 0; }这里最容易踩的坑就是那个“alertable等待”。完成例程不是随随便便在哪个线程上被调用的它只会调度到发起IO的那个线程而且该线程必须处于一个“允许APC执行”的等待状态。SleepEx、WaitForSingleObjectEx、WaitForMultipleObjectsEx这些带Ex后缀的等待函数第二个参数设为TRUE才会让线程进入这种状态。普通的Sleep、WaitForSingleObject做不到这一点回调永远不会被调用。另外注意完成例程的执行时机。如果你发起了一个ReadFileEx之后线程不进入alertable等待而是继续做密集的计算即使IO已经完成了回调也只能排队等着。这其实也提示了它的一个天然缺陷发起线程必须反复进入可唤醒等待才能及时处理完成事件这在纯计算密集型的线程模型里很不友好。实战里你还可以利用APC队列的特性做点小花活比如用QueueUserAPC主动往线程的APC队列塞一个自定义函数。这个函数不依赖任何IO操作纯粹由线程执行可以用作线程间协作。不过这个用法属于进阶操作先在笔记本上记一笔。3.4 IOCP完成端口高并发服务器的主干完成端口的使用套路基本是固定的创建完成端口对象、把句柄关联到端口、投递异步操作、等待完成、处理结果、再投递新的操作。网上有很多版本我这里写一个最精简的可运行骨架用来演示底层逻辑。#include windows.h #include iostream #include vector // IO上下文把操作类型、缓冲区、OVERLAPPED打包在一起 struct IOCPContext { OVERLAPPED ov; std::vectorchar buffer; enum { OP_READ, OP_WRITE } opType; }; int main() { HANDLE hFile CreateFileW( Ldata.bin, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr ); if (hFile INVALID_HANDLE_VALUE) { std::cerr CreateFile failed, error: GetLastError() std::endl; return 1; } // 1. 创建完成端口对象 HANDLE hIOCP CreateIoCompletionPort( INVALID_HANDLE_VALUE, nullptr, 0, 0 // 并发线程数传0表示系统默认CPU核心数 ); if (!hIOCP) { std::cerr CreateIoCompletionPort failed, error: GetLastError() std::endl; CloseHandle(hFile); return 1; } // 2. 关联文件句柄到完成端口 // 这里把文件的句柄关联进去completionKey可以放一个自定义值 HANDLE hNewIOCP CreateIoCompletionPort(hFile, hIOCP, 12345, 0); if (hNewIOCP ! hIOCP) { std::cerr Associate file with IOCP failed std::endl; CloseHandle(hIOCP); CloseHandle(hFile); return 1; } // 3. 投递一个异步读 IOCPContext* ctx new IOCPContext(); ctx-opType IOCPContext::OP_READ; ctx-buffer.resize(4 * 1024 * 1024); memset(ctx-ov, 0, sizeof(OVERLAPPED)); BOOL bRet ReadFile( hFile, ctx-buffer.data(), static_castDWORD(ctx-buffer.size()), nullptr, ctx-ov ); if (!bRet GetLastError() ! ERROR_IO_PENDING) { std::cerr ReadFile failed, error: GetLastError() std::endl; delete ctx; CloseHandle(hIOCP); CloseHandle(hFile); return 1; } std::cout 异步读已投递到完成端口等待完成... std::endl; // 4. 等待完成事件 DWORD bytesTransferred 0; ULONG_PTR completionKey 0; OVERLAPPED* pOv nullptr; BOOL bOk GetQueuedCompletionStatus( hIOCP, bytesTransferred, completionKey, pOv, INFINITE ); if (bOk) { // 通过CONTAINING_RECORD从OVERLAPPED还原上下文 IOCPContext* completedCtx CONTAINING_RECORD(pOv, IOCPContext, ov); std::cout IO完成completionKey completionKey , 字节数 bytesTransferred std::endl; delete completedCtx; } else { std::cerr GetQueuedCompletionStatus failed, error: GetLastError() std::endl; } CloseHandle(hIOCP); CloseHandle(hFile); return 0; }这个骨架虽然功能很少但体现了IOCP工作的完整闭环。CreateIoCompletionPort这个函数身兼两职第一次调用传INVALID_HANDLE_VALUE时它创建一个全新的完成端口对象第二次传文件句柄时它把句柄“绑定”到端口上。一个端口可以绑定成千上万个句柄所有句柄的IO完成事件都会集中投递到同一个队列里。GetQueuedCompletionStatus就是那个阻塞等待线程。真正的高并发服务器里这个函数会被多个线程同时调用形成一个线程池从完成队列里取任务处理。系统内部会做负载均衡线程多了也不会互相抢到崩溃。那个并发线程数参数在创建时传0系统默认按CPU核心数来调度实际项目里我习惯根据压测结果微调通常设置为核心数加一到两倍。IOCP模型的精髓在于内存管理因为操作是异步的上下文需要自己new出来完成后再自己delete。常见的设计是给每个连接维护一个上下文结构里面放OVERLAPPED、缓冲区、套接字句柄和状态标志一次投递一个“读”操作等读完成后处理数据再投递一个“写”操作。周而复始这就是高性能网络服务器的核心循环。4. 常见问题与排查技巧实录4.1 ERROR_IO_PENDING到底怎么处理新手最常见的问题就是把ERROR_IO_PENDING当成错误码上报程序提前退出然后一脸懵。记住一个铁律凡是发起异步操作的函数ReadFile、WriteFile、WSARecv、AcceptEx等返回FALSE时先GetLastError()判断如果错误码是ERROR_IO_PENDING那说明操作正常进行中不是失败。只有其他错误码才是真的失败。还有一种情况是在异步操作进行中直接关闭句柄。某些程序在发起IO后因为逻辑错误提前CloseHandle导致后续完成事件成为野指针引用。正确做法是等所有挂起操作完成后确保完成回调或完成队列已经收集了对应的完成包再释放上下文和句柄。4.2 缓冲区生命周期“借用”而非“拷贝”的代价前面说过异步IO的缓冲区是借给你的。操作系统内核在读写磁盘或网卡时直接访问这块内存如果你的逻辑在操作完成前把这些内存释放了或者让它被重分配了内核写入时就会踩到无效内存。典型崩溃表现为随机访问违例地址还不固定。工程上我习惯用一个小技巧给每个IO操作包一个“引用计数”的对象。发起一次操作就加一次引用完成后在回调里减引用并检查计数归零才真正析构缓冲区。命令行Demo里可以用简单的new/delete但服务器项目里就必须认真管理生命周期了。4.3 完成例程为什么不回调如果你用的是完成例程方式Octocallback没有执行九成原因是线程没有进入alertable等待。另一个原因是发起IO的线程已经退出了APC队列整个被销毁回调无从谈起。还有一个小概率同一时刻APC队列里有大量别的APC在排队你的回调排在后面看起来就像“没被调用”。这种情况可以通过在回调里加日志来确认。补充一个容易忽略的细节如果你在DLL里发起异步IO并使用完成例程必须特别注意DLL卸载时机。如果DLL已经卸载了而APC回调的代码地址指向了已卸载的DLL进程会直接崩溃。解决方法是使用DLL的引用计数或者确保所有操作完成后才卸载。4.4 IOCP上下文指针丢失怎么排查用IOCP时GetQueuedCompletionStatus返回的pOv参数只提供了OVERLAPPED指针。如果你只分配了一个裸的OVERLAPPED结构没有把它塞进更大的上下文结构里那么处理完成事件时你完全不知道这个IO属于哪条连接、哪个缓冲区。这就是为什么必须用CONTAINING_RECORD来从OVERLAPPED地址倒推出整个context结构。还有个排查技巧如果GetQueuedCompletionStatus返回FALSE不要急着把它当错误处理。还有一种情况是PostQueuedCompletionStatus投递的用户自定义包它的pOv可以是空指针bytesTransferred和completionKey携带你自定义的数据。这是IOCP模型里用来“通知线程池退出”或“传递控制指令”的标准手段。你在接收端要区分pOv是否为null。4.5 线程池开多少线程合适网上看多了会看到各种公式比如“CPU核心数乘以2”或者“核心数加1”。实际项目中线程数取决于IO操作的类型和延迟。对于网络IO由于涉及网络栈的调度和延迟我通常从核心数的两倍开始压测逐步增加直到吞吐不再提升为止。对于磁盘IO线程数不宜过多因为磁盘本身有队列深度限制线程过多只会增加上下文切换开销。还有一种经验如果你的服务既有IO密集型又有CPU密集型任务可以把工作线程分成两组一组专门跑GetQueuedCompletionStatus一组跑计算任务。中间用无锁队列衔接。这个分层设计能大幅降低IO线程的阻塞概率但实现复杂度会上升不少。4.6 调试异步IO的辅助工具调试异步IO比同步IO难得多传统断点思路经常失效。我习惯在几个关键位置打日志发起操作时记录上下文地址和参数完成回调/完成队列取出时记录上下文地址和字节数释放上下文时记录地址。如果上下文被重复释放或遗漏释放日志里能看到重复地址或者永不出现的地址。Windows自带的性能监视器里有一项“IO完成端口”相关的计数器可以观察完成端口的队列长度、线程数等指标。还有系统事件追踪ETW功能能详细记录IO请求从发起到完成的全过程定位内核层面的延迟非常有帮助。5. 最后分享一点个人经验这套异步IO的东西我刚接触时也绕了很大一圈。现在回头看最大的经验教训就是不要迷信某个技术“银弹”。事件通知、完成例程、IOCP各有各的位置选型前先把业务形态想清楚。代码写出来只是开始真正吃透是在并发量上来、各种诡异问题开始冒头的时候。我记得有一次压测某跨平台系统的IOCP服务端发现连接数到3000左右吞吐上不去排查了很久才发现是线程池里有个线程在做阻塞型的日志写入把整个IO线程池都拖慢了。后来把所有日志IO从工作线程里拆出去用单独的后台线程批量刷盘吞吐立刻翻倍。这种问题在教科书里根本学不到只有亲手压测排查才能积累经验。另一点建议是做异步IO的代码优先级第一是正确性第二是清晰度。宁可多写几行注释画出每个IO上下文的生命周期也不要在代码里玩弄各种奇技淫巧。异步IO出bug的时候问题往往不在单点而在状态流转。多花时间把状态机画清楚比什么都管用。这篇笔记写到这里正文的技术内容已经完整了。最后再留一个小提示如果你打算深入IOCP做网络服务强烈建议把“套接字与完成端口的绑定方式”单独研究一下尤其是AcceptEx和WSARecv的配合使用那是另一个可以写一整篇笔记的话题。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
