在Console或Web应用中使用async/await据我所知，C#中的async/await函数会在调用之间将await段拆分成回调方法运行在每个等待的方法在单独的工作线程上返回后，在调用线程上。在等待期间，调用线程处于“空闲”状态。回调必须通过某种事件循环在调用线程上分派。此事件循环仅存在于GUI应用程序中，例如Windows窗体或WPF。释放此循环可确保UI在长时间操作期间保持对其他用户交互的响应。控制台应用程序和Web应用程序(ASP.NET)没有这样的事件循环，因此这种回调机制不起作用。但话又说回来，他们没有事件循环，因为他们不需要。用户在任何时候都不会尝试与正在运行的程序进行交互以期望立即获得反馈。所以不需要释放调用线程。操作使用多少线程并不重要，它只会在最后一位完成时返回。那么在控制台和Web应用程序中使用async和await有什么用，或者通常是任何类型的非交互式代码，例如Windows服务？它与简单的同步调用有何不同或更高效？我正在设计一个供GUI和非交互式（服务和Web）程序使用的API，并且很难理解它在非GUI环境中的行为方式。async-await的要点是，当您到达第一个异步点（即未完成任务的第一个等待点）时，调用线程总是被释放。在UI应用程序中，你有一个SynchronizationContext在等待UI线程后释放代码，因为与UI交互的代码必须由UI线程执行，否则你会得到异常。您可以使用ConfigureAwait(false)来控制它。在控制台应用程序（和服务等）中没有这样的需要，所以代码在一些ThreadPool线程上运行。调用线程（也可能是ThreadPool线程）被释放并且能够同时执行其他类型的工作，而不是同步阻塞。所以async-await提高了可伸缩性，因为它可以用相同数量的线程做更多的工作。i3arnon的回答（和往常一样）很好。那么在控制台和Web应用程序中使用async和await有什么用，或者通常是任何类型的非交互式代码，例如Windows服务？客户端异步的主要好处是响应能力；服务器端异步的主要好处是可扩展性。它与简单的同步调用有何不同或更高效？客户端响应性和服务器端可伸缩性是通过相同的机制实现的：释放调用线程。所以异步就是使用更少的线程。在服务器端，使用较少的线程可以让您的应用程序最大限度地利用现有的线程池。据我所知，C#中的async/await函数将await调用之间的段拆分为在每个等待的方法在单独的工作线程上返回后在调用线程上运行的回调方法。这就是我回答的原因。我不能放过这个。这种理解中每次提到“线程”，都是错误的。这部分是正确的：await将异步方法“拆分”为多个段。1）回调方法不在调用线程上运行。相反，await将捕获“上下文”并在该上下文中恢复该方法。特别是在ASP.NET应用程序和控制台应用程序中，上下文并不暗示特定的线程。我在介绍异步的博文中详细解释了await如何捕获上下文。2）异步API一般不会在工作线程上执行。async的全部意义在于释放线程，因此阻塞线程池线程是没有意义的。我在我关于“无线程”的博文中解释了异步I/O几乎是无线的。Async/await与多线程无关，引用MSDN：async和await关键字不会导致创建额外的线程。异步方法不需要多线程，因为异步方法不能在自己的线程上运行。Async/await允许您根据长时间运行的操作来构建代码（无论是CPU工作还是I/O工作）。所以这适用于任何类型的程序（GUI、web服务、控制台等）以上就是C#学习教程的全部内容：在控制台或web应用中使用async/await，如果对大家有用需要的话了解更多C#学习教程，希望大家多多关注～本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
