【IT168 专稿】写这个系列原本的想法是讨论一下.NET中异步编程风格的变化，特别是F#中的异步工作流以及未来的.NET 5.0中的基于任务的异步编程模型。但经过前几篇文章（为什么需要异步，传统的异步编程，使用CPS及yield实现异步）的发表后，很多人对IO异步背后实现的原理以及为什么这样能提高性能很感兴趣。其实我本不想花更多的文字在这些底层实现的细节上，一来我并不擅长这些方面，二来我们使用.NET的异步IO就不需要关心这些底层东西，因为已经为你封装完备了。不过为了避免大家一再在这上面商讨，我还是在这个系列中间插入了一篇来解释一下。
本文我将从内核对象IO完成端口开始介绍，然后来瞧瞧.NET BCL中的FileStream.BeginRead是如何利用IO完成端口来实现的。
IO完成端口(IO Completion Port)
大多数人应该或多或少地听说过IO完成端口这么个东西，而且也知道它是实现高性能IO，高伸缩性应用的尚方宝剑。IO完成端口是一个非常复杂的内核对象，其实现的也非常巧妙，细细琢磨还是非常有意思的。
创建高伸缩性的应用的一个基本原则就是：创建更少的线程。线程数更少首先消耗的资源就少，每个线程的创建除了要浪费CPU时间外，还要创建一系列的数据结构用来保存线程相关的一些信息：用户栈，线程上下文，内核栈等。这个总共加起来大概1.5M左右，那么你算算你的32位机器总共能使用多少内存?那么对应地能创建多少线程?可能有人讲那对于64位的就无所谓了。嗯，在资源占用这方面64位确实不用担心。但是系统中可运行的线程数越多，你的CPU数又是有限的(8个?80个?)。Windows的任务调度机制是每个线程会运行一个时间片，然后Windows抢占式的调度另一个线程运行。那么线程数越多，Windows势必要进行更频繁的线程上下文切换。线程上下文切换对系统性能的影响在这里我就不多说了，你可以搜搜资料。
那么如何做到创建更少的线程，而又干更多的事儿呢?答案就是“不等待”。相对CPU来说，IO设备的速度简直低的要命。就好像飞机和拖拉机的差别一样，我们可不能让拖拉机拖了飞机的后退儿。而IO完成端口就是为了这个而生的：创建更少的线程，干更多的事儿。
IO完成端口首先不是一个我们看得见摸得着的什么插口，也和我们常说的80这样的端口不同。你可以将其理解为一个数据结构或一个对象(下面我会用C#的代码来辅助讲解IO完成端口，仅仅是讲解，这些代码并不是真实的实现)：
Windows提供了一个CreateIoCompletionPort API来创建IO完成端口，实际上这个API有两个作用：创建IO完成端口和将一个IO设备与该端口绑定。创建IO完成端口时有一个很重要的参数：指定同时最多能有多少个线程并行运行，这就是为了保证更少的线程，如果你将这个数值指定为0，那么默认值就会是你机器的CPU数。IO端口里还有一个IO设备句柄列表，你可以将很多设备句柄与这个端口绑定(文件、Socket等)：
HANDLE CreateIoCompletionPort(
//设备句柄
HANDLE hFile,
//已有的IO完成端口句柄，如果这里已经指定，则是将前面指定的设备与该端口绑定
HANDLE hExistingCompletionPort,
//因为一个IO完成端口可以绑定很多设备，可以用这个来区分
ULONG_PTR CompletionKey,
//允许同时运行的线程数
DWORD dwNumberOfConcurrentThreads
);
//创建一个IO完成端口
HANDLE hIoPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,0,2);
//创建文件，如果要异步访问文件则需要指定FILE_FLAG_OVERLAPPED
HANDLE hFile = CreateFile(..);
//将上面创建的文件句柄与刚才创建的IO完成端口绑定，不仅仅是文件可以
CreateIoCompletionPort(hFile,hIoPort,1,2);
