走进异步世界-犯傻也值得分享:ConfigureAwait(false)使用经验分享

时间:2022-12-03 11:39:11

在上周解决“博客程序异步化改造之后遭遇的性能问题”的过程中,我们干了一件自以为很有成就感的事——在表现层(MVC与WebForms)将所有使用await的地方都加上了ConfigureAwait(false),比如下面代码:

var taskCategories = GetCategoriesAsync();
model.Posts = await GetPostsAsync(model).ConfigureAwait(false);
model.Paging.TotalCount = await taskTotalCount.ConfigureAwait(false);
model.HeadlineHtml = await taskHeadlineHtml.ConfigureAwait(false);
model.Categories = await taskCategories.ConfigureAwait(false);

干完之后才恍然大悟,我们“出色”地完成了一件傻事,性能问题并没有得到解决,最终发现问题的真正原因是我们修改的EnyimMemcaced代码存在内存泄漏问题

犯傻之后,郁闷之时,意外地发现竟然有一些收获可以分享,于是自伤的心有了些许安慰。

在干这次傻事之前,我们分不清默认的ConfigureAwait(continueOnCapturedContext:true)与ConfigureAwait(false)的区别,只知道一个是在异步执行时捕获上下文,一个是在异步执行时不捕获上下文。更不知道ConfigureAwait(false)会带来什么影响?

傻过之后,我们对此多了一点了解:

1)当ConfigureAwait(true),代码由同步执行进入异步执行时,当前同步执行的线程上下文信息(比如HttpConext.Current,Thread.CurrentThread.CurrentCulture)就会被捕获并保存至SynchronizationContext中,供异步执行中使用,并且供异步执行完成之后(await之后的代码)的同步执行中使用(虽然await之后是同步执行的,但是发生了线程切换,会在另外一个线程中执行「ASP.NET场景」)。这个捕获当然是有代价的,当时我们误以为性能问题是这个地方的开销引起,但实际上这个开销很小,在我们的应用场景不至于会带来性能问题。

2)当Configurewait(flase),则不进行线程上下文信息的捕获,async方法中与await之后的代码执行时就无法获取await之前的线程的上下文信息,在ASP.NET中最直接的影响就是HttpConext.Current的值为null。

我们在犯傻过程中,工作量最大的就是处理HttpConext.Current为null的情况。

由于之前写代码时的幼稚与偷懒,造成了很多地方用HttpConext.Current去获取http请求相关信息。在异步化改造之后,HttpConext.Current也遍布在很多aync方法中。Configurewait(flase)之后,NullReferenceException如雨后春笋。

针对这样的窘境,我们只能一个个修改代码,通过方法参数传递所需要的HttpConext信息,取代原先的HttpConext.Current“绿色通道”访问方式。

还有些地方根本不需要HttpConext.Current,只是因为当初的幼稚,比如Server.MapPath(),Server.UrlEncode(),进行了这样的更改:

System.Web.Hosting.HostingEnvironment.MapPath();
HttpUtility.UrlEncode();

在处理HttpConext.Current为null的情况中,我们遇到了一个棘手的问题,它出现在MVC与WebForms混用的场景——在MVC Controller中加载WebForms中的UserControl(也就是让UserControl直接Render为字符串)。

之前我们在MVC中是这样处理的:

page.Controls.Add(commentControl);
using (var sw = new StringWriter())
{
HttpContext.Current.Server.Execute(page, sw, true);
commentsHtml = sw.ToString();
}

可是现在HttpContext.Current为null,不得不改成这样:

page.Controls.Add(commentControl);
var sb = new StringBuilder();
using (var sw = new StringWriter(sb))
{
using (var htw = new HtmlTextWriter(sw))
{
commentControl.RenderControl(htw);
commentsHtml = sb.ToString();
}
}

改好之后发现,只要.ascx中用到了HyperLink控件并访问NavigateUrl属性,就会出现NullReferenceException。原来HyperLink.NavigateUrl中调用了ResolveClientUrl方法,而ResolveClientUrl时会访问Context.Request.ClientBaseDir.VirtualPathString,而Context为null。

在这个地方折腾了不少时间,后来绕道解决了这个问题,用Attributes.Add取代HyperLink.NavigateUrl,比如:

hl.Attributes.Add("href", "http://www.cnblogs.com/");

在WebForms的UserControl中添加ConfigureAwait(false)时,我们开始时以为await之后的代码如果访问Context,也会引发NullReferenceException,而事实表明不会引发。因为在ASP.NET实例化UserControl时会将HttpContext的值传给UserControl的Context属性,所以在UserControl无需通过线程上文获取HttpContext信息(Page的情况也一样)。

另外一个受影响的地方就是线程的CurrentCulture设置,之前我们是在Application_BeginRequest中处理的,代码如下:

protected void Application_BeginRequest(Object sender, EventArgs e)
{
CultureInfo newci = new CultureInfo("zh-CN");
newci.DateTimeFormat.DayNames = new string[] { "日", "一", "二", "三", "四", "五", "六" };
newci.DateTimeFormat.FirstDayOfWeek = DayOfWeek.Sunday;
System.Threading.Thread.CurrentThread.CurrentCulture = newci;
}

但是由于ConfigureAwait(false),异步执行中的线程切换会造成CurrentCulture丢失。

解决方法很简单,直接设置所有线程的CurrentCulture,代码如下:

protected void Application_Start(Object sender, EventArgs e)
{
var newCulture = new CultureInfo("zh-CN");
newCulture.DateTimeFormat.DayNames = new string[] { "日", "一", "二", "三", "四", "五", "六" };
newCulture.DateTimeFormat.FirstDayOfWeek = DayOfWeek.Sunday;
CultureInfo.DefaultThreadCurrentCulture = newCulture;
}

ConfigureAwait(false)的使用经验值得分享的就这些。

在这次异步化改造过程中,不仅加ConfigureAwait(false)是干傻事,整个异步化改造就是一件大傻事。改造过程很艰辛,多次犹豫是不是要这么彻底地异步化,最终还是坚持了下来。当解决了内存泄漏问题之后,如释重负!异步化改造效果明显,超出了预期——响应性能与吞吐能力都得到了提升。过程中所有的煎熬与痛苦都被成功后涌上心头的那种兴奋所秒杀。

【参考资料】

Best practice to call ConfigureAwait for all server-side code

It's All About the SynchronizationContext