Task.WhenAll与Parallel.ForEachAsync对比：异步任务哪种方案更优？

性能差异核心原因 #

你的测试结果差异主要源于并发度控制逻辑的不同：

• Task.WhenAll是一次性启动所有5000个下载任务，只要系统网络、目标服务器允许，会尽可能拉满并发量。IO绑定的异步任务（比如HTTP下载）在等待响应时会释放线程回线程池，不会占用额外资源，所以能高效利用网络带宽，总耗时最短。
• Parallel.ForEachAsync默认会限制并发任务数量，它的调度逻辑偏向于平衡资源使用，默认并发度和CPU核心数、线程池状态挂钩，不会一次性发起所有请求。在IO密集的下载场景中，这种限制会导致大量时间浪费在等待任务排队上，所以总耗时远高于预期。

内部实现原理 #

Task.WhenAll #

• 它本质是一个“聚合任务”，不负责任务的执行调度，只是监听所有传入任务的完成状态，当全部任务结束（成功/失败）时，自身才完成。
• 所有下载任务的调度交给.NET线程池，对于IO异步操作，任务在等待IO响应时会释放线程，线程池可以复用这些线程处理其他任务的IO回调，因此能支持极高的并发量，不会因为任务数量多而阻塞。

Parallel.ForEachAsync #

• 这是.NET 6新增的异步并行迭代API，设计初衷是兼顾CPU绑定和IO绑定场景，核心是主动控制并发度。
• 内部维护一个任务队列，默认根据系统环境设置最大并发数（比如和CPU核心数正相关），同一时间只执行指定数量的异步任务，当一个任务完成后，才从队列中取出下一个任务启动。这种设计在CPU密集场景下能避免线程上下文切换过载，但在IO密集的下载场景中，会因并发不足拖慢整体速度。

方案选型建议 #

• 纯IO密集的大规模批量任务（如你的图片下载场景）：优先用Task.WhenAll，但要注意如果并发量过高可能触发服务器限流或本地网络拥堵，这时可以用SemaphoreSlim手动限制并发数（比如同时执行50个任务），兼顾速度和稳定性。
• 需要控制并发、或混合CPU+IO的任务：选Parallel.ForEachAsync更合适，比如下载图片后需要本地压缩（CPU密集），或者调用有频率限制的第三方API，它的内置并发控制能避免资源过载，同时平衡IO等待和CPU利用效率。

Parallel.ForEachAsync的适用场景 #

• 有限流要求的IO任务：比如调用第三方API有QPS限制，通过设置MaxDegreeOfParallelism可以精准控制并发请求数，避免被封禁。
• CPU+IO混合任务：如下载后需处理数据、转换格式等，它能平衡线程资源，避免过多线程导致CPU过载。
• 需边执行边处理结果的场景：可以在迭代过程中实时处理每个任务的结果（如下载一张就保存一张），无需等待所有任务完成后统一处理。
• 同步并行迭代的异步迁移：如果原来用Parallel.ForEach做同步并行处理，现在要改成异步逻辑，Parallel.ForEachAsync是更自然的替代方案，无需手动管理任务队列和并发控制。

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