为何ASP.NET Core Web API未出现预期的死锁现象？

这问题我当初刚从传统ASP.NET转ASP.NET Core的时候也踩过坑，太能理解你的困惑了！核心原因其实是ASP.NET Core彻底移除了传统ASP.NET里的请求专属SynchronizationContext，这直接避免了这类死锁场景。

先搞懂传统环境下死锁的本质 #

在.NET Framework的传统ASP.NET（或者WinForms、WPF这类有UI上下文的场景）中，每个请求/UI线程都会绑定一个专属的SynchronizationContext。这个上下文的作用是维护当前的执行环境（比如HttpContext、UI线程关联）。

当你用await调用异步方法时，默认会捕获这个SynchronizationContext，等异步操作完成后，会尝试回到这个上下文继续执行后续代码。如果此时你用.Result或者.Wait()阻塞了当前线程（也就是持有这个上下文的线程），就会形成死锁：

• 异步操作完成后，需要回到被阻塞的上下文执行后续逻辑，但这个上下文的线程已经被你的阻塞调用占住，永远腾不出手。
• 你的阻塞调用又在等异步操作完成，两边互相卡着，死锁就来了。

ASP.NET Core的关键改变 #

ASP.NET Core重构了整个执行模型，它不再使用请求专属的SynchronizationContext。默认情况下，await完成后会直接从线程池里拿一个空闲线程继续执行后续代码，完全不需要依赖某个特定的请求线程。

回到你的代码场景：

1. 当await Task.Delay(3000)执行时，当前线程会被释放回线程池，不占资源。
2. 3秒后异步操作完成，直接从线程池找个空闲线程继续跑DoSomethingAsync的剩余逻辑，根本不需要等被.Result阻塞的那个线程。
3. 最终异步操作完成，.Result拿到结果，整个流程顺畅走完，自然不会死锁。

关于你的.NET Framework 4.6.1控制台应用 #

顺便提一句，控制台应用默认是没有SynchronizationContext的（和ASP.NET Core逻辑类似），所以你在控制台里跑同样的代码，大概率也不会死锁。但如果把这段代码放到有SynchronizationContext的环境（比如传统ASP.NET、WinForms），死锁就会立刻出现。

最后必须提的：别因为不会死锁就这么写！ #

虽然ASP.NET Core不会触发死锁，但使用.Result、.Wait()这类阻塞调用是非常糟糕的实践：

• 会浪费线程池资源，严重降低应用的并发处理能力。
• 可能引发线程饥饿等潜在问题。
• 违背异步编程的设计初衷，代码也会变得更难维护和调试。

正确的做法是全程使用async/await，把你的API方法改成异步风格：

[HttpGet]
public async Task<IActionResult> YourAction()
{
    var result = await asyncTest.DoSomethingAsync();
    return Ok(result);
}

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