图解 .NET async/await
我非常认同一图胜千言的说法，因此我也喜欢用图来解释各种技术概念。本文通过图解来说明 .NET 中 async/await 如何工作。
async/await 背后的主要思想是，当我们在一个正在进行的 I/O 操作上等待时，调用线程可以被释放出来做其他工作，它提供了很好的线程可重用性。因此，具备更好的可扩展性，与同步/等待方式相比，更少的线程可以处理相同数量的操作。
这里的主要作用是进行所谓的 overlapped I/O（在 Windows 环境），它允许异步地将 I/O 操作委托给操作系统，只有在操作完成后，提供的回调才通知调用者结果。这里的主要工作是 I/O 完成端口（IOCP）。
I/O 完成端口是 Windows 中异步 I/O 的一种非常有效的机制，只需要一个端口就可以观察大量正在进行的操作。在 .NET 环境下，实际上只由一个 IOCP 来完成。然后，几个 I/O 完成线程（由 ThreadPool 管理）观察这个单一的 IOCP。IOCP 线程的典型数量大约等于逻辑处理器的数量，但 ThreadPool 默认设置下可以创建多达 1000 个线程（我们可以改变这个最大值）。
I/O 操作的回调是在其中一个 IOCP 线程上执行的，它设置操作的结果并决定：
在 IOCP 线程上原地执行 continuation 操作，这样做有一定好处，因为它不会产生上下文切换，避免了缓存回收，但有可能出现用户代码污染 IOCP 线程（并导致线程泄漏）。
或者将其调度回另一个地方，可能是由 SynchronizationContext / TaskScheduler 指定，所以典型的情况是被工作线程排队执行。
通常情况下，大多数的 continuation 都被调度给工作线程。其中一个最重要的例外是 Windows 的 HttpClient continuation（自 .NET Core 2.1 以来）。
注意：在 Linux 环境下，使用 epoll 机制代替 IOCP。通过 epoll 线程监听事件，将 continuation 安排给工作线程（不会出现内联 inlining ）。并且使用 AIO 和 io_uring 重建 Linux 的 ThreadPool 工作。
所有的点都由一个状态机实例连接起来，进行状态跟踪，执行 continuation，保持上下文等。
这张图片也让我想起 Stephen Cleary 著名文章 "没有线程 (1)"，他解释说，当一个异步 I/O 操作被执行时，没有 "执行用户代码" 的线程被消耗。事实上也确实如此，虽然有评论中提到，有 IOCP 线程被阻塞，用于处理 I/O 完成端口通知，但几乎可以视为没有线程。
(1) https://blog.stephencleary.com/2013/11/there-is-no-thread.html
我发表在 Twitter 上面关于 ThreadPool 和 I/O 完成端口关系的图片也引起不少讨论，有兴趣的读者可以参阅。
https://twitter.com/konradkokosa/status/1264855190131400704
英文原文：
https://tooslowexception.com/net-asyncawait-in-a-single-picture/
参考阅读：
本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。