async和await通过异步非阻塞方式避免UI卡顿，提升响应性；其底层由编译器生成状态机实现，基于Task模型管理异步操作；使用时需避免死锁、慎用async void，并合理处理异常与上下文切换。
C#中的
async
和
await
关键字是现代C#异步编程的核心，它们提供了一种编写非阻塞代码的简洁方式，让程序在等待I/O操作（如网络请求、文件读写、数据库查询）完成时，能够释放当前线程去处理其他任务，从而提高应用程序的响应性和吞吐量。简单来说，它们让异步代码看起来和写同步代码一样直观。
解决方案
要理解
async
和
await
，我们得先从它们解决的问题说起。想象一下，你正在写一个桌面应用，需要从网上下载一张大图。如果用传统的同步方式，下载过程中你的应用界面就会“卡死”，用户体验极差。
async
和
await
就是为了解决这类问题而生。
当一个方法被标记为
async
时，它就表明这个方法内部可能包含一个或多个
await
表达式。而
await
关键字，则只能在
async
方法中使用，它告诉编译器：“嘿，我这里要等待一个异步操作完成，在等待期间，当前线程可以去做别的事情，等操作完成了再回来从这里继续执行。”
具体来说，
await
后面通常跟着一个
Task
或
Task
对象。当执行到
await
时：
如果被
await
的异步操作（比如
HttpClient.GetStringAsync()
）还没有完成，
await
会立即将控制权返回给调用者。此时，当前方法并没有结束，它只是“暂停”了，并且注册了一个回调，告诉系统当异步操作完成后，从暂停的地方继续执行。当异步操作完成时，系统会调度剩余的代码继续执行，通常是在捕获到的同步上下文（例如UI线程的上下文）或线程池线程上。
这样一来，耗时的操作就不会阻塞主线程（比如UI线程），用户界面就能保持响应，程序也能更高效地利用系统资源。
C#中async/await如何避免UI卡顿，提升用户体验？
这是一个非常实际的问题，也是
async/await
最直接的价值体现。在没有
async/await
的日子里，我们为了避免UI卡顿，不得不手动创建新线程，然后通过
Invoke
或
Dispatcher.BeginInvoke
等机制，将结果安全地传回UI线程更新界面。这过程复杂、容易出错，而且代码可读性很差。
async/await
的出现，极大地简化了这一过程。当你在UI线程上调用一个
async
方法，并在其中
await
一个耗时操作时，
await
会智能地捕获当前的同步上下文。这意味着，当异步操作完成后，
await
后面的代码会尝试在捕获到的那个上下文中继续执行。对于UI应用程序来说，这个上下文就是UI线程。
所以，当一个网络请求在后台线程完成时，
await
会自动确保更新UI的代码（比如
myTextBox.Text = result;
）是在UI线程上执行的，你不需要再手动去处理线程切换。这就像是
await
在说：“你去忙吧，我来帮你看着，等结果回来了，我会敲门告诉你，并且帮你把结果送到你手上。” 这样，UI线程在等待期间可以自由地处理用户的点击、拖拽等事件，从而避免了“假死”现象，大大提升了用户体验。它不仅让代码更简洁，还从根本上改变了我们编写响应式应用程序的方式。
async和await的底层原理是什么？它们与Task有何关系？
要深入理解
async
和
await
，就必须触及其底层原理和与
Task
的关系。这并不是什么魔法，而是编译器和.NET运行时协同工作的结果。
从根本上说，
async
和
await
是编译器语法糖。当你标记一个方法为
async
并使用
await
时，C#编译器会将其重写（rewrite）成一个状态机（state machine）。这个状态机是一个复杂的类，它包含了原始方法中的所有局部变量、参数，以及一个记录当前执行到哪一步的状态变量。
Task
（或
Task
）则是异步操作的代表。当你调用一个返回
Task
的方法时，你并没有立即得到结果，而是得到了一个承诺（Promise），这个承诺代表了未来的某个时间点会有一个结果。
Task
对象本身包含了操作的状态（是否完成、是否出错、结果是什么等）。
当
await
遇到一个未完成的
Task
时，它会：
保存当前方法的状态（局部变量、指令指针等）。将控制权返回给
async
方法的调用者。注册一个回调到
Task
上，告诉
Task
一旦完成，就通知状态机继续执行。
当
Task
完成时，状态机就会被唤醒，从之前暂停的地方继续执行。整个过程，线程可能已经切换了多次，但对于开发者来说，代码看起来仍然是顺序执行的。这种机制避免了手动管理回调和线程的复杂性，将异步编程从“回调地狱”中解救出来。
Task
就是这个异步操作的“句柄”或“票据”，
async
和
await
则是操作这个票据的语法糖，让整个流程变得平滑和易于理解。
在使用async/await时常见的陷阱和最佳实践有哪些？
尽管
async/await
极大地简化了异步编程，但如果不注意，也容易踩坑。
一个常见的陷阱是死锁，尤其是在UI应用程序中。当你在一个同步方法中，通过
.Result
或
.Wait()
来阻塞性地等待一个
async
方法的完成时，如果这个
async
方法在内部又尝试回到UI线程（通过捕获的同步上下文），而UI线程又被
.Result
或
.Wait()
阻塞了，那么就会发生死锁。UI线程在等待异步方法完成，异步方法在等待UI线程空闲以继续执行，形成循环等待。
最佳实践之一是：永远不要在同步代码中阻塞性地等待异步操作完成，除非你确定没有同步上下文需要捕获（例如在控制台应用中）。如果必须等待，考虑使用
ConfigureAwait(false)
来避免捕获上下文，但更好的做法是让整个调用链都变成异步的。
另一个陷阱是使用
async void
。
async void
方法主要用于事件处理器，它无法被
await
，这意味着你无法知道它何时完成，也无法捕获它抛出的异常。一旦
async void
方法抛出未处理的异常，它会直接崩溃整个应用程序，而不是像
Task
那样将异常封装起来。因此，除了事件处理器，尽量避免使用
async void
。
此外，异常处理也需要注意。在
async
方法中，
await
会像同步方法一样，将异步操作抛出的异常重新抛出。所以，你可以像处理同步代码一样，使用
try-catch
块来捕获异步操作中的异常。这比传统的回调模式下的异常处理要直观得多。
最后，性能考量。虽然
async/await
不会引入太多额外的开销，但过度细化异步操作，或者在不必要的地方使用
async/await
，也可能带来不必要的上下文切换开销。对于CPU密集型任务，
async/await
并不能直接提升性能，因为它们主要用于I/O密集型任务。对于CPU密集型任务，更适合使用
Task.Run
将其放到线程池中执行，以避免阻塞主线程。记住，
async/await
的核心是“不阻塞”，而不是“更快地完成计算”。
以上就是C#的async和await关键字是什么？如何使用？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439531.html
微信扫一扫 
支付宝扫一扫 
