C# 并发编程之异步编程(线程讨论)

来自:艾心

写在前面


本篇是异步编程系列的第三篇,本来计划第三篇的内容是介绍异步编程中常用的几个方法,但是前两篇写出来后,身边的朋友总是会有其他问题,所以决定再续写一篇,作为异步编程(一)(cnblogs.com/edison0621/p/10542953.html)和异步编程(二)(cnblogs.com/edison0621/p/10584279.html)的补充。


本篇内容主要讨论,在我们的异步代码里,运行的到底是哪个线程,在执行长时间运行操作时线程发生了什么。


Await之前


在一个被async修饰了的异步方法里,如果没有遇到await,你的代码将一直在调用线程上。


在UI应用程序里,比如ASP.NET或者WinForm程序里,你的代码会在ASP.NET工作线程或WinForm工作线程上运行。


我们来看一下以下范例


public async Task GetResultAsync()
{
   Console.WriteLine();
   User user = this.GetUserAsync();
   //call other code
   return Task.CompletedTask;
}


以上范例里,我们在一个异步方法里调用了另一个异步方法,但是我们并没有使用await,这段代码依然在原始调用线程上执行,此时这个方法只是扮演了一个传播异步的作用。


当我们在UI线程上如此编程的时候,代码在UI线程是执行,在没有执行结束之前,页面是没有响应的。所以如果页面长时间没有响应,未必是异步导致的,可能会有其他原因,需要综合考虑,可以借助性能分析器来查看影响系统的原因在哪里。


Await中


代码到达await后,到底是哪一个线程在执行异步操作呢。


我们以ASP.NET为例,对于网络请求之类的操作,此时没有线程在执行异步操作,他们都被阻塞了,正在等待操作完成。但是如果使用了Task.Run,那么执行该任务时就要用到线程池里的线程了。


那么问题来了,我们在编写异步方法的时候,确确实实可以看到这个方法被执行了,肯定有线程执行才行啊。


对的,确实需要线程来执行,这个线程我们把它称之为是IO完成端口线程。此线程等待网络请求完成,同时它在所有网络请求之间共享。当网络请求完成时,操作系统中的中断处理程序会以Job方式添加到IO完成端口的队列中。在请求发起后,响应返回前,它们需要依次由单个IO完成端口处理。


实际上,一般情况下只有少量IO完成端口线程,以充分利用多个CPU核心。需要注意的是,无论当前有多少个请求,我们的线程数量都是固定的。 


参考以下运行图



SynchronizationContext


我在异步编程(一)这边文章里,有讲到SynchronizationContext这个类,它是.NET框架提供的类,可以在特定类型的线程中运行代码。


.NET使用各种SynchronizationContext,常见的有ASP.NET、WinForms和WPF使用的UI线程上下文。


SynchronizationContext的实例本身并没有特殊的地方,其实例指向的是其子类,具有静态成员,可以用于读取和控制当前的SynchronizationContext。


当前SynchronizationContext是当前线程的属性。在一个特定线程所运行到的任意的地方,都能够获取当前的SynchronizationContext并存储它,并且可以使用SynchronizationContext,在所启动的这个特定线程上运行代码。综上所述,我们并不需要知道代码在哪个线程上启动,只需要使用到SynchronizationContext,我们就可以返回到启动线程。


SynchronizationContext的重要方法是POST,它可以使委托在正确的上下文中运行。


某些SynchronizationContext封装单个线程,如UI线程。有些线程封装了特定类型的线程,例如线程池,但可以选择将委托发送到其中的任何一个线程。有些不会更改代码运行在哪个线程上,而只用于监视,如ASP.NET SynchronizationContext。


到这个地方,我们就需要了解一个问题了。在await之前,我们的代码是在调用线程上运行,那么await之后,恢复方法时到了哪个线程上了?


实际上,大多数情况下,await后的代码也由调用线程运行,尽管调用线程可能在等待期间做了其他事情。C#使用SynchronizationContext来完成此操作。


当等待任务完成时,当前的同步上下文被存储为暂停方法的一部分。然后,当方法恢复时,await关键字的基础结构使用POST在捕获的同步上下文上恢复该方法。


既然有大多数情况,那么肯定也有小众情况吧,以下情况可以在不同的线程上运行


  • SynchronizationContext具有多个线程,如线程池


  • SynchronizationContext不是真正切换线程的上下文


  • 到达等待时,没有当前的同步上下文,例如在控制台应用程序中


  • 将任务配置为不使用同步上下文来恢复


注意:对于UI应用程序来说,在同一线程上恢复是最重要的,我们等待之后安全的操作UI。


解析异步操作


以WinForm为例,我们设计一个按钮,用于下载我们喜欢的小图标。用户点击按钮之后,UI线程启动,并会执行响应的操作,以下图片展示了一个异步操作的流程,以及期间UI线程与IO线程是如何切换的



1、用户单击该按钮,事件处理程序GetButton_OnClick开始排队等待运行。


2、用户界面线程执行GetButton_OnClick的前半部分,包括对GetFaviconAsync的调用。


3、UI线程继续进入GetFaviconAsync并执行其前半部分,包括对DownloadDataTaskAsync的调用。


4、UI线程继续进入DownloadDataTaskAsync,它启动下载并返回任务。


5、UI线程离开DownloadDataTaskAsync,并返回GgetFaviconAsync处的await。


6、当前的UI线程捕获到了SynchronizationContext。


7、GetFaviconAsyncy因为有await的标识,会等待,当DownloadDataTaskAsync完成后GetFaviconAsyncy便会使用捕获到的SynchronizationContext恢复。


8、用户线程离开GetFaviconAsync,并返回一个任务,并运行到GetButton_OnClick中的await。


9、类似地,GetButton_OnClick被等待暂停。


10、用户线程离开GetButton_OnClick,可能会用于处理其他操作。【此时,我们正在等待图标下载。可能需要几秒钟。注意,UI线程可以自由处理其他用户操作,而IO完成端口线程尚未涉及到。操作期间阻塞的线程总数为零。】


11、下载完成,因此IO完成端口在DownloadDataTaskAsync中对逻辑进行排队处理。


12、IO完成端口线程将把DownloadDataTaskAsync返回的任务设置为完成。


13、IO完成端口线程在任务内部运行代码并处理完成,并会调用捕获到的同步上下文(UI线程)上的POST以继续运行接下来的代码。


14、IO完成端口线程被释放并可能在其他IO上工作。


15、用户界面线程找到POST指令,并继续执行GetFaviconAsync的后半部分,直到结束。


16、当UI线程离开GetFaviconAsync时,它会将GetFaviconAsync返回的任务设置为完成。


17、在这个运行点里,当前的同步上下文与捕获的上下文相同,因而无需用到POST,UI线程也会继续同步进行。【此逻辑在WPF中是无效的,因为WPF经常创建新的SynchronizationContext对象。尽管它们是等效的,这使得TPL认为它需要重新POST。】


18、用户线程继续运行GetButton_OnClick的后半部分,直到结束。 


总结


同步上下文的每个实现都是以不同的方式执行POST的,这是非常消耗性能的事情。为了避免这种开销.


.NET内部也是有自己的优化机制的,它会在捕获的SynchronizationContext与任务完成时的当前上下文相同时,不使用POST。很有意思的是,如果你使用调试器查看这种情况,会发现调用堆栈是颠倒的。


但是,当同步上下文不同时,这就需要用到系统开销了。在性能关键的代码中或者某个代码库中,如果我们并不不关心使用到了哪个线程,这个时候我们也可以通过自己的手动操作来避开这种开销。


在等待任务之前调用ConfigureaWait来完成。这样就不会恢复到原始同步上下文。


byte[] bytes = await httpClient.PostAsJsonAsync(url,data)               .ConfigureAwait(false).ReadAsStreamAsync();


不过,ConfigureAwait并不是严格的指令,它是.NET设计的一个标识,用来告诉运行时我们不介意方法在哪个线程上运行。如果该线程不重要(线程池线程),它将会继续执行代码。


如果是很重要的线程,.NET会通过自身机制将线程释放,让它来做其他事情,而方法也将在线程池中恢复。.NET使用线程的当前的SynchronizationContext来判断它是否重要。


前文有说过,本文再提一次,在同步代码中运行异步代码,可能有隐藏的问题。Task有一个Result属性,该属性阻止等待任务完成。如以下代码:


var result = GetUserAsync().Result;


但是如果在只有一个线程(如UI线程)的SynchronizationContext使用就会发生死锁现象。解决问题的方法就是,我们可以使用线程池线程来解决这个问题。如以下代码:


var result = Task.Run(() =>GetUserAsync()).Result;
推荐↓↓↓
DotNet程序员
上一篇:Visual Studio 2019使用Live Share 下一篇:ASP.NET Core 使用Jaeger实现分布式追踪