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

当你有服务器端代码（即一些ApiController）并且你的函数是异步的 - 所以它们返回Task<SomeObject>- 每当您等待调用的函数时，这是否被认为是最佳实践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;
    }
}

Update: ASP.NET Core 没有SynchronizationContext。如果您使用 ASP.NET Core，则是否使用并不重要ConfigureAwait(false) or not.

对于 ASP.NET“完整”或“经典”或其他任何内容，此答案的其余部分仍然适用。

原始帖子（针对非核心 ASP.NET）：

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

我读到它的性能更高，因为它不必将线程上下文切换回原始线程上下文。

对于 UI 应用程序来说确实如此，其中只有一个您必须“同步”回的 UI 线程。

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

So ConfigureAwait(false)不会为您节省 ASP.NET 中的线程跳转；它确实节省了您重新输入请求上下文的时间，但这通常非常快。ConfigureAwait(false) could如果您尝试对请求进行少量并行处理，那么 TPL 会很有用，但实际上 TPL 更适合大多数这些场景。

然而，对于 ASP.NET Web Api，如果您的请求在一个线程上传入，并且您等待某个函数并调用ConfigureAwait(false)，那么当您返回 ApiController 函数的最终结果时，这可能会将您置于不同的线程上。

其实，只是做一个await可以做到这一点。一旦你的async方法命中await, the method被阻止，但thread返回到线程池。当该方法准备好继续时，将从线程池中抢夺任何线程并用于恢复该方法。

唯一的区别ConfigureAwaitASP.NET 中的关键在于线程在恢复方法时是否进入请求上下文。

我有更多背景信息MSDN 文章关于SynchronizationContext and my async介绍性博客文章.