chromeplugin叛
正文
异步/等待解决了什么问题？
在传统同步I/O操作中（如文件读取或Web API调用），调用线程会被阻塞直到操作完成。这在UI应用中会导致界面冻结，在服务器应用中则造成线程资源的浪费。async/await通过非阻塞的异步操作解决了这些问题，同时保持了代码的线性结构和可读性。
编译器的转换：从方法到状态机
当你用async标记一个方法时，C#编译器并不会直接执行你的代码。相反，它会将该方法重写为一个状态机结构体。这个结构体实现了IAsyncStateMachine接口，包含以下关键部分：
当前状态（整数，表示执行暂停的位置）
捕获的局部变量和参数（提升为字段以便在await之间保持状态）
方法构建器（如AsyncTaskMethodBuilder用于Task返回）
原始方法被转换为一个存根(stub)方法：它在栈上创建状态机实例，初始化并启动它。而你的主要代码逻辑则被移动到状态机的MoveNext()方法中，通过状态值和switch语句实现执行点的跳转。
特别重要的是：如果异步方法同步完成（所有等待的操作已经完成），状态机将保留在栈上，不会发生堆分配。只有当真正的await暂停执行时，结构体才会被装箱到堆中。
一个简单示例
考虑以下异步方法：
public async Task DownloadDataAsync(string url)
{
using var client = new HttpClient();
string data = await client.GetStringAsync(url);
return data.Length;
}
在编译时，编译器会将该方法重写为状态机结构体，并生成一个存根方法替换原始方法签名。方法体被拆分并移入状态机的MoveNext()方法中，按状态组织。
运行时调用流程：
生成的存根创建状态机实例（初始在栈上）
初始化状态机（状态设为-1，捕获必要参数/局部变量）
调用MoveNext()开始执行
在MoveNext()内部：
执行从当前状态开始，直到遇到await
如果等待的任务已完成，继续同步执行（快速路径，无堆分配）
如果任务未完成，注册继续回调，立即返回控制（非阻塞），并暂停执行
任务完成后，继续回调会再次调用MoveNext()，从await点恢复执行
编译器生成的状态机
以下是编译器生成的状态机简化伪代码（基于Release模式下的反编译结果）：
private struct d__1 : IAsyncStateMachine
{
public int <>1__state; // 状态：-1=开始，0=等待中，-2=完成
public AsyncTaskMethodBuilder <>t__builder;
public string url; // 捕获的参数
private string 5__2; // 提升的局部变量
private HttpClient 5__3; // using变量也被提升
private void MoveNext()
{
int num = this.<>1__state;
try
{
if (num == -1) // 初始执行
{
this.5__3 = new HttpClient();
Task getTask = this.5__3.GetStringAsync(this.url);
var awaiter = getTask.GetAwaiter();
if (!awaiter.IsCompleted)
{
this.<>1__state = 0; // 标记为等待中
this.<>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
return; // 在此暂停 - 继续回调稍后调用MoveNext
}
// 已完成时的快速路径
this.5__2 = awaiter.GetResult();
}
else // num == 0 → await后恢复
{
this.5__2 = /* awaiter.GetResult()逻辑 */;
}
// await之后的代码
int result = this.5__2.Length;
// 清理
this.5__3?.Dispose();
// 设置最终结果
this.<>1__state = -2;
this.<>t__builder.SetResult(result);
}
catch (Exception exception)
{
this.<>1__state = -2;
this.<>t__builder.SetException(exception);
}
}
void IAsyncStateMachine.MoveNext() => MoveNext();
// SetStateMachine(...)为简洁省略
}
原始方法被转换为类似这样的存根：
public Task DownloadDataAsync(string url)
{
var stateMachine = new d__1();
stateMachine.<>t__builder = AsyncTaskMethodBuilder.Create();
stateMachine.url = url;
stateMachine.<>1__state = -1;
stateMachine.<>t__builder.Start(ref stateMachine);
return stateMachine.<>t__builder.Task;
}
理解状态机的重要性
理解状态机的工作机制有助于我们：
认识同步完成时的零分配快速路径
理解为什么局部变量需要被捕获（它们成为结构体的字段以便在暂停和恢复状态时使用）
掌握正确的性能特征（当操作正确时开销最小）
正如微软文档所述："编译器会把你的程序转化为状态机。该构造会追踪代码中的各种操作和状态，比如当代码达到等待表达式时放弃执行，以及在后台作业完成时恢复执行。"
结论
async/await不仅仅是让异步代码更简洁的语法糖，其背后是编译器将顺序逻辑转换为高效状态机的复杂过程。通过深入理解这一机制，我们可以：
编写更高效的异步代码
避免常见的性能陷阱
更好地调试异步程序
下次使用async/await时，请记住：你正在利用C#编译器的强大魔法，将看似简单的顺序代码转换为高效的状态机实现。这种理解将帮助你成为更优秀的.NET开发者。掣诹嘏馗