写在前面

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

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

Await之前

在一个被async修饰了的异步方法里，如果没有遇到await，你的代码将一直在调用线程上。在UI应用程序里，比如ASP.NET或者WinForm程序里，你的代码会在ASP.NET工作线程或WinForm工作线程上运行。

我们来看一下以下范例

   2:  {

   3:      Console.WriteLine();

   4:   

   5:      User user = this.GetUserAsync();

   6:   

   7:      //call other code

   8:   

   9:      return Task.CompletedTask;

  10:  }

以上范例里，我们在一个异步方法里调用了另一个异步方法，但是我们并没有使用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来完成。这样就不会恢复到原始同步上下文。

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

不过，ConfigureAwait并不是严格的指令，它是.NET设计的一个标识，用来告诉运行时我们不介意方法在哪个线程上运行。如果该线程不重要（线程池线程），它将会继续执行代码。如果是很重要的线程，.NET会通过自身机制将线程释放，让它来做其他事情，而方法也将在线程池中恢复。.NET使用线程的当前的SynchronizationContext来判断它是否重要。

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

   1:  var result = GetUserAsync().Result;

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

   1:  var result = Task.Run(() =>GetUserAsync()).Result;