c# - 关于 MVC 中异步/等待的矛盾建议

Question

我一直在开发一些将由 MVC 操作方法使用的库代码，因此我一直在阅读 Steven Cleary 的大量关于该主题的博客。

我浏览了他的“Don't Block on Async Code”博文，但对某些看似矛盾的部分感到困惑。

在“防止死锁”下，他说:

There are two best practices (both covered in my intro post) that avoid this situation:

1. In your “library” async methods, use ConfigureAwait(false) wherever possible.

2. Don’t block on Tasks; use async all the way down.

然后:

Using ConfigureAwait(false) to avoid deadlocks is a dangerous practice. You would have to use ConfigureAwait(false) for every await in the transitive closure of all methods called by the blocking code, including all third- and second-party code. Using ConfigureAwait(false) to avoid deadlock is at best just a hack).

鉴于这 2 个陈述，一个说 ConfigureAwait(false) 是库代码的最佳实践，另一个说它充其量是一种危险的 hack，实际正确的编写方法是什么在 MVC 中使用时不会死锁的库代码？

我读过关于 SO 的其他问题和答案，可能 被认为是这个的重复，但它们似乎都没有解决异步/等待专家之一给出的矛盾信息。

Answer 1

这些信息并不直接矛盾，除非你断章取义:

前者是编写库代码的一般建议；做这些事情是个好主意，以确保您的库无论调用它的同步上下文如何都表现良好。

后者明确指出如何使用 ConfigureAwait(false) 作为避免已知 死锁情况的手段是一种 hack。它在说，

I want to block here, but doing so would normally cause a deadlock, so I'll push the work to another thread (from the thread-pool) and hope everything works out okay.

如果遵循前面的建议不阻塞任务(一直使用异步)，那么这种死锁情况就不会发生。

死锁场景仅在特定同步上下文中运行代码时相关，这些同步上下文安排继续在启动任务的线程上执行，例如 ASP.NET 使用的同步上下文(请求在一个线程上处理)或由 Windows 桌面应用程序使用(所有 UI 事件的单个线程)。

在这些上下文中阻塞任务会导致单个线程阻塞，因此线程永远无法自由运行延续和方法死锁。