在独立线程中执行无ConfigureAwait的异步同步等待是否会引发死锁？

死锁的核心触发逻辑 #

同步调用异步代码的死锁，本质是双向等待：被阻塞的线程卡在那儿等异步任务跑完，而异步任务的后续执行步骤（续体）又被调度规则强制安排到这个被阻塞的线程上执行，最终两边互相等。这套机制生效的核心前提是当前调用线程存在非空的自定义同步上下文（SynchronizationContext）——比如WPF/WinForms的UI线程有Dispatcher同步上下文，经典ASP.NET的请求线程有AspNetSynchronizationContext，这些上下文都会默认捕获异步任务的续体，强制让任务回到原线程执行。

疑问1：在独立新线程里直接调用.GetAwaiter().GetResult()是否安全 #

• 结论：默认实现下完全安全，不会触发死锁
• 原因：通过new Thread(MyWork.DoWork).Start()启动的独立工作线程，默认的SynchronizationContext.Current为null，没有任何自定义的续体调度逻辑。当MyHttpClient.MakeRequestAsync执行到第一个await节点时，捕获到的当前同步上下文就是null，后续所有异步续体都会直接投递到线程池执行，根本不会排队要求切回那个被GetResult()阻塞的独立工作线程，完全不满足死锁的触发条件。
• 补充说明：就算MakeRequestAsync内部所有await都没有加ConfigureAwait(false)，在这个场景下也不会出问题；而且这个逻辑完全不会影响它在UI、经典ASP.NET等场景下的原有能力——那些场景的线程本身带非空同步上下文，依然可以正常捕获上下文、切回原线程执行，不需要为了这个场景全局修改ConfigureAwait配置。

疑问2：MakeRequestAsync的异步续体恢复时，是否会回到启动它的独立新线程 #

• 结论：不会
• 原因：异步续体的调度完全依赖运行时捕获的同步上下文：
  • 如果捕获到非空的UI/ASP.NET同步上下文，才会把续体排到对应上下文的专属线程队列里执行；
  • 如果捕获到的同步上下文为null，续体会直接由任意空闲的线程池线程执行，不存在强制切回调用线程的逻辑。
    何况你通过new Thread启动的独立线程本身没有消息循环、没有续体接收队列，就算想把任务切回去也没有承接逻辑，根本不可能回到这个独立线程上执行。

场景边界提醒 #

• 不要在这个独立工作线程里手动赋值非空的SynchronizationContext.Current，否则会打破当前的安全边界，重新引入死锁风险。
• 这个安全结论仅适用于当前的裸独立线程场景，如果把同样的同步阻塞调用逻辑挪到UI线程、经典ASP.NET请求线程上执行，依然会触发经典的同步调用异步死锁问题，不能直接套用这个场景的经验。

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