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

Question

我用一个控制器和一个方法创建了一个简单的 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;
    }
}

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

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

我看到了一些答案，例如，并且我还观察到在执行 lambda 时 SynchronizationContext.Current 为空。但是，我也有类似的问题问为什么上面的代码会死锁，我已经看到在使用 ConfigureAwait(false) 的情况下会发生死锁（不捕获上下文）结合 .Result.

什么给了？

Answer 1

我将以相反的方式给你一个简短的答案：如何产生死锁：

让我们从一个 Click 处理程序开始，该处理程序正在执行同步并将一些异步调用卸载到单独的任务，然后等待结果

private void MenuItem_Click(object sender, RoutedEventArgs e)
{
    var t = Task.Run(() => DeadlockProducer(sender as MenuItem));
    var result = t.Result;
}

private async Task<int> DeadlockProducer(MenuItem sender)
{
    await Task.Delay(1);
    Dispatcher.Invoke(() => sender.Header = "Life sucks");
    return 0;
}

异步方法在做另一件坏事：它试图同步带来一些 UI 变化，但 UI 线程仍在等待任务结果...

所以基本上，Task.Run 已经过时了，可以用于很多格式良好的异步代码，但是有办法打破它，所以它不是一个可靠的解决方案。

此示例代码是在 WPF 上下文中编写的，但我想 ASP.Net 可能会被滥用以产生类似的行为。

Answer 2

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

在 standard example 中，Result 等待任务完成 同时保持上下文 ，但任务无法完成，因为它是等待上下文空闲。所以有一个僵局 - 他们在等待对方。

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 代码（没有上下文）。不过，这种情况要少见得多。

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

In the context of ASP.NET, why doesn't Task.Run(...).Result deadlock when calling an async method?

c#

asp.net

asynchronous

task

synchronizationcontext