应该废弃 Task.Wait 吗？

Question

5

我曾经吃过亏，从池线程调用Task.Wait可能会导致线程饥饿死锁。根据这篇MSDN文章的“死锁”章节，我们应该遵守以下两个规则：

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

似乎Task.Wait唯一合法的使用场景就是Main函数——我有点夸张了，但你明白我的意思。既然Task.Wait如此危险，为什么它仍然是.NET框架的一部分呢？

- ZunTzu

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Yuval Itzchakov · Accepted Answer

因为您想要能够同步阻塞Task。虽然很少，但您仍然需要。正如您所说，Main可能是最受欢迎（也最好是唯一）使用它的地方。此外，微软以其向后兼容性而著称，因此一旦引入了这个功能，它就不太可能被弃用或从BCL中消失。对于Task.WaitAll也是如此。

在我看来，真正的问题是当人们没有正确阅读文档并不理解调用此类方法的影响时，他们最终会误用它。如果您小心使用，它可以很好地完成工作。

另一件事是你不能总是完全使用异步。不幸的是，很多时候你有同步代码，其签名无法更改，需要调用异步方法。是的，这是危险的，也是所有人都反对的反模式的异步代码，我自己在SO上回答了至少十几个问题，其中人们最终会死锁并且不知道为什么，但TPL作者仍然需要使这些类型的调用成为可能。