ASP.NET MVC 中异步编程的最佳实践是什么？

Question

根据this 文章，ASP.NET 要求在控制器中使用相同的SynchronizationContext 进行异步操作，否则会阻塞正在运行的线程。作为结论，作者提到我们应该使用这两种方法作为防止线程死锁的最佳实践：

1. 在您的“库”异步方法中，尽可能使用 ConfigureAwait(false)。

2. 不要阻塞任务；一直使用异步。

   注意：最好同时应用这两种最佳做法。任何一个都会阻止 死锁，但必须同时应用这两种方法以实现最佳性能和响应能力。

但是是什么目的导致微软使用相同的SynchronizationContext？可能正在使用 ConfigureAwait(false)，它禁用相同的同步上下文限制，可能会导致例如不可预测的行为或性能问题。因此，尽可能使用ConfigureAwait(false) 真的是一种好习惯吗？

Answer 1

ASP.NET 要求使用相同的 SynchronizationContext 控制器中的异步操作，否则它会阻塞 正在运行的线程。

我不太确定那句话是什么意思。 ASP.NET 不需要“相同”的同步上下文。为了让你进入你的HttpContext，你需要SynchronizationContext。

但是是什么目的导致微软使用相同的SynchronizationContext？

我建议您阅读 It's All About SynchronizationContext 以了解有关同步上下文的更大图景。基本上，它是一种允许您在特定线程上发布延续的机制。例如，它可用于将工作编组回 UI 应用程序内的 UI 消息循环线程。

可能正在使用 ConfigureAwait(false)，它会禁用相同的 同步上下文限制，可能导致例如不可预测的行为或 性能问题

相反。将工作编组回同步上下文确实有（非常少的）开销，因为需要将请求（使用抽象 SynchronizationContext.Post）发布回所需的线程和上下文。通过使用ConfigureAwait(false)，您可以节省该时间，并且只需在分配的线程上继续执行。

因此，使用 ConfigureAwait(false) 真的是一个好习惯吗？ 哪里有可能？

这样做的主要原因是避免死锁。当有人调用Task.Result 或Task.Wait 而不是使用await 进行异步等待时，您会遇到经典的死锁场景，同步上下文试图将延续发布回线程，但它当前被阻止，因为Result 和Wait 正在阻止呼叫。另一个原因是您获得的性能开销较小。

编辑：

微软为什么不把这个方法封装在Task类里面呢？ 看起来 ConfigureAwait(false) 只有优点。是 有什么缺点吗？

让我们想象一下以下场景：您执行一个返回Task 并使用await 等待的方法，然后立即更新一些UI 元素。现在，什么对你来说更自然？您希望隐式返回到之前的相同“环境”（UI 线程），还是希望您必须明确指定要返回到相同的环境？

我认为前者对用户来说“感觉”更自然。

例子：

public Task FetchAndReturnAsync(string url)
{
    var httpClient = new HttpClient();
    return httpClient.GetAsync(url);
}

你这样称呼它：

var awesomeUiResult = await FetchAndReturnAsync("http://www.google.com");
textBox.Text = awesomeUiResult;

你认为应该发生什么？是在等待之后更新文本框更自然，还是因为您现在不在原始上下文中而失败？

Answer 2

ASP.NET 要求在控制器中对异步操作使用相同的 SynchronizationContext，否则会阻塞正在运行的线程。

有点，但不完全是。 ASP.NET 为每个传入请求创建一个SynchronizationContext，并且此上下文根本不绑定到特定线程。但是，一次只有一个线程可以进入上下文，所以如果第二个线程尝试进入上下文，而另一个线程已经在其中，那么它将阻塞该线程。

什么目的导致微软使用相同的 SynchronizationContext？

用于 ASP.NET 的 SynchronizationContext 管理每个请求的数据，例如 HttpContext.Current、文化和用户身份。

尽可能使用 ConfigureAwait(false) 真的很好吗？

一般来说，是的，尤其是对于通用库。在 ASP.NET 上，ConfigureAwait(false) 不会给您带来太多收益 - 在某些情况下，性能会略有提升。它可以用于避免我在文章中提到的死锁，但最好（尤其是在 ASP.NET 上）一直使用async。