.NET中的异步编程（四）- IO完成端口以及FileStream.BeginRead

来源：http://www.verydemo.com/demo_c134_i36767.html

写这个系列原本的想法是讨论一下.NET中异步编程风格的变化，特别是F#中的异步工作流以及未来的.NET 5.0中的基于任务的异步编程模型。但经过三篇文章后很多人对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完成端口，仅仅是讲解，这些代码并不是真…………………………………………………………………………