.NET Core 3.1中async/await在Select内的并行性能异常疑问

这个问题的核心不是Select的写法，而是你在Wait方法里使用了阻塞线程的操作，触发了.NET线程池的线程注入限制，导致后续任务无法立即并行执行。

为什么会出现“分批完成”的现象？ #

.NET的线程池会自动管理工作线程的数量，默认有两个关键机制：

• 线程池有一个最小工作线程数（在.NET Core中，默认值等于CPU核心数，比如4核CPU就是4个）
• 当排队任务数超过最小线程数时，线程池不会立刻创建新线程，而是每隔大约1秒才新增一个线程——这是为了避免短时间内创建过多线程，导致系统上下文切换开销飙升。

你的Wait方法里的代码是问题关键：

await Task.Run(() => { Thread.Sleep(5000); });

Thread.Sleep(5000)是阻塞线程池线程的操作，每个任务会占用一个线程池线程长达5秒。当你启动20个这样的任务时：

1. 前N个任务（N=CPU核心数）会立刻占用所有最小工作线程
2. 剩下的任务进入线程池等待队列
3. 线程池每秒新增一个线程处理排队任务，所以后续任务的Thread.Sleep会分批启动，最终导致总耗时远超预期的5秒。

你看到的“第9至13个任务每秒才完成一个”，就是线程池每秒新增线程处理任务的直接表现。

为什么“During Before”会同时输出？ #

因为Select(async l => ...)会立刻枚举所有20个元素并调用Wait方法：

• Wait方法开头的Console.WriteLine会立刻执行，所以所有“During Before”日志几乎同时输出
• 之后才走到await Task.Run(...)，任务才进入线程池的等待/执行阶段。

解决方案 #

方案1：用非阻塞延迟替代阻塞睡眠（推荐） #

如果只是模拟延迟场景，把Thread.Sleep换成Task.Delay——它是非阻塞的，不会占用线程池线程，所有任务可以真正并行执行：

async static Task<string> Wait(int index)
{
    Console.WriteLine(index + " - During Before - " + DateTime.Now.ToLongTimeString());
    await Task.Delay(5000); // 替换Thread.Sleep
    Console.WriteLine(index + " - During After - " + DateTime.Now.ToLongTimeString());
    return "ok";
}

修改后，所有20个任务会在5秒后同时完成，总耗时符合你的预期。

方案2：调整线程池最小工作线程数（仅适用于必须用阻塞操作的场景） #

如果你确实需要执行阻塞操作（比如调用同步IO或CPU密集型代码），可以通过ThreadPool.SetMinThreads提前设置足够多的最小工作线程，避免任务排队：

async static Task Main(string[] args)
{
    // 设置最小工作线程数为20（大于任务数量）
    ThreadPool.SetMinThreads(20, 20);
    Console.WriteLine("Before - " + DateTime.Now.ToLongTimeString());
    var list = await (Task.WhenAll((await GetList()).Select(async l => new { Value = l, Text = await Wait(l) })));
    Console.WriteLine("After - " + DateTime.Now.ToLongTimeString());
    Console.WriteLine("Count - " + list.Count());
    Console.ReadLine();
}

注意：这种方法要谨慎使用，过多的线程会增加系统上下文切换开销，反而降低整体性能。

验证修改效果 #

使用方案1修改代码后，运行日志会显示所有“During After”在5秒后同时输出，总耗时约5秒，完全符合预期。

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