我非常认同一图胜千言的说法,因此我也喜欢用图来解释各种技术概念。本文通过图解来说明 .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/