Web API控制器中应使用await Task.WhenAll替代Task.WaitAll吗？

改用的核心好处： #

• 避免线程阻塞，提升并发能力
  Task.WaitAll会阻塞当前的ASP.NET线程池线程，直到所有任务完成。ASP.NET的线程池线程数量有限（默认与CPU核心数相关），如果多个请求都卡在WaitAll上占用线程，线程池里的空闲线程会快速耗尽，后续请求只能排队等待，直接导致API响应变慢甚至超时。
  而await Task.WhenAll会把当前线程释放回线程池，让它可以去处理其他请求。等任务完成后，ASP.NET会从线程池再分配线程继续执行后续代码，相同的线程池能支撑更多并发请求，这对Web API这种高并发场景至关重要。

• 符合异步编程规范，避免潜在问题
  你的控制器方法本身就是async Task类型，全程使用异步等待是标准的异步编程模式，避免了“阻塞式异步”这种混合写法带来的上下文混乱、异常处理复杂等潜在问题。

• 异常处理更直观
  Task.WaitAll如果有任务抛出异常，会抛出AggregateException，需要手动展开处理内部多个异常；而await Task.WhenAll会直接抛出第一个发生的异常（若需处理所有异常，也可捕获AggregateException），处理逻辑更符合异步代码的习惯。

关于生产环境多实例的影响 #

哪怕你有5个实例，Task.WaitAll的阻塞依然会降低每个实例的请求处理能力。每个实例的线程池都是独立的，单个实例里的线程被阻塞，该实例就无法高效处理新请求，5个实例的整体吞吐量也会跟着下降。改用await Task.WhenAll后，每个实例都能最大化利用线程池资源，支撑更多并发请求，整体服务的响应能力会显著提升。

另外补充：你后续用doSomethingTask.Result的写法，其实可以改成await doSomethingTask（在Task.WhenAll之后，任务已完成，await会直接返回结果，不会再等待），这样比直接访问Result更安全，避免不必要的异常包装。

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