好久没写博客了，时隔5个月，奉上一篇精心准备的文章，希望大家能有所收获，对async 和 await 的理解有更深一层的理解。
async 和 await 有你不知道的秘密，微软会告诉你吗？
我用我自己的例子，去一步步诠释这个技术，看下去，你绝对会有收获。（渐进描述方式，愿适应所有层次的程序员）
从零开始， 控制台 Hello World：
什么？开玩笑吧？拿异步做Hello World？？
下面这个例子，输出什么？猜猜？
static void Main(string[] args)
{ Task t = example1();
} static async Task DoWork()
{ Console.WriteLine("Hello World!");
for (int i = ; i < ; i++)
{
Console.WriteLine("Working..{0}",i);
await Task.Delay();//以前我们用Thread.Sleep(1000)，这是它的替代方式。
}
}
static async Task example1()
{
await DoWork();
Console.WriteLine("First async Run End");
}
先不要看结果，来了解了解关键字吧，你确定你对async 和await了解？
async 其实就是一个标记，标记这个方法是异步方法。
当方法被标记为一个异步方法时，那么其方法中必须要使用await关键字。
重点在await，看字面意思是等待，等待方法执行完成。
它相当复杂，所以要细细讲述：
当编译器看到await关键字后，其后的方法都会被转移到一个单独的方法中去独立运行。独立运行？
是不是启动了另一个线程？
嗯。有这个想法的同学，很不错。就是这个答案。
我们来看看执行顺序。来验证一下我的这个说法，加深大家对await的理解。
首先从入口example1 进入：
——>碰见await Dowork()
——>此时主线程返回
——>进入DoWork
——>输出“Hello World！”
——>碰见await 关键字
——>独立执行线程返回
——>运行结束
我们看到3个输出语句，按照我的说法，最终会出几个？猜猜，动手验证答案，往往是最实在的，大部分程序都不会骗我们。如果对Task有不熟悉的，可以参看本人博客先前写Task的部分
程序员就是喜欢折腾，明明一句话能搞定的 偏偏写这么多行。
我们现在看到的就是，程序进入一个又一个方法后，输出个Hello World 就没了，没有结束，没有跳出。因为是异步，所以我们看不到后续的程序运行了。
我为什么要用控制台来演示这个程序？
这个疑问，让我做了下面的例子测试，一个深层次的问题，看不懂跳过没有丝毫影响。
分析一下这个例子：
static void Main(string[] args)
{
example2();
} static async void example2()
{
await DoWork();
Console.WriteLine("First async Run End");
} static async Task DoWork()
{
Console.WriteLine("Hello World!");
for (int i = ; i < ; i++)
{
await Task.Delay();
Console.WriteLine("Working..{0}",i);
}
}
运行丝毫问题，结果依旧是“Hello World ”，似乎更简单了。
注意，细节来了，example2 是void，Mani也是void，这个相同点，似乎让我们可以这么做：
static async void Main(string[] args)//给main加个 async
{
await DoWork();
}
static async Task DoWork()
{
Console.WriteLine("Hello World!");
for (int i = ; i < ; i++)
{
await Task.Delay();
Console.WriteLine("Working..{0}",i);
}
}
程序写出，编译器没有错误，运行->
一个异步方法调用后将返回到它之前，它必须是完整的，并且线程依旧是活着的。
而main正因为是控制台程序的入口，是主要的返回操作系统线程,所以编译器会提示入口点不能用async。
下面这种事件，我想大家不会陌生吧？WPF似乎都用这种异步事件写法：
private async void button1_Click(object sender, EventArgs e)
{ //…. }
以此列Main入口，类推在ASP.NET 的 Page_Load上也不要加async，因为异步Load事件内的其他异步都会一起执行，死锁？ 还有比这更烦人的事吗？winfrom WPF的Load事件目前没有测试过，现在的事件都有异步async了，胡乱用，错了你都不知道找谁。
好小细节提点到了，这个牵出的问题也就解决了。
有心急的同学可能就纳闷了，第一个例子，怎么才能看到先前的输出啊？
别急加上这句：
static void Main(string[] args)
{
Task t = example1(); t.Wait();//add
}
输出窗口就可以看到屏幕跳动连续输出了、、、
入门示例已经介绍完了，来细细品味一下下面的知识吧。
Async使用基础总结
到此Async介绍了三种可能的返回类型：Task，Task<T>和void。
但是async方法的固有返回类型只有Task和Task<T>,所以尽量避免使用async void。
并不是说它没用，存在即有用，async void用于支持异步事件处理程序，什么意思？(比如我例子里面那些无聊的输出呀..)或者就如上述提到的：
private async void button1_Click(object sender, EventArgs e)
{
//….
}
有兴趣的同学可以去找找（async void怎么支持异步事件处理程序）
异常处理介绍
async void 的方法具有不同的错误处理语义，因为在Task和Task<T>方法引发异常时，会捕获异常并将其置于Task对象上，方便我们查看错误信息，而async void，没有Task对象，没有对象直接导致异常都会直接在SynchronizationContext上引发(SynchronizationContext是async 和 await的实现底层哦)既然提到了SynchronizationContext，那么我在这说一句：
SynchronizationContext 对任何编程人员来说都是有益的。
无论是什么平台（ASP.NET、Windows 窗体、Windows Presentation Foundation (WPF)、Silverlight 或其他），所有 .NET 程序都包含 SynchronizationContext 概念。（建议好学的同学去找找）
扯远了，回到之前谈到的 async void 和 Task 异常，看看两种异常的结果，看看测试用例。
首先是 async void：
static void Main(string[] args)
{
AsyncVoidException();
}
static async void ThrowExceptionAsync()
{
throw new OutOfMemoryException();
}
static void AsyncVoidException()
{
try
{
ThrowExceptionAsync();
}
catch (Exception)
{ throw;
}
}
没有丝毫异常抛出，我先前说了，它会直接在SynchronizationContext抛出，但是执行异步的时候，它丝毫不管有没有异常，执行线程直接返回，异常直接被吞，所以根本无法捕获async void 的异常。我就不上图了，偷懒了。。
再看看async Task测试用例：
static void Main(string[] args)
{
AsyncVoidException();
}
static async Task ThrowExceptionAsync()
{
await Task.Delay();
throw new OutOfMemoryException();
}
static void AsyncVoidException()
{
try
{
Task t = ThrowExceptionAsync();
t.Wait();
}
catch (Exception)
{ throw;
}
}
预料之中啊：
通过比较，大家不难看出哪个实用哪个不实用。
对于async void 我还要闲扯一些缺点，让大家认识到，用这个的确要有扎实的根底。
很显然async void 这个方法未提供一种简单的方式，去通知向调用它的代码发出回馈信息，通知是否已经执行完成。
启动async void方法不难，但你要确定它何时结束也是不易。
async void 方法会在启动和结束时去通知SynchronizationContext。简单的说，要测试async void 不是件简单的事，但有心去了解，SynchronizationContext或许就不这么难了，它完全可以用来检测async void 的异常。
说了这么多缺点，该突出些重点了：
建议多使用async Task 而不是async void。
async Task方法便于实现错误处理、可组合性和可测试性。
不过对于异步事件处理程序不行，这类处理程序必须返回void。
异步——我们既陌生又熟悉的朋友——死锁！
对于异步编程不了解的程序员，或许常干这种事：
混合使用同步和异步代码，他们仅仅转换一小部分应用程序，提出一段代码块，然后用同步API包装它，这么做方便隔离，同步分为一块，异步分为另一块，这么做的后果是，他们常常会遇到和死锁有关的问题。
我之前一直用控制台来写异步，大家应该觉得，异步Task就是这么用的吧？没有丝毫阻噻，都是理所当然的按计划运行和结束。
嗯，来个简单的例子，看看吧：
这是我的WPF项目的测试例子：
1 int i = ;
private void button_1_Click(object sender, RoutedEventArgs e)
{ textBox.Text += "你点击了按钮 "+i++.ToString()+"\t\n";
Task t = DelayAsync();
t.Wait();
8 }
private static async Task DelayAsync()
{ MessageBox.Show("异步完成");
await Task.Delay();
14 }
为了便于比较，看看控制台对应的代码：
static void Main(string[] args)
{
Task t = DelayAsync();
t.Wait();
}
private static async Task DelayAsync()
{
await Task.Delay();
Console.WriteLine("Complet");
}
控制台程序没有丝毫问题，我保证。
现在来注意一下WPF代码，当我button点击之后,应该出现的效果是：
看图片的效果不错。
接着你关掉提示框，你会发现 ，这个窗口点什么都没用了。关闭的不行，我确定我说的没错。
想关掉 就去任务管理器里面结束进程吧~~~
这是一个很简单的死锁示例，我想说的是差不多的代码，在不同的应用程序里面会有不一样的效果，这就是它灵活和复杂的地方。
这种死锁的根本原因是await处理上下文的方式。
默认情况下，等待未完成的Task时，会捕获当前“上下文”，在Task完成时使用该上下文回复方法的执行（这里的“上下文”指的是当前TaskScheduler任务调度器）
值得注意的就是下面这几句代码：
t.Wait(); private static async Task DelayAsync()
{ MessageBox.Show("异步完成");
await Task.Delay();
}
请确定你记住他的结构了，现在我来细讲原理。
Task t 有一个线程块在等待着 DelayAsync 的执行完成。
而 async Task DelayAsunc 在另一个线程块中执行。
也就是说，在 MessageBox.Show("异步完成"); 这个方法完成后，await 会继续获取 async 余下的部分，它还能捕获到接下来的代码吗？
async的线程已经被t线程在等待了，t在等待 async的完成，而运行Task.Delay(1000)后，await就会尝试在捕获的上下文中执行async方法的剩余部分，async被占用了，它就在等待t。然后它们就相互等待对方，从而导致死锁，锁上就不听使唤了~~~用个图来形容一下这个场景
说重点了。
为什么控制带应用程序不会形成这种死锁？
它们具有线程池SynchronizationContext（同步上下文），而不是每次执行一个线程块区的SynchronizationContext，以此当await完成时，它会在线程池上安排async方法的剩余部分。所以各位，在控制台写好的异步程序，移动到别的应用程序中就可能会发生死锁。
好，现在来解决这个WPF的异步错误，我想这应该会引起大家兴趣，解决问题是程序员最喜欢的活。
改Wait()为ConfigureAwait(false)像这样：
Task t = DelayAsync(); t.ConfigureAwait(continueOnCapturedContext：false);//这个写法复杂了点，但从可读性角度来说是不错的，你这么写t.ConfigureAwait(false)当然也没问题
什么是ConfigureAwait？
官方解释：试图继续回夺取的原始上下文，则为 true，否则为 false。
不好理解，我来详细解释下，这个方法是很有用的，它可以实现少量并行性：
使得某些异步代码可以并行运行，而不是一个个去执行，进行零碎的线程块工作，提高性能。
另一方面才是重点，它可以避免死锁。
Wait造成的相互等待，在用这个方法的时候，就能顺利完成，如意料之中自然。当然还有指导意见要说的，如果在方法中的某处使用ConfigureAwait，则建议对该方法中，此后每个await都使用它。
说到这，只怕有些同学觉得，能避免死锁，这么好！以后就用ConfigureAwait就行了，不用什么await了。
没有一种指导方式是让程序员盲目使用的，ConfigureAwait这个方法，在需要上下文的代码中是用不了的。看不懂？没关系，接着看。
await运行的是一种原始上下文，就比如这样：
static async Task example1()
{
await DoWork();
Console.WriteLine("First async Run End");
}
一个async对应一个await ，它们本身是一个整体，我们称它为原始上下文。
ConfigureAwait而它有可能就不是原始上下文，因为它的作用是试图夺回原始上下文。用的时候VS2012会帮我们自动标识出来：
出这个问题是我在事件前加了一个async声明。
添加异步标识后，ConfigureAwait就不能夺取原始上下文了，在这种情况下，事件处理程序是不能放弃原始上下文。
大家要知道的是：
每个async方法都有自己的上下文，如果一个async方法去调用另一个async方法，则其上下文是相互独立的。
为什么这么说？独立是什么意思？我拿个例子说明吧：
private async void button_1_Click(object sender, RoutedEventArgs e)
2 {
Task t = DelayAsunc(); t.ConfigureAwait(false);//Error }
8 private static async Task DelayAsunc()
{
MessageBox.Show("异步完成");
await Task.Delay();
12 }
因为是独立的，所以ConfigureAwait不能夺取原始上下文，错误就如上那个图。
修改一下：
private async void button_1_Click(object sender, RoutedEventArgs e)
{
Task t = DelayAsunc(); t.Wait();
}
private static async Task DelayAsunc()
{
MessageBox.Show("异步完成");
await Task.Delay().ConfigureAwait(continueOnCapturedContext:false);
}
每个async 都有自己的上下文，因为独立所以它们之间的调用是可行的。
修改后的例子，将事件处理程序的所有核心逻辑都放在一个可测试且无上下文的async Task方法中，仅在上下文相关事件处理程序中保存最少量的代码。
至此，已经总结了3条异步编程指导原则，我一起集合一下这3条，方便查阅。
我们都忽略了一个问题，可能大家从来都没想过，
我们对代码操作，一直都是一种异步编程。而我们的代码都运行在一个操作系统线程！
来看些最简单的应用，帮助大家能快速的熟悉，并使用，才是我想要达到的目的，你可以不熟练，可以不会用，但是，你可以去主动接近它，适应它，熟悉它，直到完全活用。
异步编程是重要和有用的。
下面来做些基本功的普及。我先前提到UI线程，什么是UI线程？
我们都碰见过程序假死状态，冻结，无响应。
微软提供了UI框架，使得你可以使用C#操作所有UI线程，虽说是UI框架，我想大家都听过，它们包括：WinForms，WPF，Silverlight。
UI线程是唯一的一个可以控制一个特定窗口的线程，也是唯一的线程能检测用户的操作，并对它们做出响应。
这次介绍就到这了。