为所有服务器端代码调用ConfigureAit的最佳实践

Question

当您有服务器端代码（即一些apicontroller)并且您的函数是异步的--因此它们返回task --在等待函数时调用configureawait(false)是否被认为是最佳做法？

我读到它的性能更好，因为它不需要将线程上下文切换回原来的线程上下文。但是，使用ASP.NET Web Api，如果请求是在一个线程上传入的，并且您等待某个函数并调用configureawait(false)，当您返回apicontroller函数的最终结果时，该函数可能会将您置于另一个线程上。

我在下面打了一个例子来说明我所说的：

public class CustomerController : ApiController
{
    public async Task<Customer> Get(int id)
    {
        // you are on a particular thread here
        var customer = await GetCustomerAsync(id).ConfigureAwait(false);
        
        // now you are on a different thread!  will that cause problems?
        return customer;
    }
}

Answer 1

更新：ASP.NET核心没有synchronizationContext。如果您在ASP.NET核心上，则是否使用configureaitait(false)并不重要。

对于ASP.NET“完整的”或“经典的”或其他什么，这个答案的其余部分仍然适用。

原始文章（用于非核心ASP.NET）：

ASP.NET团队的这段视频提供了关于在ASP.NET上使用async的最佳信息。

我读到它的性能更好，因为它不需要将线程上下文切换回原来的线程上下文。

UI应用程序也是如此，其中只有一个UI线程需要“同步”回。

在ASP.NET中，情况要复杂一些。当async方法恢复执行时，它会从ASP.NET线程池中抓取一个线程。如果使用configureawait(false)禁用上下文捕获，则线程只是继续直接执行该方法。如果不禁用上下文捕获，那么线程将重新进入请求上下文，然后继续执行该方法。

因此configureawait(false)不会在ASP.NET中为您保存线程跳转；它确实节省了重新输入请求上下文的时间，但这通常是非常快的。configureawait(false)在尝试对请求进行少量并行处理时可能很有用，但实际上TPL更适合大多数这种情况。

但是，对于ASP.NET Web Api，如果请求是在一个线程上传入的，并且您正在等待某个函数和调用ConfigureAit（false），当您返回ApiController函数的最终结果时，它可能会将您置于另一个线程上。

实际上，只需执行await就可以做到这一点。一旦async方法命中await,该方法将被阻塞,但线程将返回线程池。当方法准备好继续时，将从线程池中提取任何线程并用于恢复该方法。

configureawait在ASP.NET中的唯一区别是在恢复方法时该线程是否进入请求上下文。

我在关于synchronizationcontext的MSDN文章和async介绍博文中有更多的背景信息。