.NET中为何async/await下CPU绑定代码锁GUI而IO绑定代码不会

async/await本质是一套语法糖，它本身不会创建后台线程、不会主动让代码脱离当前调用线程运行，唯一的作用是：当碰到未完成的Task时，把当前线程的控制权交回调用方，等Task执行完成后，再沿着之前的上下文恢复代码执行。 #

第24行CPU绑定代码卡GUI的原因 #

顺着代码的执行流逐行追踪：

• 从按钮点击触发事件处理程序，到进入TestAsync，再进入DoWork方法，代码全程跑在GUI线程上，还没碰到任何会触发控制权移交的await节点。
• TimeConsumingCPUBound()是完全同步的纯CPU计算逻辑，没有被包装到任何后台任务中，这4秒的字符串拼接计算会全程占满GUI线程。
• Windows系统的GUI重绘、鼠标点击、消息响应都依赖这个唯一的GUI线程处理，线程被占满的时候，自然没法处理这些界面请求，表现就是窗口卡死。

第27行await Task.Delay不卡GUI的原因 #

• 代码执行到await Task.Delay(10000)时，框架会检测到这个延迟任务还没完成，立刻把GUI线程的控制权交还给窗口消息循环，让线程可以正常响应界面操作。
• 10秒的延迟计时完全由系统底层定时器完成，不需要占用应用的任何线程。等计时结束后，框架才会切回GUI线程，执行await后面的剩余代码。

如何理解“async/await对CPU、IO绑定场景都适用”的说法 #

这个结论的适用前提是：你要await的Task本身已经把对应工作跑在了非GUI线程上。
如果CPU绑定工作没有被卸载到后台，哪怕整个方法全用async语法写，同步执行的部分该卡GUI还是会卡。正确的异步CPU写法需要主动把耗时计算丢到后台线程执行：

private async Task<double> DoWork()
{
    // 将CPU密集任务交给线程池后台执行，不占用GUI线程
    await Task.Run(() => TimeConsumingCPUBound());
    // 等待IO绑定的延迟操作完成
    await Task.Delay(10000);
    return 0;
}

修改后的代码执行到第一个await时，GUI线程就会立刻交还控制权，CPU计算全程都在后台跑，自然不会卡界面——这时候用async/await消费后台Task的结果，和处理IO绑定任务的体验没有任何区别。 #

两个常见认知误区 #

• 只要给方法加了async关键字，内部代码就会自动异步运行。实际上async方法在碰到第一个未完成的await之前，所有代码都是同步在调用线程上执行的。
• CPU密集任务和async/await不兼容。只要通过Task.Run把CPU工作卸载到后台线程，后续的异步消费流程和IO绑定任务的写法完全一致。

内容的提问来源于stack exchange，提问作者穆罕默德 - Moh