为何CPU密集型并行Task可使用Task.Wait，而异步Task需避免？

首先明确《Concurrency in C# Cookbook》“4.4 动态并行”章节的完整原文翻译：

并行任务可使用Task.Wait、Task.Result、Task.WaitAll及Task.WaitAny等阻塞成员；与之相反，异步任务应避免使用阻塞成员，优先选择await、Task.WhenAll和Task.WhenAny。并行任务通常还会使用AttachedToParent来创建任务间的父子关系。并行任务应通过Task.Run或Task.Factory.StartNew创建。

要搞清楚这个问题，核心是区分CPU密集型并行任务和IO密集型异步任务的设计目标，以及调用线程的角色差异：

1. 并行任务（CPU密集）的核心诉求 #

并行任务的目的是榨取多核CPU算力，把大型计算拆分成多个子任务分散到不同线程执行，缩短总计算时间。这种场景下：

• 如果调用线程本身就是“等待型线程”（比如控制台程序的主线程，它的唯一职责就是等所有计算完成后退出），阻塞它完全没问题——因为计算任务已经占满了其他CPU核心，这个线程本来就没别的工作可做，阻塞它反而能避免不必要的上下文切换开销。
• 并行任务的设计通常是“同步协调”的：发起任务的线程需要等待所有计算完成，汇总结果后继续执行，这种时候用Wait/WaitAll是符合逻辑的设计选择。

2. 异步任务（IO密集）的核心诉求 #

异步任务的目的是释放线程资源，让线程可以去处理其他请求（比如Web服务器的请求线程、UI线程）。这种场景下：

• 如果用Wait阻塞线程，就彻底违背了异步的初衷——线程被死死占着什么也做不了，造成资源浪费（比如Web服务器能处理的请求数直接下降，UI界面假死）。
• 所以异步场景必须用await，让线程在IO等待期间去处理其他任务，IO完成后再回来继续执行。

3. 你的示例对比 #

来看你给出的两个方法：

Test() 用Task.Wait #

private static void Test()
{
    Task.Run(() =>
    {
        for (int i = 0; i < 100; i++)
        {
            // CPU密集操作
        }
    }).Wait();
}

• 如果是在控制台主线程调用：完全合理，主线程本来就要等计算结束，阻塞它没毛病，甚至比await少了一点上下文切换的开销。
• 如果是在UI线程/Web请求线程调用：非常糟糕，会导致界面假死、请求阻塞，这种场景必须用await。

Test1() 用await #

private static async Task Test1()
{
    await Task.Run(() =>
    {
        for (int i = 0; i < 100; i++)
        {
            // CPU密集操作
        }
    });
}

• 在UI/Web场景下绝对更优：调用线程被释放，界面不卡、服务器能处理更多请求。
• 在控制台场景下：虽然也能正常工作，但await会带来一点点额外的状态保存/恢复开销，不过这个差异在大多数场景下可以忽略不计。

总结 #

选择Wait还是await，核心看调用线程的角色，而不是单纯看任务是CPU还是IO密集：

• 若调用线程是“空闲等待型”（如控制台主线程）：CPU密集并行任务用Wait是可行且合理的。
• 若调用线程是“资源复用型”（如UI、Web线程）：不管什么任务，都必须用await，避免阻塞浪费资源。

Stephen Cleary的话本质是在区分两种模式的最佳实践：并行模式下，阻塞是可接受的设计；异步模式下，阻塞是反模式。

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