异步和等待-控制台、Windows和ASP.NET的区别
我一直在对自己进行异步/等待使用方面的教育，我想我理解了这个概念。然而，大多数Channel 9教程、MSDN文章和堆栈溢出答案都是关于异步/等待使用基于GUI的应用程序(Windows窗体应用程序)来演示异步/等待的强大功能。
但是，我注意到异步/等待在基于UI线程的应用程序中的使用与普通的基于ThreadPool线程的应用程序(例如ASP.NET网络应用程序、控制台应用程序等)之间的根本区别。
因为在基于UI线程的应用程序中，UI线程总是可用的(除非进程显式停止或被Windows停止)，所以负责在任何异步方法中“等待”之后执行代码的ThreadPool线程将保证找到UI线程来回发结果(如果有的话)。
但是，在控制台应用程序或ASP.NET Web应用程序中，主线程(在控制台应用程序中)或HTTP (在ASP.NET web应用程序中)必须等待(在某个时候)直到所有异步操作完成。因此，如果没有更多的工作要做，那么在异步方法调用之后应该有.Wait()和.Result调用。
这种理解是正确的吗？我并不怀疑异步用于I/O绑定或网络绑定操作的好处(我理解它将如何提高应用程序的可伸缩性)。
回答 1
Stack Overflow用户
发布于 2013-12-24 19:16:13
因为在基于UI线程的应用程序中，UI线程总是可用的(除非进程显式停止或被Windows停止)，所以负责在任何异步方法中“等待”之后执行代码的ThreadPool线程将保证找到UI线程来回发结果(如果有的话)。
这有点混乱。根本没有迹象表明需要一个ThreadPool线程。
需要由awaitable实现来决定在何处运行该延续，但通常使用当前的同步上下文来确定在何处运行它：
- 在控制台应用程序中，不存在同步上下文，因此使用线程池线程来继续。
- 在Windows窗体应用程序中，当您在UI线程上运行时，同步上下文将在UI线程上执行代码.因此继续在那里执行(除非使用
ConfigureAwait等.) - 在ASP.NET应用程序中，有一个特定于ASP.NET本身的同步上下文。
有关更多详细信息，请参阅Stephen Cleary's MSDN article。
关于必须在Wait或Result中调用ASP.NET或控制台应用程序的问题，现在还不清楚你的意思是什么。在这两种情况下，它都可能是必需的，但同样可能不是。这取决于你到底在做什么。不要忘记，即使是控制台应用程序也可以启动自己的线程并执行其他各种操作--例如，您可以在控制台应用程序中编写HTTP服务器.
https://stackoverflow.com/questions/20765723
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号