https://www.cnblogs.com/haibozhu/p/11407647.html
2020.11.18 用于延迟时钟等方面的，存在异步调用注意事项，待继续学习了解
每次提到异步我都选择绕开，感觉深不可测，最近打算看看异步，但又不愿意看书，网上找了几个视频看，发现传智播客的老师讲异步都不是很深入，关键的问题一笔带过，倒是把我弄糊涂了，印象最深刻的是那个老师说的一句话：“在异步函数中，Await之后会自动创建出一个线程”。确实，在控制台程序中是这样，但是在winform中却不都在UI线程中执行，感觉内部隐藏不可告人的秘密，索性自己探索一下。
控制台程序：
static void Main(string[] args)
{
Console.WriteLine("1.同步ThreaID：" + Thread.CurrentThread.ManagedThreadId);
RunTimeAsync();
Console.WriteLine("4.异步执行完毕ThreaID：" + Thread.CurrentThread.ManagedThreadId);
Thread.Sleep(5000);
Console.WriteLine("5.同步延迟完毕ThreaID：" + Thread.CurrentThread.ManagedThreadId);
Console.ReadKey();
}
public async static Task RunTimeAsync()
{
Console.WriteLine("2.进入异步ThreaID：" + Thread.CurrentThread.ManagedThreadId);
await Task.Delay(1000);
Console.WriteLine("3.异步执行后ThreaID：" + Thread.CurrentThread.ManagedThreadId);
}
执行结果：
同样的代码在winform中执行：
winform程序：
private void button1_Click(object sender, EventArgs e)
{
Console.WriteLine("1.同步ThreaID：" + Thread.CurrentThread.ManagedThreadId);
RunTimeAsync();
Console.WriteLine("4.异步执行完毕ThreaID：" + Thread.CurrentThread.ManagedThreadId);
Thread.Sleep(2000);
Console.WriteLine("5.同步延迟完毕ThreaID：" + Thread.CurrentThread.ManagedThreadId);
}
public async static Task RunTimeAsync()
{
Console.WriteLine("2.进入异步ThreaID：" + Thread.CurrentThread.ManagedThreadId);
await Task.Delay(1000);
Console.WriteLine("3.异步执行后ThreaID：" + Thread.CurrentThread.ManagedThreadId);
}
执行结果：
前后代码执行结果对比后发现，
1.线程数量，winfrom都是在一个线程里执行，控制台程序是两个线程执行，其中异步操作在新的线程里。
2.执行顺序，winform先执行click中同步操作，再执行异步操作，控制台却相反。
所以await这个关键字到底对异步操作动了什么手脚呢？
在查了一些相关资料后有两个词比较高频：SynchronizationContext 和TaskScheduler,执行代码时,Task不会自己执行,而是将执行内容放到SynchronizationContext 和TaskScheduler执行。
其实await Task.Delay（1000）或者await AsyncFun()（异步操作）等价于以下代码：
Task t = AsyncFun();
var currentContext = SynchronizationContext.Current;
if (null == currentContext)
{
t.ContinueWith((te) => { Run(); }, TaskScheduler.Current);
}
else
{
t.ContinueWith((te) => { Run(); }, TaskScheduler.FromCurrentSynchronizationContext())
}
如果SynchronizationContext为null就在TaskScheduler中执行，如果不为null则在FromCurrentSynchronizationContext中执行。
先了解一下TaskScheduler——–CSDN中注解是：表示一个处理将任务排队到线程中的低级工作的对象。
看一下TaskScheduler的元数据：
TaskScheduler其实就是将Task放到Threadpool执行，通过入队出队的方式排列执行顺序。
根据等价代码我们要区分一下控制台程序与winfrom程序异步操作的执行方式，
我们执行这条代码：var currentContext = SynchronizationContext.Current;
在控制台程序中currentContext 为null
在winform中currentContext 为System.Windows.Forms.WindowsFormsSynchronizationContext
那么控制台程序是在TaskScheduler.Current所在的线程池执行，我们看到控制台的await 异步操作在其他线程中执行一致。
下面分析一下winform的执行方式：
WindowsFormsSynchronizationContext继承自SynchronizationContext，
https://www.cnblogs.com/lzxianren/p/SynchronizationContext.html 参考了这篇文章
里面有两点：
public virtual void Send(SendOrPostCallback d, Object state)
{
d(state);
}
public virtual void Post(SendOrPostCallback d, Object state)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
}
在UI线程执行是，会将执行的任务用Send方法放到消息泵中，当时UI中同步执行的操作执行完毕，再执行详细泵中的数据，这就是为什么UI中只在一个线程中执行，而且总是在最后执行。
总结：用 await 语句等待一个任务完成，当该方法在 await 处暂停时，就可以捕捉上下文（context）。如果当前 SynchronizationContext 不为空，这个上下文就是当前SynchronizationContext；如果当前 SynchronizationContext 为空，则这个上下文为当前askScheduler，该方法会在这个上下文中继续运行。一般来说，运行 UI 线程时采用 UI 上下文，处理 ASP.NET 请求时采用 ASP.NET 请求上下文，其他很多情况下则采用线程池上下文。因此，在上面的代码中，每个同步程序块会试图在原始的上下文中恢复运行。如果在 UI线程中调用 ，这个方法的每个同步程序块都将在此 UI 线程上运行。但是，如果在线程池线程中调用，每个同步程序块将在线程池线程上运行。
控制台程序以及类库是在TaskScheduler中调度执行，UI程序则是在SynchronizationContext调度执行。
参考了：https://blog.csdn.net/wlk1229/article/details/81287374
