译文: async/await SynchronizationContext 上下文问题

async / await 使异步代码更容易写，因为它隐藏了很多细节。 许多这些细节都捕获在 SynchronizationContext 中，这些可能会改变异步代码的行为完全由于你执行你的代码的环境（例如WPF，Winforms，控制台或ASP.NET）所控制。 若果尝试通过忽略 SynchronizationContext 产生的影响，您可能遇到死锁和竞争条件状况。

SynchronizationContext 控制任务连续的调度方式和位置，并且有许多不同的上下文可用。 如果你正在编写一个 WPF 应用程序，构建一个网站或使用 ASP.NET 的API，你应该知道你已经使用了一个特殊的 SynchronizationContext 。

SynchronizationContext in a console application

让我们来看看控制台应用程序中的一些代码：

public class ConsoleApplication
{
    public static void Main()
    {
        Console.WriteLine($"{DateTime.Now.ToString("T")} - Starting");
        var t1 = ExecuteAsync(() => Library.BlockingOperation());
        var t2 = ExecuteAsync(() => Library.BlockingOperation()));
        var t3 = ExecuteAsync(() => Library.BlockingOperation()));
 
        Task.WaitAll(t1, t2, t3);
        Console.WriteLine($"{DateTime.Now.ToString("T")} - Finished");
        Console.ReadKey();
    }
 
    private static async Task ExecuteAsync(Action action)
    {
        // Execute the continuation asynchronously
        await Task.Yield();  // The current thread returns immediately to the caller
                             // of this method and the rest of the code in this method
                             // will be executed asynchronously
 
        action();
 
        Console.WriteLine($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId}");
    }
}

其中 Library.BlockingOperation() 是一个第三方库，我们用它来阻塞正在使用的线程。 它可以是任何阻塞操作，但是为了测试的目的，您可以使用 Thread.Sleep(2) 来代替实现。

运行程序，输出结果为：

16:39:15 - Starting

16:39:17 - Completed task on thread 11

16:39:17 - Completed task on thread 10

16:39:17 - Completed task on thread 9

16:39:17 - Finished

在示例中，我们创建三个任务阻塞线程一段时间。 Task.Yield 强制一个方法是异步的，通过调度这个语句之后的所有内容（称为_continuation_）来执行，但立即将控制权返回给调用者（Task.Yield 是告知调度者"我已处理完成，可以将执行权让给其他的线程"，至于最终调用哪个线程，由调度者决定，可能下一个调度的线程还是自己本身）。 从输出中可以看出，由于 Task.Yield 所有的操作最终并行执行，总执行时间只有两秒。

SynchronizationContext in an ASP.NET application

假设我们想在 ASP.NET 应用程序中重用这个代码，我们将代码 Console.WriteLine 转换为 HttpConext.Response.Write 即可，我们可以看到页面上的输出：

public class HomeController : Controller
{
    public ActionResult Index()
    {
        HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Starting");
        var t1 = ExecuteAsync(() => Library.BlockingOperation()));
        var t2 = ExecuteAsync(() => Library.BlockingOperation()));
        var t3 = ExecuteAsync(() => Library.BlockingOperation()));
 
        Task.WaitAll(t1, t2, t3);
        HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Finished");
 
        return View();
    }
 
    private async Task ExecuteAsync(Action action)
    {
        await Task.Yield();
 
        action();
        HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId}");
    }
}

我们会发现，在浏览器中启动此页面后不会加载。 看来我们是引入了一个死锁。那么这里到底发生了什么呢？

死锁的原因是控制台应用程序调度异步操作与 ASP.NET 不同。 虽然控制台应用程序只是调度线程池上的任务，而 ASP.NET 确保同一 HTTP 请求的所有异步任务都按顺序执行。 由于 Task.Yield 将剩余的工作排队，并立即将控制权返回给调用者，因此我们在运行 Task.WaitAll 的时候有三个等待操作。 Task.WaitAll 是一个阻塞操作，类似的阻塞操作还有如 Task.Wait 或 Task.Result，因此阻止当前线程。

ASP.NET 是在线程池上调度它的任务，阻塞线程并不是导致死锁的原因。 但是由于是顺序执行，这导致不允许等待操作开始执行。 如果他们无法启动，他们将永远不能完成，被阻止的线程不能继续。

此调度机制由 SynchronizationContext 类控制。 每当我们等待任务时，在等待的操作完成后，在 await 语句（即继续）之后运行的所有内容将在当前 SynchronizationContext 上被调度。 上下文决定了如何、何时和在何处执行任务。 您可以使用静态 SynchronizationContext.Current 属性访问当前上下文，并且该属性的值在 await 语句之前和之后始终相同。

在控制台应用程序中，SynchronizationContext.Current 始终为空，这意味着连接可以由线程池中的任何空闲线程拾取，这是在第一个示例中能并行执行操作的原因。 但是在我们的 ASP.NET 控制器中有一个 AspNetSynchronizationContext，它确保前面提到的顺序处理。

要点一：

不要使用阻塞任务同步方法，如 Task.Result，Task.Wait，Task.WaitAll 或 Task.WaitAny。 控制台应用程序的 Main 方法目前是该规则唯一的例外（因为当它们获得完全异步时的行为会有所改变）。

解决方案

现在我们知道不应该使用 Task.WaitAll，让我们修复我们的控制器的 Index Action：

public async Task<ActionResult> Index()
{
    HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Starting 
");
    var t1 = ExecuteAsync(() => Library.BlockingOperation()));
    var t2 = ExecuteAsync(() => Library.BlockingOperation()));
    var t3 = ExecuteAsync(() => Library.BlockingOperation()));
 
    await Task.WhenAll(t1, t2, t3);
    HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Finished 
");
 
    return View();
}

我们将 Task.WaitAll（t1，t2，t3）更改为非阻塞等待 Task.WhenAll（t1，t2，t3），这也要求我们将方法的返回类型从 ActionResult 更改为 async 任务。

更改后我们看到页面上输出如下结果：

16:41:03 - Starting

16:41:05 - Completed task on thread 60

16:41:07 - Completed task on thread 50

16:41:09 - Completed task on thread 74

16:41:09 - Finished

 

这看起来更好，但我们有另一个问题。 页面现在需要六秒的加载，而不是我们在控制台应用程序中的两秒。 输出很好地显示 AspNetSynchronizationContext 确实调度其在线程池上的工作，因为我们可以看到执行任务的不同线程。 但是由于这种上下文的顺序性质，它们不会并行运行。 虽然我们解决了死锁，我们的复制粘贴代码仍然低于在控制台应用程序中使用的效率。

要点二：

永远不要假设异步代码是以并行方式执行的，除非你显式地将其设置为并行执行。 用 Task.Run 或 Task.Factory.StartNew 调度异步代码来使他们并行运行。

第二次尝试

我们使用新的的规则：

private async Task ExecuteAsync(Action action)
{
    await Task.Yield();
 
    action();
    HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId} 
");
}

to:

private async Task ExecuteAsync(Action action)
{
    await Task.Run(action);
    HttpContext.Response.Write($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId} 
");
}

Task.Run 在没有 SynchronizationContext 的情况下在线程池上调度给定的操作。 这意味着在任务内运行的所有内容都将 SynchronizationContext.Current 设置为 null。 结果是所有入队操作都可以由任何线程自由选取，并且它们不必遵循ASP.NET上下文指定的顺序执行顺序。 这也意味着任务能够并行执行。

注意 HttpContext 不是线程安全的，因此我们不应该在 Task.Run 中访问它，因为这可能在 html 输出上产生奇怪的结果。 但是由于上下文捕获，Response.Write 被确保发生在 AspNetSynchronizationContext（这是在 await 之前的当前上下文）中，确保对 HttpContext 的序列化访问。

这次的输出结果为：

16:42:27 - Starting

16:42:29 - Completed task on thread 9

16:42:29 - Completed task on thread 12

16:42:29 - Completed task on thread 14

16:42:29 - Finished

 

不仅仅如此

SynchronizationContext 可以做的不仅仅是调度任务。 AspNetSynchronizationContext 也确保正确的用户设置在当前正在执行的线程（记住，它是在整个线程池中安排工作），它使得  HttpContext.Current 可用。
在我们的代码中这些都是没有必要的，因为我们能够使用 Controller 的 HttpContext 属性。 如果我们想要提取我们超级有用的 ExecuteAsync 到一个帮助类，这变得很明显：

class AsyncHelper
{
    public static async Task ExecuteAsync(Action action)
    {
        await Task.Run(action);
        HttpContext.Current.Response.Write($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId} 
");
    }
}

我们刚刚将 HttpContext.Response 更改为静态可用的 HttpContext.Current.Response 。 这仍然可以工作，这得益于 AspNetSynchronizationContext，但如果你尝试在 Task.Run 中访问 HttpContext.Current ，你会得到一个 NullReferenceException，因为 HttpContext.Current 没有设置。

忘掉上下文

正如我们在前面的例子中看到的，上下文捕获可以非常方便。 但是在许多情况下，我们不需要为 "continuation" 恢复的上下文。 上下文捕获是有代价的，如果我们不需要它，最好避免这个附加的逻辑。 假设我们要切换到日志框架，而不是直接写入加载的网页。 我们重写我们的帮助：

class AsyncHelper
{
    public static async Task ExecuteAsync(Action action)
    {
        await Task.Run(action);
        Log.Info($"{DateTime.Now.ToString("T")} - Completed task on thread {Thread.CurrentThread.ManagedThreadId}");
    }
}

现在在 await 语句之后，AspNetSynchronizationContext 中没有我们需要的东西，因此在这里不恢复它是安全的。 在等待任务之后，可以使用 ConfigureAwait(false) 禁用上下文捕获。 这将告诉等待的任务调度其当前 SynchronizationContext 的延续。 因为我们使用 Task.Run，上下文是 null，因此连接被调度在线程池上（没有顺序执行约束）。

使用 ConfigureAwait(false) 时要记住的两个细节：

• 当使用 ConfigureAwait(false) 时，不能保证 "continuation" 将在不同的上下文中运行。 它只是告诉基础设施不恢复上下文，而不是主动切换到其他的东西（使用 Task.Run 如果你想摆脱上下文）。
• 禁用上下文捕获仅限于使用 ConfigureAwait(false) 的 await 语句。 在下一个 await（在同一方法中，在调用方法或被调用的方法）语句中，如果没有另外说明，上下文将被再次捕获和恢复。 所以你需要添加 ConfigureAwait(false) 到所有 await 语句，以防你不依赖上下文。

TL; DR;

由于异步代码的 SynchronizationContext，异步代码在不同环境中的表现可能不同。 但是，当遵循最佳做法时，我们可以将遇到问题的几率减少到最低限度。 因此，请确保您熟悉 async/await 最佳实践并坚持使用它们。

原文： Context Matters