c# - 在 ASP.NET 的上下文中，为什么 Task.Run(...).Result 在调用异步方法时不会死锁？

Question

我用一个 Controller 和一个方法创建了一个简单的 WebApi 项目:

public static class DoIt
{
    public static async Task<string> GetStrAsync(Uri uri)
    {
        using (var client = new HttpClient())
        {
            var str = await client.GetStringAsync(uri);
            return str;
        }
    }
}

public class TaskRunResultController : ApiController
{
    public string Get()
    {
        var task = Task.Run(() =>
            DoIt.GetStrAsync(new Uri("http://google.com"))
        );
        var result = task.Result;

        return result;
    }
}

我对异步/等待和任务有很好的理解；几乎虔诚地追随斯蒂芬克利里。 .Result 的存在让我很焦虑，我希望这会陷入僵局。我知道 Task.Run(...) 很浪费，导致线程在等待异步 DoIt() 完成时被占用。

问题是这不是死锁，它让我心悸。

我看到一些答案，例如 https://stackoverflow.com/a/32607091/1801382 ，并且我还观察到 SynchronizationContext.Current 在执行 lambda 时为 null。但是，我也有类似的问题问为什么上面的代码确实死锁，我已经看到死锁发生在使用ConfigureAwait(false)的情况下(不捕获context) 与 .Result 结合使用。

什么给了？

Answer 1

Result 本身不会导致死锁。死锁是指代码的两部分都在等待对方。 Result 只是一次等待，因此它可能是死锁的一部分，但不一定总是导致死锁。

在standard example ，Result 等待任务完成同时保留上下文，但任务无法完成，因为它正在等待上下文空闲 em>。所以出现了僵局 - 他们在等待对方。

ASP.NET Core does not have a context at all ，所以 Result 不会在那里死锁。 (由于其他原因，这仍然不是一个好主意，但它不会死锁)。

The problem is this is not deadlocking, and it's giving me heart palpitations.

这是因为 Task.Run 任务不需要上下文来完成。所以调用 Task.Run(...).Result 是安全的。 Result 正在等待任务完成，它会保留上下文(防止请求的任何其他部分在该上下文中执行)，但这没关系，因为 Task.Run 任务根本不需要上下文。

Task.Run 通常在 ASP.NET 上仍然不是一个好主意(出于其他原因)，但这是一种非常有效的技术，有时会有用。它永远不会死锁，因为 Task.Run 任务不需要上下文。

However, there are similar questions to mine asking why the above code does deadlock,

类似但不准确。仔细查看这些问题中的每个代码语句，并问问自己它运行在什么上下文中。

and I've seen deadlocks occur in cases where ConfigureAwait(false) is used (not capturing the context) in conjunction with .Result.

Result/context 死锁是一种非常常见的死锁——可能是最常见的死锁。但这并不是唯一的死锁场景。

Here's an example如果您在 async 代码(没有 上下文)中阻塞，可能会出现更困难的死锁。不过，这种情况要少见得多。