这是最纯粹形式的异步的基本真理：没有线程。
反对这个道理的人是军团。 “不，”他们哭了，“如果我正在等待一个操作，一定要有一个线程正在等待！ 这可能是一个线程池线程。 或OS线程！ 或者有设备驱动程序的东西...“
不要那些哭泣。 如果异步操作是纯粹的，那么就没有线程。
怀疑者不信服。 让我们幽默他们
我们将跟踪异步操作一直到硬件，特别注意.NET部分和设备驱动程序部分。 我们必须通过省略一些中间层的细节来简化这个描述，但我们不会偏离真相。
考虑一个通用的“写入”操作（对于文件，网络流，USB烤面包机，无论如何）。 我们的代码很简单：
private async void Button_Click(object sender, RoutedEventArgs e)
{
byte[] data = ...
await myDevice.WriteAsync(data, 0, data.Length);
}我们已经知道UI线程在await期间没有被阻止。问题：是否有另一个线程必须在Blocking的祭坛上牺牲自己，以便UI线程可以活下来？
我们深入探索
第一站：基类库（例如，输入BCL代码）。我们假设WriteAsync是使用基于重叠(Overlapped)I/O的.NET中的标准P/Invoke异步I/O系统来实现的。因此，这将启动设备底层HANDLE上的Win32 重叠(Overlapped)I/O。
操作系统然后转到设备驱动程序并要求它开始写操作。它通过首先构建表示写请求的对象来实现;这被称为I/O请求分组（IRP）。
设备驱动程序接收IRP并向设备发出命令以写出数据。如果设备支持直接存储器访问（DMA），则可以像将缓冲区地址写入设备寄存器一样简单。这就是设备驱动程序所能做的一切，它将IRP标记为 “pending” 并返回给操作系统。
真相的核心在这里：设备驱动程序不允许在处理IRP时阻止。 这意味着如果IRP无法立即完成，那么它必须被异步处理。 即使是同步的API也是如此！ 在设备驱动程序级别，所有（有意义的）请求都是异步的。
无论
I/O请求的类型如何，代表应用程序发给驱动程序的内部I/O操作都是异步执行的
由于IRP“pending”，操作系统返回到基类库，该库将不完整的任务返回到按钮单击事件处理程序，该事件处理程序将挂起异步方法，并且UI线程继续执行。
我们已经跟随这个请求进入系统的深渊，直到物理设备。
写入操作现在是“in flight”。有多少线程处理它？
答案是没有。
没有设备驱动程序线程，OS线程，BCL线程或正在处理该写操作的线程池里的线程。没有线程。
现在，让我们跟随内核守护进程的响应，回归到凡人的世界。
写入请求开始一段时间后，设备完成写入操作。它通过中断通知CPU。
设备驱动程序的中断服务程序（ISR）响应中断。中断是一个CPU级事件，暂时占用CPU的任何线程的运行控制权。您可以将ISR视为“借用”当前正在运行的线程，但我更喜欢将ISRs视为在“线程”的概念不存在的低级别执行，因此它们进入“所有”线程，可以这么说。
无论如何，ISR被正确写入，所以它所做的只是告诉设备“谢谢你的中断”并排队延迟过程调用（DPC）。
当CPU被中断打扰时，它会设法找到足够的时间去执行它的DPCs。 DPCs也执行得如此之低，以至于说“线程”不太正确;像ISR一样，DPC直接在CPU上执行，“在线程”下面。
DPC将表示写入请求的IRP标记为“complete”。但是， “completion”状态只存在于操作系统层面;该进程有自己的内存空间必须通知。因此，操作系统将特殊的内核模式的异步过程调用（APC）排队到拥有HANDLE的线程。
由于library/BCL正在使用标准的P/Invoke重叠I/O系统，所以它已经使用作为线程池的一部分的I/O完成端口（IOCP）来注册句柄。因此，I/O线程池线程被简单地借用来执行APC，它通知任务完成。
该任务捕获了UI上下文，因此它不会直接在线程池线程上恢复async方法。相反，它将该方法的继续排队到UI上下文中，并且UI线程设法找到足够的时间去处理它时将恢复执行该方法。
所以，我们看到请求在飞行中没有线程。当请求完成时，各种线程被“借用”，或者已经对他们进行了短暂的排队。这个工作通常在毫秒左右或者（例如，在线程池上运行的APC）下降到微秒左右（例如，ISR）。但是没有线程被阻塞，只是等待该请求完成。
现在，我们遵循的路径是“标准”的路径，有点简化。 有无数的变化，但核心的真相保持不变。
“在某处处理异步操作时必须有线程”的想法不是真相。
释放你的心灵。 不要试图找到这个“异步线程” - 这是不可能的。 相反，只想实现真相：
没有线程。
