Task.WhenAll适用于异步I/O并发，不创建线程，任务需已启动且真正异步；Parallel.Invoke用于同步CPU密集型并行，依赖线程池，不支持async。

Task.WhenAll 适合异步 I/O 并发，不是 CPU 密集型并行

Task.WhenAll 本质是等待多个 Task 同时完成，它不创建新线程，也不控制执行时机——所有任务必须已启动（或在传入时立即启动）。常见误用是把它当成“并发执行多个耗时计算”，结果发现 CPU 占用没上去、总耗时不降反升。

典型适用场景：同时发起多个 HTTP 请求、读多个文件、查多个数据库。这些操作大部分时间在等 I/O，线程可以释放去做别的事。

• 传入的每个 Task 应该是真正异步的（比如用了 HttpClient.GetAsync、File.ReadAllTextAsync），而不是包装了 Task.Run(() => { Thread.Sleep(1000); })
• 如果任务里混入同步阻塞代码（如 Thread.Sleep、File.ReadAllText），会占用线程池线程，可能拖慢其他异步操作
• 返回的是 Task，结果顺序与输入顺序严格一致

var tasks = new[]
{
    httpClient.GetAsync("https://api1/"),
    httpClient.GetAsync("https://api2/"),
    httpClient.GetAsync("https://api3/")
};
var responses = await Task.WhenAll(tasks); // 三路请求真正并发，通常 1 秒内完成

Parallel.Invoke 是同步 CPU 绑定任务的并行执行工具

Parallel.Invoke 会在内部使用 ThreadPool 分配多个线程，强制并行执行多个 Action 委托。它不返回值，也不支持 async 委托——传入的每个动作都必须是同步的、CPU 密集型的。

如果你试图在里面 await，编译直接报错；如果硬写成 async void 或用 .Wait()，会死锁或严重降低效率。

• 适合场景：图像像素处理、大量数学计算、本地 XML 解析、批量字符串转换等纯内存运算
• 不适用于含 I/O 的逻辑（如写文件、调 API），因为线程会被卡住，浪费线程池资源
• 没有内置顺序保证，各 Action 执行完成时间不确定，也不能直接获取返回值

Parallel.Invoke(
    () => ProcessImage(partA),
    () => ProcessImage(partB),
    () => ProcessImage(partC)
); // 三个计算任务真正在多核上跑，假设每个需 800ms，总耗时约 800ms

别把 async 方法塞进 Parallel.Invoke

这是最常踩的坑：Parallel.Invoke 接收的是 Action，而 async void 或 async Task 方法签名不匹配。即使你绕过编译（比如用 .Wait()），也会引发线程池饥饿、死锁或异常堆积。

• 错误写法：() => SomeAsyncMethod().Wait() —— 阻塞线程，失去 async 意义
• 错误写法：async () => await SomeAsyncMethod() —— 编译失败，类型不兼容
• 正确做法：I/O 类型并发统一走 Task.WhenAll；CPU 类型才考虑 Parallel.Invoke 或 Parallel.For

混合场景（比如先并发下载，再并发处理）要分两层：先 await Task.WhenAll(downloads) 拿到数据，再用 Parallel.ForEach 处理 byte[] 数组。

性能和可维护性差异很实际

Task.WhenAll 开销极小，只是组合状态机；Parallel.Invoke 有线程调度、负载均衡、异常聚合等开销，小数据量下甚至比单线程还慢。

• 10 个 50ms 的 HTTP 请求：用 Task.WhenAll 总耗时 ~55ms；用 Parallel.Invoke + .Wait() 可能要 500ms+（线程争抢 + 阻塞）
• 10 个 50ms 的 CPU 计算：用 Parallel.Invoke 可压满双核，总耗时 ~55ms；用 Task.WhenAll(Task.Run(...)) 多一层调度，略慢但可接受
• 调试难度：Task.WhenAll 异常堆栈清晰指向具体哪个 task；Parallel.Invoke 的异常会被包装成 AggregateException，需遍历 InnerExceptions

真正难的是判断一个方法到底是 I/O 型还是 CPU 型——看它是否频繁调系统调用、是否长时间不返回、是否依赖外部服务。这点错了，选什么并发方案都白搭。

https://www.php.cn/faq/1964868.html