以下文章来源于精益码农 ,作者精益码农
有态度马甲,阿里云社区专家博主,热衷分享,执着于阅读写作,佛系不水文; 持续输出高价值Go、.NET、云原生原创文章。
引言
C#异步编程语法糖async/await,使开发者很容易就能编写异步代码。零散看过很多文章,很多是填鸭式灌输 (有的翻译文还有偏差)。
遵守以上冷冰冰的②③条的原则,可以确保我们的异步程序按照预期运作,但是我们常看到违背这2条原则引发的死锁现场。
由async/await引起的死锁现场
UI例子:
点击按钮触发一个HTTP请求,用请求的返回值修改UI控件, 以下代码会引发deadlock (类似状态出现在WinForm、WPF)
public static async Task<JObject> GetJsonAsync(Uri uri)
{
using (var client = new HttpClient())
{
var jsonString = await client.GetStringAsync(uri);
return JObject.Parse(jsonString);
}
}
// 上层调用方法
public void Button1_Click(...)
{
var jsonTask = GetJsonAsync(...);
textBox1.Text = jsonTask.Result;
}
ASP.NET web例子:
从api发起远程HTTP请求,等待请求的结果,以下代码也会引发deadlock
public static async Task<JObject> GetJsonAsync(Uri uri)
{
using (var client = new HttpClient())
{
var jsonString = await client.GetStringAsync(uri);
return JObject.Parse(jsonString);
}
}
// 上层调用方法
public class MyController : ApiController
{
public string Get()
{
var jsonTask = GetJsonAsync(...);
return jsonTask.Result.ToString();
}
}
解决以上死锁有2种编程写法:
SynchronizationContext
就是解决这类死锁的牛鼻子,大多数时候SynchronizationContext
是在异步编程后默默工作的,但是了解这个对象对于理解Task、await/sync 工作原理大有裨益。
本文会解释:
微软提出了Task线程包装类和 await/async简化了异步编程的方式:
第②步:调用异步方法GetStringAsync时,开启异步任务;
第⑥步:遇到await关键字,框架会捕获调用线程的同步上下文(SynchronizationContext)对象,附加给异步任务;同时,控制权上交到上层调用函数;
第⑦步:异步任务完成,通过IO完成端口通知上层线程, 第⑧步:通过捕获的线程同步上下文执行后继代码块;
先看下MSDN中关于SynchronizationContext的定义:
提供在各种同步模型中传播同步上下文的基本功能。此类实现的同步模型的目的是允许公共语言运行库的内部异步/同步操作使用不同的同步模型正常运行。
☹️这完全不是人能看懂的解释,我给出的解释是:在线程切换过程中保存调用线程的上下文, 用于在异步任务完成后使用此线程同步上下文执行后继代码。
这个线程同步上下文的意义在哪?
我们大家都知道:WinForm和WPF都有类似的原则:长耗时的任务在后台计算,将异步结果返回给UI线程
这个时候我们就需要捕获UI线程的SynchronizationContext,并将这个对象传入后台线程。
public static void DoWork()
{
//On UI thread
var sc = SynchronizationContext.Current;
ThreadPool.QueueUserWorkItem(delegate
{
// do work on ThreadPool
sc.Post(delegate
{
// do work on the original context (UI)
}, null);
});
}
SynchronizationContext
标识了代码运行的线程环境,每个线程都有自己的SynchronizationContext,通过SynchronizationContext.Current可以获取当前线程的同步上下文。
在异步线程切换场景中,使用SynchronizationContext ,就可以返回到调用线程。不同的.NET框架因各自独特的需求有不同SynchronizationContext子类(通常是重写父类虚方法):
AspNetSynchronizationContext维护了HttpContext.Current、用户身份和文化,但在ASP. NET Core这些信息天然依赖注入,故不再需要SynchronizationContext;另一个好处是不再获取同步上下文对性能也是一种提升。因此,对于ASP.NET Core程序,ConfigureAwait(false)不是必需的,然而,在基础库时最好还是使用ConfigureAwait(false),因为你保不准上层会混用同步/异步代码。
观察引言代码,控制权返回到上层调用函数时,执行流使用Result/(Wait方法)等待任务结果,Result/Wait()会导致调用线程同步阻塞(等待任务完成), 而异步任务执行完成后,会尝试利用捕获的同步上下文执行后继代码,这样形成死锁。
正因为如此,我们提出:
ConfigureAwait(bool):true 表示尝试在捕获的原调用线程SynchronizationContext 中执行后继代码;false 不再尝试在捕获的线程SynchronizationContext中执行后继代码。ConfigureAwait(false) 能解决[因调用线程同步阻塞]引发的死锁,但是同步阻塞没有利用异步编程的优点,不是很推荐。
你会看到,这两种缓解死锁的方案其实 都是针对SynchronizationContext
;ASP.NET Core和控制台程序,因为捕获的SynchronizationContext=null, 会选择一个线程同步上下文来执行,不会死锁。
总结
- EOF -
看完本文有收获?请转发分享给更多人
推荐关注「DotNet」,提升.Net技能
点赞和在看就是最大的支持❤️