使用ConfigureAwait(false)时调用Task.Result是否死锁？代码写法咨询

一、使用ConfigureAwait(false)时调用Task.Result是否会引发死锁？ #

死锁的核心诱因是：同步上下文被阻塞（比如调用.Result/.Wait()），同时异步代码尝试抢占同一个同步上下文恢复执行。当你在await时加上ConfigureAwait(false)，会告知编译器无需回到原同步上下文，这种情况下如果后续调用.Result，只要异步链中所有关键await点都正确使用ConfigureAwait(false)，一般不会触发死锁。

但要注意：ConfigureAwait(false)仅作用于当前await节点，并非全局生效。如果异步操作的上游代码已经绑定了同步上下文，或者链中某一步未加ConfigureAwait(false)，仍存在死锁风险。

二、针对示例代码的具体分析 #

原代码如下：

public override void OnActionExecuting(HttpActionContext actionContext)
{
    var body = Task.Run(async()
    => await actionContext.Request.Content.ReadAsStringAsync()
        .ConfigureAwait(false)).Result;
    // 其余代码省略
}

1. 上述代码是否会导致死锁？ #

不会。Task.Run会将异步委托放到线程池线程执行，脱离了原ASP.NET同步上下文（仅老版ASP.NET存在，ASP.NET Core无此上下文）；同时内部await ReadAsStringAsync().ConfigureAwait(false)明确不要求回到原上下文。即便外部用.Result阻塞了当前线程，异步操作的后续执行也不会抢占被阻塞的同步上下文，因此不会死锁。但该写法多套了一层Task.Run，属于冗余操作。

2. 无法标记为async Task时，是否应改用GetAwaiter().GetResult()？ #

是的，更推荐使用以下写法：

var body = actionContext.Request.Content.ReadAsStringAsync().ConfigureAwait(false).GetAwaiter().GetResult();

理由有两点：

• 移除了冗余的Task.Run，减少线程池调度开销，直接调用原始异步方法，效率更高；
• .GetAwaiter().GetResult()会直接抛出异步操作的原始异常，而.Result会将异常包装在AggregateException中，调试和异常处理更便捷。

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