同步调用异步方法时JoinableTaskFactory的使用限制与适用场景

JoinableTaskFactory（简称JTF）是Microsoft.VisualStudio.Threading库中的核心组件，最初为解决Visual Studio IDE这类单线程UI上下文下同步调用异步方法的死锁问题设计，是目前同步调用异步方案里成熟度较高的一类实现。

与其他方案的共性缺陷与特有注意事项 #

共性缺陷 #

• 和直接使用.Result/.Wait()的方案一样，JTF的Run方法执行时如果异步逻辑抛出异常，会被包装为AggregateException抛出，不会像原生await那样直接抛出原始异常，需要额外做解包处理。
• 本质还是同步阻塞调用线程，会占用线程资源，和纯异步方案相比吞吐量更低。

特有注意事项 #

• 依赖正确的上下文初始化：使用前必须初始化全局唯一的JoinableTaskContext实例，且初始化时要正确捕获当前的SynchronizationContext，如果上下文初始化错误或者多实例混用，JTF的死锁规避能力会完全失效。
• 不能和其他同步阻塞方案嵌套使用：如果在JTF执行的异步委托内部调用.Result/.Wait()，仍然有概率触发死锁。
• 存在额外性能开销：JTF需要跟踪所有待执行任务的上下文依赖关系，相比原生异步或者Task.Run+.Result的方案有明显的额外开销。

适用与不适用场景 #

推荐使用场景 #

• 棕地项目迁移：存在大量遗留同步代码，无法短期内全链路改造为async/await，且运行环境存在单线程同步上下文（比如WPF/WinForm UI线程、ASP.NET Framework请求上下文），原有同步调用异步方案频繁触发死锁的场景。
• 兼容类库开发：类库需要同时支持上层同步、异步两种调用方式，且上层可能运行在有单线程同步上下文的环境中。

不推荐使用场景 #

• 全新项目：可以全链路使用async/await实现异步逻辑的场景，没必要引入额外依赖和开销。
• 无特殊同步上下文的环境：比如控制台应用、ASP.NET Core服务，这类环境下默认没有单线程同步上下文，直接使用Task.Run包装异步逻辑再阻塞等待也不会死锁，使用JTF属于过度设计。
• 高并发服务端场景：JTF的任务跟踪开销会明显降低服务吞吐量，不适合高并发的后端服务使用。

使用时的核心考量要点 #

• 依赖成本：JTF不属于.NET基础类库，需要单独引入Microsoft.VisualStudio.ThreadingNuGet包，要提前评估项目的依赖管理要求。
• 上下文单例性：必须保证整个应用域内只初始化一次JoinableTaskContext，且所有JTF实例都基于这个全局上下文创建，否则会出现各种不可预期的并发问题。
• 长期架构规划：JTF只是同步调用异步的临时过渡方案，不要作为长期架构依赖，有条件的情况下还是要逐步完成全链路异步改造，从根本上避免同步调用异步的各类问题。

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