注： 最近Java 19引入的虚拟线程火热，还有很多人羡慕 go的 coroutine，很多同学一直有一个疑问： C# 有 虚拟线程或者 coroutine吗，下面的这个回答可以解决问题。这里节选的是知乎上的hez2010 的高赞回答：https://www.zhihu.com/question/554133167/answer/2690808608 

C# 的 async/await 其实就是一个通用的异步编程模型，编译器会对 async 方法采用 CPS 变换，以 await 为分界线将方法进行拆分，然后使用一个状态机来驱动执行。用现在比较潮的说法就是 stackless coroutine。

例如说以下代码：

编译完之后就变成类似这样的玩意（极度简化版）

其中的 Scheduler 是交由用户自己实现的，.NET 默认用线程池来做 Scheduler，但并不妨碍一些框架可以自行设计一个事件循环来做成 JavaScript 的 Promise。.NET 还提供了 AsyncMethodBuilder 的 type trait 来让你自己实现这个状态机和你自己的 Task 类型，因此你可以最大程度发挥想象来编写你想控制的一切。

你可以发现 async/await 本身并没有涉及到任何线程、调度相关的细节内容。换言之，async/await 是一个纯编译器特性。C# 在推出 async/await 的时候，考虑到方便用户的使用内置了 Task 和基于线程池的调度器满足一般使用，我们一般叫这个为 async runtime，其实就是根据上面所说的 type trait 实现出来的东西，后来为了减少分配又有了 ValueTask，以及 ASP .NET Core 为了性能又自己实现了个 PooledValueTask，Blazor WebAssembly 又因为浏览器平台不支持多线程于是实现了个基于事件循环的单线程 Scheduler，Unity 社区还有自己做的 UniTask 等等。当然，用户自己也可以实现自己的 async runtime。而 C++、Rust 则一开始只是将其作为语言特性推出，async runtime 则完全交给用户实现，标准库里除了一些 async primitives 之外什么都不带，于是 Rust 里出现了 async-std 和 tokio 等 async runtime，而 C++ 的话社区实现了一大堆的 async runtime，然后标准委员会还没吵出要怎么实现 STL 里的 async runtime。

啊，扯远了，继续说优缺点。

stackless coroutine 不需要寄存器上下文备份和恢复，需要引用什么局部变量只需要很简单的将它们提升到这个状态机的闭包里即可，而且是需要什么才提升什么，如果只有一个 int 需要引用，那就只需要一个装箱后的 int 那么多字节的堆内存，大概也就十几 B。此外，它遵循正常的分支判断和函数调用，因此不会打断 CPU 的控制流，分支预测和缓存友好。

而类似 goroutine 的 stackful coroutine 方案则是在用户态自己模拟系统线程来做了个用户态线程，然后在运行时上自己调度，于是每一个 goroutine 都需要创建自己的 stack 用来保存上下文（对应线程的 stack），这一个 stack 就是至少 8K，开多了占用会变得非常大。而且这种方案需要操作寄存器来进行上下文的备份和恢复，会打断正常的 CPU 控制流，使得分支预测失误和缓存缺失问题非常严重。唯一的好处就是不需要修改代码，对已有老代码改造起来非常方便。但是如果不存在已有老代码这种东西的话，这种方案可以说一点优势都没有，我始终认为 stackful coroutine 只是一个在已有老代码已经不方便修改了才应该使用的东西，否则完全没有意义。

综上所述，async/await 就是一个通用的异步编程方案，这个“异步”和它的调度方式是不绑定的，由用户想怎么实现就怎么实现，因此可以做到最高的灵活度；并且由于不需要维护所谓的虚拟线程的 stack，只需要将用到的局部变量提升到闭包内即可，资源占用也很低；并且由于不打断 CPU 控制流，性能更高，而且一些情况下是可以直接把 coroutine inline 掉的。

缺点自然也很明显，那就是代码不好编写，而且对代码有侵入性。如果要用 async/await，那必然需要将所有需要改造的阻塞调用改成 async/await，否则就约等于没有异步。

最后提一嘴性能问题，网上大为流传的 Go vs C#, part 1: Goroutines vs Async-Await | by Alex Yakunin | Medium，其中给 C# 测试代码加入了毫无意义的 await Task.YieldAsync()，带来了大量无意义的调度开销，这等价于给测试代码里面加 Thread.Sleep(1)，何必呢。况且这个测试当时甚至用的是几乎一点优化都没有的 .NET Core 1.1，把原文用的 Go 和 .NET 升级到今天的 Go 1.19 和 .NET 7.0，C# 带着 await Task.YieldAsync() 这一行故意负优化都能跑到跟 Go 不相上下，去掉之后更是只需要不到 Go 一半的时间。

而且由于前面所说的 stackful coroutine 内存问题，没有大内存是没法流畅跑完 Go 的测试的，因为 goroutine 的内存开销非常大，在这个测试中需要耗费几个 G 的内存，如果内存不够会导致大量 GC 使得效率非常低下；对应 C# 的版本几乎没有什么内存消耗，十几 M 内存就够跑完了。