C#中Task.WhenAll与并行任务执行的技术疑问及代码差异对比

一、Task.WhenAll() vs 直接await多个任务的核心差异 #

这不是单纯的偏好选择，而是基于技术场景的取舍：

• 并行执行效率：如果先启动两个任务再用Task.WhenAll()，两个任务会并行执行；但如果是await aService.GetAContentAsync(); await bService.GetBContentAsync();的串行写法，第二个任务要等第一个完全结束才启动，性能差距明显。
• 异常处理逻辑：Task.WhenAll()会等待所有任务完成，若多个任务抛出异常，会把所有异常打包进AggregateException；而逐个await时，第一个抛出异常的任务会直接中断后续代码，无法捕获后续任务的异常。
• 代码适配场景：
  • 用Task.WhenAll()的场景：
    1. 需要多个异步任务并行执行以提升性能
    2. 必须等待所有任务完成后再继续后续逻辑
    3. 需要收集所有任务的执行结果或所有可能的异常
  • 用逐个await的场景：
    1. 任务之间存在依赖（第二个任务需要第一个的执行结果）
    2. 只需要等待第一个完成的任务（这类场景更适合Task.WhenAny()）
    3. 要求遇到第一个异常就终止后续流程

二、三段代码的差异与最优选择 #

第一段代码：通过Task.Result获取结果 #

var aTask = aService.GetAContentAsync(request.Language);
var bTask = bService.GetBContentAsync(request.Language);

await Task.WhenAll(aTask, bTask);

var aResponse = aTask.Result;
var bResponse = bTask.Result;

var response = new Content
{
   Title = aResponse,
   Details = bResponse
};

• 差异：在await WhenAll后任务已完成，此时调用Result不会阻塞线程，但这种写法不符合异步编程最佳实践——异步代码中应优先用await而非Result，后者在任务未完成时会阻塞线程，虽在此场景下安全，但可读性差、风格不规范。

第二段代码：再次await已完成的任务 #

var aTask = aService.GetAContentAsync(request.Language);
var bTask = bService.GetBContentAsync(request.Language);

await Task.WhenAll(aTask, bTask);

var aResponse = await aTask;
var bResponse = await bTask;

var response = new Content
{
   Title = aResponse,
   Details = bResponse
};

• 差异：await已完成的任务是合法操作，会直接返回结果且无性能损耗，但属于冗余代码——已经通过WhenAll确认任务完成，没必要重复await，代码啰嗦。

第三段代码：直接获取WhenAll返回的结果数组 #

var aTask = aService.GetAContentAsync(request.Language);
var bTask = bService.GetBContentAsync(request.Language);

var allTasks = await Task.WhenAll(aTask, bTask);

var aResponse = allTasks[0];
var bResponse = allTasks[1];

var response = new Content
{
   Title = aResponse,
   Details = bResponse
};

• 差异：这是最优实现——Task.WhenAll直接返回所有任务的结果数组，类型安全、代码简洁，完全符合异步编程的最佳实践，既无冗余也无不规范的写法。

总结 #

三段代码的功能完全一致，最终都能并行获取两个内容并组装结果，但第三段是最规范、可读性最好的写法。Task.WhenAll()是并行异步场景下的必要技术手段，和逐个await的核心差异体现在并行效率、异常处理逻辑上，需根据具体业务场景选择。

内容的提问来源于stack exchange，提问作者Avery Lam