个人随笔
技术改变世界

C# async await 异步编程

async await异步编程的这边文章转载自作者:

这个文章写的非常通俗易懂,很不错。

 

进入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 = 0; i < 3; i++) 
    { 
         Console.WriteLine("Working..{0}",i); 
         await  Task.Delay(1000);//以前我们用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的部分

async await

程序员就是喜欢折腾,明明一句话能搞定的 偏偏写这么多行。

我们现在看到的就是,程序进入一个又一个方法后,输出个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 = 0; i < 3; i++) 
    { 
        await  Task.Delay(1000); 
        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 = 0; i < 3; i++) 
    { 
        await  Task.Delay(1000); 
        Console.WriteLine("Working..{0}",i); 
    } 
}

程序写出,编译器没有错误,运行->

async await 2

一个异步方法调用后将返回到它之前,它必须是完整的,并且线程依旧是活着的。

而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介绍了三种可能的返回类型:TaskTask<T>void

但是async方法的固有返回类型只有TaskTask<T>,所以尽量避免使用async void

并不是说它没用,存在即有用,async void用于支持异步事件处理程序,什么意思?(比如我例子里面那些无聊的输出呀..)或者就如上述提到的:

private async void button1_Click(object sender, EventArgs e)
{
    //….
}

有兴趣的同学可以去找找(async void怎么支持异步事件处理程序)

 

async await 异常处理介绍

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 voidTask 异常,看看两种异常的结果,看看测试用例。

首先是 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(1000); 
     throw new OutOfMemoryException(); 
 } 

 static void AsyncVoidException() 
 { 
     try 
     { 
         Task t = ThrowExceptionAsync(); 
         t.Wait(); 
     } 
     catch (Exception) 
     {
         throw; 
     } 
 }

预料之中啊:

async await 3

通过比较,大家不难看出哪个实用哪个不实用。

对于async void 我还要闲扯一些缺点,让大家认识到,用这个的确要有扎实的根底。

很显然async void 这个方法未提供一种简单的方式,去通知向调用它的代码发出回馈信息,通知是否已经执行完成。

启动async void方法不难,但你要确定它何时结束也是不易。

async void 方法会在启动和结束时去通知SynchronizationContext。简单的说,要测试async void 不是件简单的事,但有心去了解,SynchronizationContext或许就不这么难了,它完全可以用来检测async void 的异常。

说了这么多缺点,该突出些重点了:

建议多使用async Task 而不是async void。

async Task方法便于实现错误处理、可组合性和可测试性。

不过对于异步事件处理程序不行,这类处理程序必须返回void。

 

async await 死锁

异步——我们既陌生又熟悉的朋友——死锁

对于异步编程不了解的程序员,或许常干这种事:

混合使用同步和异步代码,他们仅仅转换一小部分应用程序,提出一段代码块,然后用同步API包装它,这么做方便隔离,同步分为一块,异步分为另一块,这么做的后果是,他们常常会遇到和死锁有关的问题。

我之前一直用控制台来写异步,大家应该觉得,异步Task就是这么用的吧?没有丝毫阻噻,都是理所当然的按计划运行和结束。

嗯,来个简单的例子,看看吧:

这是我的WPF项目的测试例子:

 int i = 0; 
 private void button_1_Click(object sender, RoutedEventArgs e) 
 { 
     textBox.Text += "你点击了按钮 "+i++.ToString()+"\t\n"; 
     Task t = DelayAsync(); 
     t.Wait(); 
 } 

 private static async Task DelayAsync() 
 {
     MessageBox.Show("异步完成"); 
     await Task.Delay(1000); 
 }

 

为了便于比较,看看控制台对应的代码:

 static void Main(string[] args) 
 { 
     Task t = DelayAsync(); 
     t.Wait(); 
 } 

 private static async Task DelayAsync() 
 { 
     await Task.Delay(1000); 
     Console.WriteLine("Complet"); 
 }

控制台程序没有丝毫问题,我保证。

现在来注意一下WPF代码,当我button点击之后,应该出现的效果是:

async await 4

看图片的效果不错。

接着你关掉提示框,你会发现 ,这个窗口点什么都没用了。关闭的不行,我确定我说的没错。

想关掉 就去任务管理器里面结束进程吧~~~

这是一个很简单的死锁示例,我想说的是差不多的代码,在不同的应用程序里面会有不一样的效果,这就是它灵活和复杂的地方。

这种死锁的根本原因是await处理上下文的方式

默认情况下,等待未完成的Task时,会捕获当前“上下文”,在Task完成时使用该上下文回复方法的执行(这里的“上下文”指的是当前TaskScheduler任务调度器)

值得注意的就是下面这几句代码:

t.Wait();

private static async Task DelayAsync() 
{
    MessageBox.Show("异步完成"); 
    await Task.Delay(1000); 
}

请确定你记住他的结构了,现在我来细讲原理。

Task t 有一个线程块在等待着 DelayAsync 的执行完成。

而 async Task DelayAsunc 在另一个线程块中执行。

也就是说,在 MessageBox.Show(“异步完成”); 这个方法完成后,await 会继续获取 async 余下的部分,它还能捕获到接下来的代码吗?

async的线程已经被t线程在等待了,t在等待 async的完成,而运行Task.Delay(1000)后,await就会尝试在捕获的上下文中执行async方法的剩余部分,async被占用了,它就在等待t。然后它们就相互等待对方,从而导致死锁,锁上就不听使唤了~~~用个图来形容一下这个场景

async await 5

说重点了。

为什么控制带应用程序不会形成这种死锁?

它们具有线程池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 await 6

出这个问题是我在事件前加了一个async声明。

添加异步标识后,ConfigureAwait就不能夺取原始上下文了,在这种情况下,事件处理程序是不能放弃原始上下文。

大家要知道的是:

每个async方法都有自己的上下文,如果一个async方法去调用另一个async方法,则其上下文是相互独立的。

为什么这么说?独立是什么意思?我拿个例子说明吧:

 private async void button_1_Click(object sender, RoutedEventArgs e) 
 { 
     Task t = DelayAsunc(); 
     t.ConfigureAwait(false);//Error 
 } 

 private static async Task DelayAsunc() 
 { 
     MessageBox.Show("异步完成"); 
     await Task.Delay(1000); 
 }

因为是独立的,所以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(1000).ConfigureAwait(continueOnCapturedContext:false); 
 }

每个async 都有自己的上下文,因为独立所以它们之间的调用是可行的。

修改后的例子,将事件处理程序的所有核心逻辑都放在一个可测试且无上下文的async Task方法中,仅在上下文相关事件处理程序中保存最少量的代码。

至此,已经总结了3条异步编程指导原则,我一起集合一下这3条,方便查阅。

async await 7

我们都忽略了一个问题,可能大家从来都没想过,

我们对代码操作,一直都是一种异步编程。而我们的代码都运行在一个操作系统线程!

来看些最简单的应用,帮助大家能快速的熟悉,并使用,才是我想要达到的目的,你可以不熟练,可以不会用,但是,你可以去主动接近它,适应它,熟悉它,直到完全活用。

异步编程是重要和有用的。

下面来做些基本功的普及。我先前提到UI线程,什么是UI线程?

我们都碰见过程序假死状态,冻结,无响应。

微软提供了UI框架,使得你可以使用C#操作所有UI线程,虽说是UI框架,我想大家都听过,它们包括:WinForms,WPF,Silverlight。

UI线程是唯一的一个可以控制一个特定窗口的线程,也是唯一的线程能检测用户的操作,并对它们做出响应。

这次介绍就到这了。

 

总结

这篇文章基本上详细介绍了async await的异步编程经验,在此感谢作者 肅 的分享。

他的博客地址:http://www.cnblogs.com/x-xk/

转载请注明出处王旭博客 » C# async await 异步编程

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址