应该不推荐Task.Wait吗？

Question

我了解了从池线程中调用Task.Wait可能导致线程饥饿死锁的艰难方法。

根据这篇MSDN文章 ，在“僵局”一章中，我们应遵守以下两个规则：

• 不要创建任何其同步方法等待异步函数的类，因为可以从池中的线程调用该类。
• 如果此类阻塞了等待异步功能的类，请不要在异步功能内使用任何类。

似乎唯一可以合法使用Task的地方。等待是Main函数-在这里我有点夸张，但是您明白了。

为什么Task.Wait仍然是.NET框架的一部分，看到它有多危险？

Answer 1

为什么Task.Wait仍然是.NET框架的一部分，看到它有多危险？

因为您希望能够同步阻塞Task 。 很少，但您仍然这样做。 如您所说， Main可能是发生这种情况的最受欢迎（最好是唯一）的地方。 那，以及Microsoft因其向后兼容而臭名昭著的事实，因此，一旦引入该功能，就不太可能被BCL弃用或消失。 Task.WaitAll 。

当人们没有正确阅读文档并且不了解调用这种方法的含义并最终滥用该方法时，IMO就会出现真正的问题 。 如果您仔细使用它，它的效果很好。

---

另一件事是，您不能总是始终保持异步状态 。 不幸的是，很多时候您都有通过签名同步的代码，这些代码无法更改，需要调用异步方法调用。 是的，这很危险，所有人都不要使用，它被认为是带有异步代码的反模式 ，我自己已经回答了至少十几个关于SO的问题，人们最终陷入僵局，不知道为什么，但是TPL作者仍然需要使这些类型的呼叫成为可能。