C#使用Task.WhenAll并行查询团队所有者时任务为何串行执行

架构老林

2026-11-1

问题根因定位

所有并行失效的核心原因全藏在你写的异步lambda里，没有任何一处真实使用了await让出执行流，具体拆解：

第一个阻塞点：调用httpClient.GetAsync(url)后没有await等待返回，反而直接访问这个Task的.Result属性，当前执行线程会被直接卡死直到这个HTTP请求完全返回，根本不会把执行权交回给任务调度器。
第二个阻塞点：后续ReadAsStringAsync()同样直接访问.Result，全程都是同步阻塞执行，没有任何异步流程该有的暂停、让出逻辑。
最关键的逻辑陷阱：LINQ的Select是同步枚举操作。因为你的async lambda内部全是同步阻塞逻辑、没有碰到任何一个await，整个lambda体在被Select枚举调用的时候就会同步执行完毕，才会进入下一个循环迭代。也就是说，你以为tasks里装的是待执行的并行任务，实际上这些任务在Select枚举的环节就已经串行跑完了，等走到Task.WhenAll的时候，拿到的全是已经执行完成的Task，自然完全没有并行效果，日志呈现的就是纯串行的执行顺序。这个问题编译器其实早就给出了CS1998警告：异步lambda内部没有任何await调用，会以同步方式运行。
附带的实现反模式：每次循环都新建一个HttpClient实例，哪怕并行生效了，也会因为频繁创建销毁套接字触发socket耗尽问题，同时因为没有连接复用拖慢整体请求速度。

修正后的实现逻辑

要让并行真的生效，需要满足两个核心要求：

把所有.Result的同步阻塞调用全部替换为await，让lambda在碰到第一个网络请求的await节点时就暂停执行，返回一个未完成的Task给任务列表，让调度器有机会交叉推进所有任务。
全局复用单例HttpClient，利用连接池复用减少TCP握手开销，避免socket泄漏。

修正后的代码参考：

// 全局静态复用HttpClient，避免反复创建实例的资源开销
private static readonly HttpClient _httpClient = new HttpClient();

private static async Task DispatchGetTeamOwnersAsync(JEnumerable<JToken> userTeams, GraphittiBox.Model.TokenObject token)
{
    // 统一设置鉴权头，不需要每次请求重复设置
    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(token.Token_type, token.Access_token);

    // 构建并行任务列表
    var tasks = userTeams.Select(async team =>
    {
        Team t = JsonConvert.DeserializeObject<Team>(team.ToString());
        Stopwatch clock = Stopwatch.StartNew();
        LogService.WriteLog("await: GetOwnersOfTeamAsync");

        var requestUrl = $"https://graph.microsoft.com/v1.0/groups/{t.Id}/owners?$select=mail,id,displayName";
        // 真实异步等待响应，不再阻塞线程
        using var response = await _httpClient.GetAsync(requestUrl);
        var responseContent = await response.Content.ReadAsStringAsync();

        JObject owners = JsonConvert.DeserializeObject<JObject>(responseContent);
        JsonOwnersCollection.Add(new OwnersAsyncList(t.Id, owners));

        clock.Stop();
        LogService.WriteLog($"Done ({clock.ElapsedMilliseconds} ms)");
    });

    // 等待所有并行任务执行完成
    await Task.WhenAll(tasks);
}

落地性能优化提醒

不要追求“所有请求并行发出去”的效果：微软Graph API本身有并发限流阈值，当用户的团队数到几百个时，一次性发起几百个请求会触发429限流，反而让整体耗时更长。可以用SemaphoreSlim做并发控制，把同时发起的请求数限制在10-20个的安全区间内。
修正后37个团队的总耗时，基本会落在单次请求耗时的2-3倍区间内（受本地连接池、网络往返时间影响），不会出现完全和单次请求等长的情况，但相比原来的纯串行模式，耗时压缩幅度会非常明显。

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