是否应该等待嵌套的可等待操作？

Question

我一直在关注this question，并且我理解Peter Duniho 的流行（尽管尚未接受）答案背后的原因。具体来说，我知道 not 等待后续长时间运行的操作会阻塞 UI 线程：

第二个例子在异步操作期间没有产生。相反，通过获取 content.Result 属性的值，可以强制当前线程等待异步操作完成。

为了我自己的利益，我什至已经证实了这一点，就像这样：

private async void button1_Click(object sender, EventArgs e)
{
    var value1 = await Task.Run(async () =>
        {
            await Task.Delay(5000);
            return "Hello";
        });

    //NOTE: this one is not awaited...
    var value2 = Task.Run(async () =>
        {
            await Task.Delay(5000);
            return value1.Substring(0, 3);
        });

    System.Diagnostics.Debug.Print(value2.Result); //thus, UI freezes here after 5000 ms.
}

但现在我想知道：您是否需要 await 嵌套在最外层可等待操作中的所有“等待”操作？例如，我可以这样做：

private async void button1_Click(object sender, EventArgs e)
{
    var value0 = await Task.Run(() =>
        {
            var value1 = new Func<Task<string>>(async () =>
            {
                await Task.Delay(5000);
                return "hello";
            }).Invoke();

            var value2 = new Func<string, Task<string>>(async (string x) =>
                {
                    await Task.Delay(5000);
                    return x.Substring(0, 3);
                }).Invoke(value1.Result);

            return value2;
        });

    System.Diagnostics.Debug.Print(value0); 
}

或者我可以这样做：

private async void button1_Click(object sender, EventArgs e)
{
    //This time the lambda is async...
    var value0 = await Task.Run(async () =>
        {
            //we're awaiting here now...
            var value1 = await new Func<Task<string>>(async () =>
            {
                await Task.Delay(5000);
                return "hello";
            }).Invoke();

            //and we're awaiting here now, too...
            var value2 = await new Func<string, Task<string>>(async (string x) =>
                {
                    await Task.Delay(5000);
                    return x.Substring(0, 3);
                }).Invoke(value1);

            return value2;
        });

    System.Diagnostics.Debug.Print(value0); 
}

而且它们都不会冻结 UI。哪一个更可取？

Answer 1

最后一个更可取（虽然很乱）

在 TAP（基于任务的异步模式）中，任务（和其他可等待对象）表示异步操作。您基本上有 3 个选项来处理这些任务：

• 同步等待 (DoAsync().Result, DoAsync().Wait()) - 阻塞调用线程直到任务完成。使您的应用程序更浪费、更难扩展、响应更慢并且容易出现死锁。
• 异步等待 (await DoAsync()) - 不阻塞调用线程。它基本上将await 之后的工作注册为等待任务完成后要执行的延续。
• 根本不等待 (DoAsync()) - 不阻塞调用线程，也不等待操作完成。您不知道在处理 DoAsync 时引发的任何异常

具体来说，我知道不等待后续长时间运行的操作会阻塞 UI 线程

所以，不完全是。如果您根本不等待，什么都不会阻塞，但您无法知道操作何时或是否成功完成。但是，如果您同步等待，则会阻塞调用线程，并且如果您阻塞 UI 线程，则可能会出现死锁。

结论：只要有可能，您就应该 await 您的可等待对象（例如，它不在 Main 中）。这包括“嵌套的async-await 操作”。

关于您的具体示例：Task.Run 用于将 CPU 绑定的工作卸载到 ThreadPool 线程，这似乎不是您想要模仿的。如果我们使用 Task.Delay 来表示真正的异步操作（通常是 I/O 绑定的），我们可以在没有 Task.Run 的情况下使用“嵌套 async-await”：

private async void button1_Click(object sender, EventArgs e)
{
    var response = await SendAsync();
    Debug.WriteLine(response); 
}

async Task<Response> SendAsync()
{
    await SendRequestAsync(new Request());
    var response = await RecieveResponseAsync();
    return response;
}

async Task SendRequestAsync(Request request)
{
    await Task.Delay(1000); // actual I/O operation
}

async Task<Response> RecieveResponseAsync()
{
    await Task.Delay(1000); // actual I/O operation
    return null;
}

您可以使用匿名委托而不是方法，但是当您需要定义类型并自己调用它们时会很不方便。

如果您确实需要将该操作卸载到 ThreadPool 线程，只需添加 Task.Run：

private async void button1_Click(object sender, EventArgs e)
{
    var response = await Task.Run(() => SendAsync());
    Debug.WriteLine(response); 
}