在Task内嵌套运行Task是否必要？两种异步转同步写法对比

原代码示例 #

public void LogoutAllSessions()
{
    Task.Run(async () => await _identityHttpClient.GetAsync(Uri)).Wait();

    // 是否可改写为如下形式？
    // _identityHttpClient.GetAsync(Uri).GetAwaiter().GetResult();
}

问题1：是否属于Task内嵌套运行Task，并阻塞线程等待外层Task完成？ #

是的。Task.Run会把内部的异步lambda（调用GetAsync的逻辑）放到线程池线程上执行，相当于外层新建了一个Task来包裹GetAsync返回的内层Task。随后调用.Wait()会直接阻塞当前线程，直到外层Task执行完毕，本质就是通过阻塞线程来等待异步操作结束。

问题2：两种写法功能是否一致？ #

功能上基本等效，最终都是同步阻塞当前线程，等待HTTP请求GetAsync(Uri)完成。但存在一个关键差异：

• Task.Run(...)会将异步逻辑切换到线程池线程上执行，当前线程仅负责阻塞等待；
• GetAwaiter().GetResult()则是直接在当前线程上等待异步操作完成（如果GetAsync的异步流程没有主动切换线程的话）。

问题3：两者谁的性能更优？ #

_identityHttpClient.GetAsync(Uri).GetAwaiter().GetResult()性能更优，理由如下：

• Task.Run会额外创建一个线程池线程来执行异步lambda，带来不必要的线程切换开销和上下文调度成本；
• GetAwaiter().GetResult()直接在当前线程等待，避免了额外的线程创建与切换，资源消耗更低。

注意：在ASP.NET（尤其是ASP.NET Core）中，同步阻塞异步操作存在线程池饥饿的风险，长期运行可能影响系统性能。如果有机会，建议逐步重构为全异步的async/await模式。

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