在许多微小的可等待方法上使用 WhenAll() 真的更有效吗？

Question

给定一个外部 API 方法签名，如下所示：

Task<int> ISomething.GetValueAsync(int x)

我经常看到如下代码：

public async Task Go(ISomething i)
{
    int a = await i.GetValueAsync(1);
    int b = await i.GetValueAsync(2);
    int c = await i.GetValueAsync(3);
    int d = await i.GetValueAsync(4);
    
    Console.WriteLine($"{a} - {b} - {c} - {d}");
}

在代码审查中，有时会建议这是低效的，应该重写：

public async Task Go(ISomething i)
{
    Task<int> ta = i.GetValueAsync(1);
    Task<int> tb = i.GetValueAsync(2);
    Task<int> tc = i.GetValueAsync(3);
    Task<int> td = i.GetValueAsync(4);
    
    await Task.WhenAll(ta,tb,tc,td);
    int a = ta.Result, b= tb.Result, c=tc.Result, d = td.Result;
    Console.WriteLine($"{a} - {b} - {c} - {d}");
}

我可以看到允许并行化背后的逻辑，但实际上这值得吗？ 它可能会给调度程序增加一些开销，如果方法本身非常轻量级，那么线程并行化似乎比节省的时间成本更高。 此外，在运行许多应用程序的繁忙服务器上，似乎不太可能有大量内核闲置。

我不知道这是否始终是一个值得遵循的好模式，或者它是否是根据具体情况进行的优化？ Microsoft（或其他任何人）是否提供良好的最佳实践建议？ 我们是否应该理所当然地始终以这种方式编写基于Task的代码？

Answer 1

如果方法本身是非常轻量级的，那么线程并行化似乎比节省的时间成本更高。

这肯定是并行代码（并发的并行形式）的问题，但这是异步并发。 据推测， GetValueAsync是一个真正的异步方法，它通常暗示 I/O 操作。 I/O 操作往往会使许多本地考虑相形见绌。 （旁注： WhenAll方法实际上导致更少的线程切换和更少的调度开销，但它确实会略微增加memory开销）。

所以，在一般情况下，这是一场胜利。 但是，这确实假定上述陈述是正确的（即， GetValueAsync执行 I/O）。

然而，相反，我看到这有时被用作数据访问层不足的创可贴。 如果您使用四个查询访问 SQL 数据库，那么最好的解决方案通常是将该数据访问合并到一个查询中，而不是同时对同一个 SQL 数据库进行四个调用。

Answer 2

首先， await 实际上做了什么？

public async Task M() {
    await Task.Yield();
}

如果可等待的 object 已经完成，则立即继续执行。 否则，回调委托将添加到可等待的 object。当任务结果可用时，将立即调用此回调。

那么Task.WhenAll是如何工作的呢？ 当前的实现为每个未完成的任务添加了一个回调。 该回调将自动递减计数器。 当计数器达到零时，结果将可用。

没有安排新的 I/O，也没有向线程池添加延续。 只是在每个任务处理的末尾添加了一个小计数器。 您的继续将在执行最后一个任务的任何线程上恢复。

如果您正在测量性能问题。 我不会担心Task.WhenAll的开销。