Task.Run与JoinableTaskFactory.Run的区别及非异步调用异步任务最佳实践

先看你给出的三种实现：

JoinableTaskFactory 实现 #

var jtf = new JoinableTaskFactory(new JoinableTaskContext());
var serviceResponse = jtf.Run(async () =>  await _service.UpdateSomethingAsync(requestObject));

Task.Run + Result 实现 #

var task = System.Threading.Tasks.Task.Run(async () => await _service.UpdateSomethingAsync(requestObject));
var serviceResponse = task.Result;

Task.Run + WaitAll 实现 #

ServiceResponse serviceResponse = null;

var task = Task.Run(async () => serviceResponse = await _service.UpdateSomethingAsync(requestObject));
Task.WaitAll(task);

三种写法的核心差异 #

JoinableTaskFactory.Run #

这是专门为解决同步上下文死锁设计的方案，尤其适用于WPF、WinForms、老版ASP.NET这类自带同步上下文的环境。它不会直接阻塞原线程：会先尝试在当前线程上执行异步代码的同步部分，必要时才切换到线程池线程，任务完成后还能自动回到原上下文。既避免了死锁，还能保持线程亲和性（比如UI线程的操作需求），线程资源利用也更高效。

Task.Run + Task.Result #

这种写法是把异步逻辑丢到线程池线程执行，然后用Result强制阻塞当前线程等待结果。在有同步上下文的环境里极易触发死锁：异步方法执行到await后会等待原上下文回来，但原线程被Result死死堵住，上下文无法释放，最终任务永远无法完成。另外，阻塞线程会浪费线程资源，高并发场景下可能导致线程池耗尽。

Task.Run + Task.WaitAll #

本质和上面的Result写法完全一致，都是阻塞当前线程等待任务结束，同样存在死锁风险和线程资源浪费的问题，只是写法上用WaitAll显式等待而已，核心矛盾没有解决。

最优选择怎么选？ #

• 如果代码运行在有同步上下文的环境（WPF、WinForms、老版ASP.NET），优先用JoinableTaskFactory.Run，它就是为解决这类场景的死锁问题而生的，同时能保留上下文亲和性。
• 如果是无同步上下文的环境（比如控制台程序、ASP.NET Core，因为ASP.NET Core没有传统的同步上下文），Task.Run + Result/WaitAll不会触发死锁，但还是建议优先用JoinableTaskFactory；要是场景特别简单，用这俩也能凑活，但得注意线程阻塞带来的资源消耗。
• 最根本的最优方案其实是尽量把调用方改成异步方法，从根源上避免同步调用异步的尴尬，这才是异步编程的最佳实践。只有当完全无法修改调用方法为异步时，再考虑上面的同步调用方案。

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