看过这么多爆文，依旧走不好异步编程这条路？
本文转载自微信公众号「精益码农」，看过作者精益码农。多爆转载本文请联系精益码农公众号。文依
引言
C#异步编程语法糖async/await，旧走使开发者很容易就能编写异步代码。不好编程
零散看过很多文章，异步很多是条路填鸭式灌输 (有的翻译文还有偏差)。
遵守以上冷冰冰的看过②③条的原则，一般可确保异步程序按预期运作，多爆
我们时常能在各大论坛看到同学们(因不遵守②③点)引发的文依死锁现场。
由async/await引起的旧走死锁现场
UI程序(WinForm、WPF)：点击按钮，不好编程触发一个HTTP请求，异步用请求结果修改UI控件，条路以下代码会引发deadlock
public static async Task<string> GetJsonAsync(Uri uri) { using (var client = new HttpClient()) { var jsonString = await client.GetStringAsync(uri); return jsonString; } } // 上层调用方法 public void Button1_Click(...) { var jsonTask = GetJsonAsync(...); textBox1.Text = jsonTask.Result; }ASP.NET web程序：从api接口发起HTTP请求，看过返回请求的结果，以下代码也会引发deadlock
public static async Task<string> GetJsonAsync(Uri uri) { using (var client = new HttpClient()) { var jsonString = await client.GetStringAsync(uri); return jsonString; } } // 上层调用方法 public class MyController : ApiController { public string Get() { var jsonTask = GetJsonAsync(...); return jsonTask.Result; } } 解决以上死锁有两种编程方式： 不再混用异步/同步写法, 始终使用async/await语法糖编写异步代码 对等待的异步任务应用ConfigureAwait(false)方法SynchronizationContext就是这类死锁的牛鼻子，大多数时候SynchronizationContext是在异步编程后默默工作，但了解这个对象对于理解sync/await工作原理、解决死锁大有裨益。
本文会解释：
async/await工作机制 SynchronizationContext在异步编程语法糖中的意义 示例代码为什么会deadlock1. await/async语法糖工作机制
微软提出Task线程包装类、 await/async语法糖简化了异步编程的亿华云方式：
第②步：调用异步方法GetStringAsync时，开启异步任务;
第⑥步：遇到await关键字，框架会捕获调用线程的同步上下文(SynchronizationContext)对象, 附加给异步任务;同时控制权上交到上层调用函数;
第⑦步：异步任务完成，通过IO完成端口通知上层线程， 第⑧步：通过捕获的线程同步上下文执行后继代码块;
2. SynchronizationContext的意义
先看下MSDN中关于SynchronizationContext的定义：
提供在各种同步模型中传播同步上下文的基本功能。此类实现的同步模型的目的是允许公共语言运行库的内部异步/同步操作使用不同的同步模型正常运行。
??这就不是人能看懂的解释，我给出的解释是：在线程切换过程中保存调用线程的上下文环境， 用于在异步任务完成后使用此线程同步上下文执行后继代码。
线程同步上下文的意义在哪?
大家都知道：WinForm和WPF都有类似的原则：长耗时的任务在后台进行，将异步结果返回给UI线程 。(这难道就是ConfigureAwait方法默认传true的原因?)
此时就需要捕获UI线程的香港云服务器SynchronizationContext，并将这个对象传入异步任务。
public static void DoWork() { //On UI thread var sc = SynchronizationContext.Current; ThreadPool.QueueUserWorkItem(delegate { //... async task：do work on ThreadPool sc.Post(delegate { // do work on the original context (UI) }, null); }); }SynchronizationContext表示代码运行的线程环境，在异步编程中，利用该对象切换代码执行环境。
不同的.NET框架因各自独特的线程切换场景有不同的SynchronizationContext子类(重写父类虚方法)：
ASP.NET有AspNetSynchronizationContext WinForm有WindowsFormSynchronizationContext WPF 有DispatcherSynchronizationContext ASP.NET Core、控制台程序不存在SynchronizationContext，SynchronizationContext.Current=nullAspNetSynchronizationContext维护了HttpContext.Current、用户身份和文化，但在ASP. NET Core这些信息天然依赖注入，故不再需要SynchronizationContext;另一个好处是不再获取同步上下文对性能也是一种提升。
因此，对于ASP.NET Core程序，ConfigureAwait(false)不是必需的，然而，在基础库时最好还是使用ConfigureAwait(false)，因为你保不准上层会混用同步/异步代码。
3. 引言代码为什么发生deadlock
观察引言代码，控制权返回到上层调用函数时，执行流使用Result/(Wait方法)等待任务结果：Result/Wait()导致调用线程同步阻塞(等待任务完成)， 而异步任务执行完成后，会尝试利用捕获的同步上下文执行后继代码，这样形成死锁。云服务器提供商
正因为如此，我们提出两种方式解决死锁：
原调用函数始终使用await方法，这样调用线程是异步等待任务完成，后继代码可以在该线程同步上下文上执行 对异步任务应用ConfigureAwait(false)方法ConfigureAwait(bool)：true 表示尝试在捕获的原调用线程SynchronizationContext 中执行后继代码;false 不再尝试在捕获的线程SynchronizationContext中执行后继代码。 ConfigureAwait(false) 能解决[因调用线程同步阻塞]引发的死锁，但是同步阻塞没有利用异步编程的优点，不是很推荐。
归根到底，这两种解决死锁的方式都是针对SynchronizationContext;
ASP. NET Core和控制台程序，因为捕获的SynchronizationContext=null, 会选择一个线程同步上下文来执行，不会死锁。
总结
微软为加快开发效率上着实费了心力，.NET提供的await/async语法糖简化了异步编程方式,
在异步编程中，SynchronizationContext决定了后继代码在哪里执行的环境，深入理解这个对象的背景和不同框架的实现方式，能帮助我们避免编写死锁代码。