Async-Await 在预期出现死锁的地方没有死锁

Question

众所周知，异步方法上的同步等待会导致死锁 （例如，参见Don't Block on Async Code）

我在 Windows 窗体应用程序中单击按钮的事件处理程序中有以下代码（即调用代码时安装了 UI SynchronizationContext）。

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, new Uri("http://www.google.com"));
Task<HttpResponseMessage> t = client.SendAsync(request);
t.Wait();
var response = t.Result;

我完全预料到代码会在单击按钮时死锁。但是，我实际看到的是同步等待——对话框有一段时间没有响应，然后像往常一样接受事件。 当我尝试同步等待 client 异步方法时，我总是看到死锁。但是，同步等待 library 异步方法（如 SendAsync 或 ReadAsByteArrayAsync）似乎不会死锁。有人可以解释这种行为吗？

.NET 库中异步方法的实现是否在内部使用 await 语句，因此必须将延续编组回原始 SynchronizationContext？

注意： 如果我定义一个客户端方法，说

public async Task<byte[]> wrapperMethod()
{
    var client = new HttpClient();
    var request = new HttpRequestMessage(HttpMethod.Get, new Uri("http://www.google.com"));
    var response = await client.SendAsync(request);
    return await response.Content.ReadAsByteArrayAsync();
}

然后在按钮单击处理程序中说byte[] byteArray = wrapperMethod().Result;，我确实遇到了死锁。

Answer 1

.NET 库中异步方法的实现是否在内部使用 await 语句？

一般来说，不会。我还没有在 .NET 框架中看到一个在内部使用 async-await 的实现。它确实使用了任务和延续，但没有使用 async 和 await 关键字带来的编译器魔法。

使用 async-await 很简单，因为代码看起来是同步的，但实际上是异步运行的。但这种简单性在性能上的代价是非常小。

对于大多数消费者来说，这个价格是值得付出的，但框架本身会尽可能地提高性能。

但是，同步等待库异步方法（如 SendAsync 或 ReadAsByteArrayAsync）似乎不会死锁。

死锁是 await 的默认行为的结果。当您等待未完成的任务时，SynchronizationContext 被捕获，当它完成时，继续在该 SynchronizationContext（如果存在）上恢复。当没有async、await、捕获SynchronizationContext等时，这种死锁是不会发生的。

HttpClient.SendAsync 专门使用TaskCompletionSource 来返回任务，而不将方法标记为异步。你可以在github上的实现中看到here。

为 async-await 添加到现有类的大多数任务返回方法只是使用现有的异步 API（即BeginXXX/EndXXX）构建任务。例如这是TcpClient.ConnectAsync：

public Task ConnectAsync(IPAddress address, int port)
{
    return Task.Factory.FromAsync(BeginConnect, EndConnect, address, port, null);
}

当您确实使用 async-await 时，虽然您在不需要捕获 SynchronizationContext 时使用 ConfigureAwait(false) 避免了死锁。建议库应始终使用它，除非需要上下文（例如 UI 库）。

Answer 2

阻塞大多数开箱即用的Task-returning .NET 调用不会导致死锁，因为它们不会在内部触及SynchronizationContext 而@987654325除非绝对必要，否则会启动 @（两个原因：性能和避免死锁）。

这意味着即使标准 .NET 调用确实在幕后使用 async/await（i3arnon 说他们没有 - 我不会争论，因为我根本不知道） ，毫无疑问，他们会使用ConfigureAwait(false)，除非绝对需要捕获上下文。

但这就是 .NET 框架。至于您自己的代码，如果您在客户端调用wrapperMethod().Wait()（或Result），您将观察到死锁（前提是您使用非空SynchronizationContext.Current 运行 - 如果您使用的是 Windows 窗体，这肯定是这种情况）。为什么？因为您在不与 UI 交互的async 方法内的等待对象上使用ConfigureAwait(false) 不 炫耀async/await 最佳实践，从而导致状态机生成不必要地执行的延续原SynchronizationContext。