当您可以直接返回任务＜T＞时，为什么要使用异步和返回等待？

Question

是否存在这样的编写方法：

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

而不是这个：

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

会有意义吗？

当您可以直接返回< code >任务时，为什么要使用< code>return await构造

我在很多地方看到带有返回wait的代码，我想我可能错过了一些东西。但据我了解，在这种情况下不使用async/wait关键字并直接返回任务在功能上是等效的。为什么要增加额外的wait层的额外开销？

Answer 1

您想这样做的唯一原因是如果在早期代码中还有其他wait，或者您在返回结果之前以某种方式操作结果。可能发生这种情况的另一种方式是通过改变异常处理方式的try/catch。如果您没有做任何这些，那么您是对的，没有理由增加使方法async的开销。

Answer 2

如果您不需要异步（即，您可以直接返回任务），则不要使用异步。

在某些情况下，return-await非常有用，例如，如果您有两个异步操作要执行：

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

有关异步性能的更多信息，请参阅Stephen Toub关于该主题的MSDN文章和视频。

更新:我已经写了一篇博文，内容更加详细。

Answer 3

当在普通方法中返回和async方法中返回wait时，有一种偷偷摸摸的情况：当与使用的组合时（或者，更一般地，try块中的任何返回wait）。

考虑方法的这两个版本：

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

只要< code > DoAnotherThingAsync()方法返回，第一个方法就会< code>Dispose()该< code>Foo对象，这很可能在它实际完成之前很久。这意味着第一个版本可能有问题(因为< code>Foo被处理得太快了)，而第二个版本会工作得很好。