在 C# 中，async 和 await 关键字极大简化了异步编程的书写方式，但其背后并不是运行时魔法，而是编译器在编译期对代码进行的一次结构性重写。编译器会将每一个 async 方法转换为一个实现了 System.Runtime.CompilerServices.IAsyncStateMachine 接口的状态机结构体，通过状态字段来记录执行进度，并在等待的任务未完成时把控制权交还调用方。
一、状态机的基本结构
当我们编写一个普通的 async 方法时，C# 编译器并不会直接生成多线程切换逻辑，而是生成一个隐藏的状态机类或结构体。这个类型通常命名为 <MethodName>d__0 这类形式，它包含若干个关键字段：一个是 int 类型的 <>t__state，用来表示当前执行到哪一步；另一个是 AsyncTaskMethodBuilder 或 AsyncVoidMethodBuilder 类型的 builder，负责创建返回的 Task 并在方法逻辑结束时完成它；此外，原方法中的局部变量和参数也会被提升为状态机的字段，这样才能在多次回调之间保持数据。
状态机最核心的方法是 MoveNext。编译器把原 async 方法中的代码按 await 表达式拆分成多个片段，每个片段对应一个状态值。第一次调用 MoveNext 时，状态可能是 -1 或 0，执行到某个 await 处如果发现右侧任务尚未完成，就把当前状态设为对应片段编号，然后直接返回；当任务通过继续回调（continuation）再次驱动 MoveNext 时，就根据状态跳转到断点之后继续执行。这种“保存现场、退出、恢复”的模式，正是状态机实现异步而不阻塞线程的基础。
二、await 表达式的编译展开
以一段简单代码为例，我们可以观察 await 在编译层面的含义。下面这段代码在逻辑上先访问网络再处理结果：
using System;
using System.Net.Http;
using System.Threading.Tasks;
public class Demo
{
public async Task<string> FetchAsync()
{
HttpClient client = new HttpClient();
// 等待网络请求，若未完成则退出状态机
string html = await client.GetStringAsync("https://ipipp.com");
return html.Substring(0, 10);
}
}
编译器会将上述 FetchAsync 改写为类似如下结构的伪代码逻辑，其中 await 被替换为对任务是否完成的判断：
struct <FetchAsync>d__0 : IAsyncStateMachine
{
public int <>t__state;
public AsyncTaskMethodBuilder<string> <>t__builder;
public Demo <>4__this;
private HttpClient <client>5__1;
private string <html>5__2;
private TaskAwaiter<string> <>u__1;
public void MoveNext()
{
try
{
if (<>t__state == 0)
{
<client>5__1 = new HttpClient();
<>u__1 = <client>5__1.GetStringAsync("https://ipipp.com").GetAwaiter();
if (!<>u__1.IsCompleted)
{
<>t__state = 0;
<>t__builder.AwaitUnsafeOnCompleted(ref <>u__1, ref this);
return;
}
}
<html>5__2 = <>u__1.GetResult();
<>t__state = -2;
<>t__builder.SetResult(<html>5__2.Substring(0, 10));
}
catch (Exception e)
{
<>t__builder.SetException(e);
}
}
public void SetStateMachine(IAsyncStateMachine m) { }
}
从这段展开代码可以看到，await 并非阻塞等待，而是先获取任务的 awaiter，检查 IsCompleted。若任务已完成则直接取结果；若未完成，则注册继续回调并立刻返回，此时调用 FetchAsync 的线程不会被卡住，而是拿到一个未完成的 Task 对象。等网络请求结束，线程池或原同步上下文会再次调用 MoveNext，从保存的状态恢复并执行后续代码。
这一机制也解释了为什么 async 方法内部不能使用 ref 或 out 参数：这些参数必须作为状态机字段被提升，而引用传递的语义在跨回调时无法安全保持。编译器通过禁止此类用法，避免了状态机字段捕获带来的生命周期问题。
三、Builder 与任务完成通知
AsyncTaskMethodBuilder 在状态机中承担着桥接作用。它在状态机创建之初就生成了最终的 Task 实例，并将该实例作为 async 方法的返回值交给调用方。无论 MoveNext 执行了多少次，只要方法逻辑没有结束，Task 就一直处于未完成状态；当代码跑完最后一行或抛出异常时，builder 的 SetResult 或 SetException 才会将 Task 转为完成态，从而唤醒所有等待该 Task 的后续逻辑。
需要注意的是，builder 在 AwaitUnsafeOnCompleted 中决定后续 MoveNext 由谁执行。默认情况下，如果当前存在 SynchronizationContext（例如 UI 线程上下文），continuation 会投递回该上下文，这也是为什么 WPF 或 WinForms 中 await 之后还能安全操作界面的原因。若使用 ConfigureAwait(false)，则告诉 builder 不必回原上下文，可直接在线程池上继续，通常能减少死锁风险并提升吞吐。
四、状态机带来的常见误区
很多开发者误以为 async 方法一定会开新线程。实际上状态机本身不创建线程，它只是把代码切成片段，真正执行片段的线程取决于 awaiter 的继续调度策略。如果一个 async 方法内部没有任何真正异步等待（例如直接 return Task.FromResult(1)），那么整个 MoveNext 可能在同一线程上一次性跑完，没有任何并发收益。
另一个典型误区是在异步方法中使用 Task.Wait 或 Result 同步阻塞。由于状态机可能在原线程上下文等待继续回调，而该回调又被你的阻塞操作霸占，就会出现经典死锁：状态机永远等不到线程来跑 MoveNext，而你的代码又死等 Task 完成。理解状态机的回调驱动模型，就能明白为什么应该一路 async/await 到底，而不是在中间插入阻塞调用。
五、调试与性能注意点
状态机结构体分配在栈或堆上取决于生命周期，但由于包含了闭包变量，多数情况下会作为引用类型或装箱对象参与回调，因此高频异步调用会带来一定分配开销。对于极端性能场景，可评估使用 ValueTask 配合轻量状态机，或借助池化手段降低 GC 压力。调试时，虽然编译器生成的 <MethodName>d__0 类型不可见，但调用栈中常出现 MoveNext 与 AsyncTaskMethodBuilder，结合异常堆栈可定位到具体 await 位置。
总体来看，C# 的 async/await 状态机是一种以编译期重写换取编码舒适度的方案。它用字段保存上下文、用状态编号切分逻辑、用 builder 管理任务生命周期，使异步流程写得像同步代码。掌握其原理后，面对上下文丢失、死锁和性能瓶颈，都能从状态切换与继续调度层面给出准确解释与修复思路。
async_await状态机 C#异步修改时间：2026-08-11 18:15:37