异步编程 In .NET

驴友qq群,tolove第3季,喋血宣德

　在之前写的一篇关于async和await的前世今生的文章之后，大家似乎在async和await提高网站处理能力方面还有一些疑问，博客园本身也做了不少的尝试。今天我们再来回答一下这个问题，同时我们会做一个async和await在winform中的尝试，并且对比在4.5之前的异步模式apm/eap和async/await的区别，最后我们还会探讨在不同线程之间交互的问题。

 

　　iis存在着处理能力的问题，但是winform却是ui响应的问题，并且winform的ui线程至始至终都是同一个，所以两者之间有一定的区别。有人会问，现在还有人写winform吗？好吧，它确是一个比较老的东西呢，不如wpf炫，技术也不如wpf先进，但是从架构层面来讲，不管是web，还是winform，又或是wpf，mobile，这些都只是表现层，不是么？现在的大型一般桌面客户端，web端，手机，平板端都会涉及，这也是为什么会有应用层，服务层的存在。我们在这谈论的asp.net mvc，winform，wfp，android/ios/wp 都是表现层，在表现层我们应该只处理与“表现”相关的逻辑，任何与业务相关的逻辑应该都是放在下层处理的。关于架构的问题，我们后面再慢慢深入，另外别说我没有提示您，我们今天还会看到.net中另一个已经老去的技术web service。

 

　　还得提示您，文章内容有点长，涉及的知识点比较多，所以，我推荐：”先顶后看“ ，先顶后看是21世纪看长篇的首选之道，是良好沟通的开端，想知道是什么会让你与众不同吗？想知道为什么上海今天会下这么大的雨么？请记住先顶后看，你顶的不是我的文章，而是我们冒着大雨还要去上班的可贵精神！先顶后看，你值得拥有！

 

 

　　首先响应能力并不完全是说我们程序性能的问题，有时候可能你的程序没有任何问题，而且精心经过优化，可是响应能力还是没有上去，网站性能分析是一个复杂的活，有时候只能靠经验和不断的尝试才能达到比较好的效果。当然我们今天讨论的主要是iis的处理能力，或者也可能说是iis的性能，但绝非代码本身的性能。即使async/await能够提高iis的处理能力，但是对于用户来说整个页面从发起请求到页面渲染完成的这些时间，是不会因为我们加了async/await之后产生多大变化的。

 

　　另外异步的asp.net并非只有async/await才可以做的，asp.net在web form时代就已经有异步page了，包括asp.net mvc不是也有异步的controller么？async/await 很新，很酷，但是它也只是在原有一技术基础上做了一些改进，让程序员们写起异步代码来更容易了。大家常说微软喜欢新瓶装旧酒，至少我们要看到这个新瓶给我们带来了什么，不管是任何产品，都不可能一开始就很完美，所以不断的迭代更新，也可以说是一种正确做事的方式。

 

asp.net并行处理的步骤

 　　asp.net是如何在iis中工作的一文已经很详细的介绍了一个请求是如何从客户端到服务器的http.sys最后进入clr进行处理的（强烈建议不了解这一块的同学先看这篇文章，有助于你理解本小节），但是所有的步骤都是基于一个线程的假设下进行的。iis本身就是一个多线程的工作环境，如果我们从多线程的视角来看会发生什么变化呢？我们首先来看一下下面这张图。注意：我们下面的步骤是建立在iis7.0以后的集成模式基础之上的。（注：下面这张图在dudu的提醒之后，重新做了一些搜索工作，做了一些改动，w3dt这一步来自于博客园团队对问题的不断探索，详情可以点这里）

 

 

 

　　我们再来梳理一下上面的步骤：

 

所有的请求最开始是由http.sys接收的，http.sys内部有一个队列维护着这些请求，这个队列的request的数量大于一定数量（默认是1000）的时候，http.sys就会直接返回503状态（服务器忙），这是我们的第一个阀门。性能计数指标：“http service request queues\currentqueuesize”

由w3dt负责把请求从http.sys 的队列中放到一个对应端口的队列中，据非官方资料显示该队列长度为能为20（该队列是非公开的，没有文档，所以也没有性能计数器）。

iis 的io线程从上一步的队列中获取请求，如果是需要asp.net处理的，就会转交给clr 线程池的worker 线程，iis的io线程继续返回重复做该步骤。clr 线程池的worker线程数量是第二个阀门。

当clr中正在被处理的请求数据大于一定值（最大并行处理请求数量，.net4以后默认是5000）的时候，从io线程过来的请求就不会直接交给worker线程，而是放到一个进程池级别的一个队列了，等到这个数量小于临界值的时候，才会把它再次交给worker线程去处理。这是我们的第三个阀门。

上一步中说到的那个进程池级别的队列有一个长度的限制，可以通过web.config里面的processmodel/requestqueuelimit来设置。这可以说也是一个阀门。当正在处理的数量大于所允许的最大并行处理请求数量的时候，我们就会得到503了。可以通过性能计数指标：“asp.net v4.0.30319\requests queued” 来查看该队列的长度。

 哪些因素会控制我们的响应能力

　　从上面我们提到了几大阀门中，我们可以得出下面的几个数字控制或者说影响着我们的响应能力。

 

http.sys队列的长度

clr线程池最大worker线程数量

最大并行处理请求数量

进程池级别队列所允许的长度

http.sys队列的长度

 

　　这个我觉得不需要额外解释，默认值是1000。这个值取决于我们我们后面iis io线程和worker线程的处理速度，如果它们两个都处理不了，这个数字再大也没有用。因为最后他们会被存储到进程池级别的队列中，所以只会造成内存的浪费。

 

最大worker线程数量

 

　　这个值是可以在web.config中进行配置的。

 

 

 

　　maxworkerthreads: clr中真实处理请求的最大worker线程数量

　　minworkerthreads:clr中真实处理请求的最小worker线程数量

 

　　minworkerthreads的默认值是1，合理的加大他们可以避免不必要的线程创建和销毁工作。

 

最大并行处理请求数量

 

　　进程池级别的队列给我们的clr一定的缓冲，这里面要注意的是，这个队列还没有进入到clr，所以它不会占用我们托管环境的任何资源，也就是把请求卡在了clr的外面。我们需要在net.config级别进行配置，我们可以在.net fraemwork的安装目录下找到它。一般是 c:\windows\microsoft.net\framework\v4.0.30319 如果你安装的是4.0的话。

 

 

 

　　maxconcurrentrequestpercpu: 每个cpu所允许的最大并行处理请求数量，当clr中worker线程正在处理的请求之和大于这个数时，从io线程过来的请求就会被放到我们进程池级别的队列中。

　　maxconcurrentthreadspercpu: 设置为0即禁用。

　　requestqueue: 进程池级别队列所允许的长度。　　

 

async和await 做了什么？

　　我们终于要切入正题了，拿asp.net mvc举例，如果不采用async的action，那么毫无疑问，它是在一个woker线程中执行的。当我们访问一些web service，或者读文件的时候，这个worker线程就会被阻塞。假设我们这个action执行时间一共是100ms，其它访问web service花了80ms，理想情况下一个worker线程一秒可以响应10个请求，假设我们的maxworkerthreads是10，那我们一秒内总是可响应请求就是100。如果说我们想把这个可响应请求数升到200怎么做呢？

 

　　有人会说，这还不简单，把maxworkerthreads调20不就行了么？ 其实我们做也没有什么 问题，确实是可以的，而且也确实能起到作用。那我们为什么还要大费周章的搞什么 async/await呢？搞得脑子都晕了？async/await给我们解决了什么问题？它可以在我们访问web service的时候把当前的worker线程放走，将它放回线程池，这样它就可以去处理其它的请求了。等到web service给我们返回结果了，会再到线程池中随机拿一个新的woker线程继续往下执行。也就是说我们减少了那一部分等待的时间，充份利用了线程。

 

　   我们来对比一下使用async/awit和不使用的情况，

 

　　不使用async/await： 20个woker线程1s可以处理200个请求。

 

　　那转换成总的时间的就是 20 * 1000ms =  20000ms，

　　其中等待的时间为 200 * 80ms = 16000ms。

　　也就是说使用async/await我们至少节约了16000ms的时间，这20个worker线程又会再去处理请求，即使按照每个请求100ms的处理时间我们还可以再增加160个请求。而且别忘了100ms是基于同步情况下，包括等待时间在内的基础上得到的，所以实际情况可能还要多，当然我们这里没有算上线程切换的时间，所以实际情况中是有一点差异的，但是应该不会很大，因为我们的线程都是基于线程池的操作。

　　所有结果是20个worker线程不使用异步的情况下，1s能自理200个请求，而使用异步的情况下可以处理360个请求，立马提升80%呀！采用异步之后，对于同样的请求数量，需要的worker线程数据会大大减少50%左右，一个线程至少会在堆上分配1m的内存，如果是1000个线程那就是1g的容量，虽然内存现在便宜，但是省着总归是好的嘛，而且更少的线程是可以减少线程池在维护线程时产生的cpu消耗的。另：dudu分享 clr1秒之内只能创建2个线程。

 

　　注意：以上数据并非真实测试数据，真实情况一个request的时间也并非100ms，花费在web service上的时间也并非80ms，仅仅是给大家一个思路:)，所以这里面用了async和await之后对响应能力有多大的提升和我们原来堵塞在这些io和网络上的时间是有很大的关系的。

 

几点建议

　　看到这里，不知道大家有没有得到点什么。首先第一点我们要知道的是async/await不是万能药，不们不能指望光写两个光键字就希望性能的提升。要记住，一个cpu在同一时间段内是只能执行一个线程的。所以这也是为什么async和await建议在io或者是网络操作的时候使用。我们的mvc站点访问wcf或者web service这种场景就非常的适合使用异步来操作。在上面的例子中80ms读取web service的时间，大部份时间都是不需要cpu操作的，这样cpu才可以被其它的线程利用，如果不是一个读取web service的操作，而是一个复杂计算的操作，那你就等着cpu爆表吧。

 

　　第二点是，除了程序中利用异步，我们上面讲到的关于iis的配置是很重要的，如果使用了异步，请记得把maxworkerthreads和maxconcurrentrequestpercpu的值调高试试。

 

 早期对web service的异步编程模式apm

 

　　讲完我们高大上的async/await之后，我们来看看这个技术很老，但是概念确依旧延续至今的web service。 我们这里所说的针对web service的异步编程模式不是指在服务器端的web service本身，而是指调用web service的客户端。大家知道对于web service，我们通过添加web service引用或者.net提供的生成工具就可以生成相应的代理类，可以让我们像调用本地代码一样访问web service，而所生成的代码类中对针对每一个web service方法生成3个对应的方法，比如说我们的方法名叫downloadcontent，除了这个方法之外还有begindownloadcontent和enddownloadcontent方法，而这两个就是我们今天要说的早期的异步编程模式apm(asynchronous programming model)。下面就来看看我们web service中的代码，注意我们现在的项目都是在.net framework3.5下实现的。

 

 pagecontent.asmx的代码

 

 

public class pagecontent : system.web.services.webservice

{

    [webmethod]

    public string downloadcontent(string url)

    {

        var client = new system.net.webclient();

        return client.downloadstring(url);

    }

}

　　注意我们web service中的downloadcontent方法调用的是webclient的同步方法，webclient也有异步方法即：downloadstringasync。但是大家要明白，不管服务器是同步还是异步，对于客户端来说调用了你这个web service都是一样的，就是得等你返回结果。

 

　　当然，我们也可以像mvc里面的代码一样，把我们的服务器端也写成异步的。那得到好处的是那个托管web service的服务器，它的处理能力得到提高，就像asp.net一样。如果我们用javascript去调用这个web service，那么ajax(asynchronous javascript + xml)就是我们客户端用到的异步编程技术。如果是其它的客户端呢？比如说一个cs的桌面程序？我们需要异步编程么？

 

当winform遇上web service

　　winform不像托管在iis的asp.net网站，会有一个线程池管理着多个线程来处理用户的请求，换个说法asp.net网站生来就是基于多线程的。但是，在winform中，如果我们不刻意使用多线程，那至始至终，都只有一个线程，称之为ui线程。也许在一些小型的系统中winform很少涉及到多线程，因为winform本身的优势就在它是独立运行在客户端的，在性能上和可操作性上都会有很大的优势。所以很多中小型的winform系统都是直接就访问了，并且基本上也只有数据的传输，什么图片资源那是很少的，所以等待的时间是很短的，基本不用费什么脑力去考虑什么3秒之内必须将页面显示到用户面前这种问题。

 

　　既然winform在性能上有这么大的优势，那它还需要异步吗？

 

　　我们上面说的是中小型的winform，如果是大型的系统呢？如果winform只是其它的很小一部分，就像我们文章开始说的还有很多其它成千上万个手机客户端，web客户端，平板客户端呢？如果客户端很多导致数据库撑不住怎么办？ 想在中间加一层缓存怎么办？

 

　　拿一个b2b的网站功能举例，用户可以通过网站下单，手机也可以下单，还可以通过电脑的桌面客户端下单。在下完单之后要完成交易，库存扣减，发送订单确认通知等等功能，而不管你的订单是通过哪个端完成的，这些功能我们都要去做，对吗？那我们就不能单独放在winform里面了，不然这些代码在其它的端里面又得全部全新再一一实现，同样的代码放在不同的地方那可是相当危险的，所以就有了我们后来的soa架构，把这些功能都抽成服务，每种类型的端都是调用服务就可以了。一是可以统一维护这些功能，二是可以很方便的做扩展，去更好的适应功能和架构上的扩展。比如说像下面这样的一个系统。

 

 

 

　　在上图中，web端虽然也是属于我们平常说的服务端（甚至是由多台服务器组成的web群集），但是对我们整个系统来说，它也只是一个端而已。对于一个端来说，它本身只处理和用户交互的问题，其余所有的功能，业务都会交给后来台处理。在我们上面的架构中，应用层都不会直接参加真正业务逻辑相关的处理，而是放到我们更下层数据层去做处理。那么应用层主要协助做一些与用户交互的一些功能，如果手机短信发送，邮件发送等等，并且可以根据优先级选择是放入队列中稍候处理还是直接调用功能服务立即处理。

 

　　在这样的一个系统中，我们的web服务器也好，winform端也好都将只是整个系统中的一个终端，它们主要的任何是用户和后面服务之间的一个桥梁。涉及到service的调用之后，为了给用户良好的用户体验，在winform端，我们自然就要考虑异步的问题。 

 

winform异步调用web service

　　有了像vs这样强大的工具为我们生成代理类，我们在写调用web service的代码时就可以像调用本地类库一样调用web service了，我们只需要添加一个web reference就可以了。

 

 

 

// form1.cs的代码

 

 

private void button1_click(object sender, eventargs e)

{

    var pagecontentservice = new localhost.pagecontent();

    pagecontentservice.begindownloadcontent(

        "http://jesse2013.cnblogs.com",

        new asynccallback(downloadcontentcallback),

        pagecontentservice);

}

 

private void downloadcontentcallback(iasyncresult result)

{

    var pagecontentservice = (localhost.pagecontent)result.asyncstate;

    var msg = pagecontentservice.enddownloadcontent(result);

    messagebox.show(msg);

}

　　代码非常的简单，在执行完pagecontentservice.begindownloadcontent之后，我们的主线程就返回了。在调用web service这段时间内我们的ui不会被阻塞，也不会出现“无法响应这种情况”，我们依然可以拖动窗体甚至做其它的事情。这就是apm的魔力，但是我们的callback究竟是在哪个线程中执行的呢？是线程池中的线程么？咋们接着往下看。

 

apm异步编程模式详解

 

线程问题

　　接下来我们就是更进一步的了解apm这种模式是如何工作的，但是首先我们要回答上面留下来的问题，这种异步的编程方式有没有为我们开启新的线程？让代码说话：

 

 

private void button1_click(object sender, eventargs e)

{

    trace.traceinformation("is current thread from thread pool? {0}", thread.currentthread.isthreadpoolthread ? "yes" : "no");

    trace.traceinformation("start calling web service on thread: {0}", thread.currentthread.managedthreadid);

    var pagecontentservice = new localhost.pagecontent();

    pagecontentservice.begindownloadcontent(

        "http://jesse2013.cnblogs.com",

        new asynccallback(downloadcontentcallback),

        pagecontentservice);

}

 

private void downloadcontentcallback(iasyncresult result)

{

    var pagecontentservice = (localhost.pagecontent)result.asyncstate;

    var msg = pagecontentservice.enddownloadcontent(result);

 

    trace.traceinformation("is current thread from thread pool? {0}" , thread.currentthread.isthreadpoolthread ? "yes" : "no");

    trace.traceinformation("end calling web service on thread: {0}, the result of the web service is: {1}",

        thread.currentthread.managedthreadid,

        msg);

}

　　我们在按钮点击的方法和callback方法中分别输出当前线程的id，以及他们是否属于线程池的线程，得到的结果如下：

 

　　desktop4.0.vshost.exe information: 0 : is current thread a background thread? no

　　desktop4.0.vshost.exe information: 0 : is current thread from thread pool? no

　　desktop4.0.vshost.exe information: 0 : start calling web service on thread: 9

　　desktop4.0.vshost.exe information: 0 : is current thread a background thread? yes

　　desktop4.0.vshost.exe information: 0 : is current thread from thread pool? yes

　　desktop4.0.vshost.exe information: 0 : end calling web service on thread: 14, the result of the web service is: <!doctype html>...

 

　　按钮点击的方法是由ui直接控制，很明显它不是一个线程池线程，也不是后台线程。而我们的callback却是在一个来自于线程池的后台线程执行的，答案揭晓了，可是这会给我们带来一个问题，我们上面讲了只有ui线程也可以去更新我们的ui控件，也就是说在callback中我们是不能更新ui控件的，那我们如何让更新ui让用户知道反馈呢？答案在后面接晓 :)，让我们先专注于把apm弄清楚。

 

从delegate开始

　　其实，apm在.net3.5以前都被广泛使用，在winform窗体控制中，在一个io操作的类库中等等！大家可以很容易的找到搭配了begin和end的方法，更重要的是只要是有代理的地方，我们都可以使用apm这种模式。我们来看一个很简单的例子：

 

delegate void eatasync(string food);

private void button2_click(object sender, eventargs e)

{

    var myasync = new eatasync(eat);

    trace.traceinformation("activate eating on thread: {0}", thread.currentthread.managedthreadid);

    myasync.begininvoke("icecream", new asynccallback(clean), myasync);

}

 

private void eat(string food)

{

    trace.traceinformation("i am eating.... on thread: {0}", thread.currentthread.managedthreadid);

}

 

private void clean(iasyncresult asyncresult)

{

    trace.traceinformation("i am done eating.... on thread: {0}", thread.currentthread.managedthreadid);

}

　　上面的代码中，我们通过把eat封装成一个委托，然后再调用该委托的begininvoke方法实现了异步的执行。也就是实际的eat方法不是在主线程中执行的，我们可以看输出的结果：

 

　　desktop4.0.vshost.exe information: 0 : activate eating on thread: 10

　　desktop4.0.vshost.exe information: 0 : i am eating.... on thread: 6

　　desktop4.0.vshost.exe information: 0 : i am done eating.... on thread: 6

 

　　clean是我们传进去的callback，该方法会在我们的eat方法执行完之后被调用，所以它会和我们eat方法在同一个线程中被调用。大家如果熟悉代理的话就会知道，代码实际上会被编译成一个类，而begininvoke和endinvoke方法正是编译器为我们自动加进去的方法，我们不用额外做任何事情，这在早期没有tpl和async/await之前（apm从.net1.0时代就有了），的确是一个不错的选择。

 

再次认识apm

了解了delegate实现的begininvoke和endinvoke之后，我们再来分析一下apm用到的那些对象。 拿我们web service的代理类来举例，它为我们生成了以下3个方法：

 

string downloadcontent(string url)： 同步方法

iasyncresult begindownloadcontent(string url, asynccallback callback, object asyncstate)： 异步开始方法

enddownloadcontent(iasyncresult asyncresult)：异步结束方法

　　在我们调用enddownloadcontent方法的时候，如果我们的web service调用还没有返回，那这个时候就会用阻塞的方式去拿结果。但是在我们传到begindownloadcontent中的callback被调用的时候，那操作一定是已经完成了，也就是说iasyncresult.iscompleted = true。而在apm异步编程模式中begin方法总是返回iasyncresult这个接口的实现。iasyncreuslt仅仅包含以下4个属性：

 

 

 

　　waithanlde通常作为同步对象的基类，并且可以利用它来阻塞线程，更多信息可以参考msdn 。 借助于iasyncresult的帮助，我们就可以通过以下几种方式去获取当前所执行操作的结果。

 

轮询

强制等待

完成通知

　　完成通知就是们在"winform异步调用webservice"那结中用到的方法，调完begin方法之后，主线程就算完成任务了。我们也不用监控该操作的执行情况，当该操作执行完之后，我们在begin方法中传进去的callback就会被调用了，我们可以在那个方法中调用end方法去获取结果。下面我们再简单说一下前面两种方式。

 

//轮询获取结果代码

 

var pagecontentservice = new localhost.pagecontent();

iasyncresult asyncresult = pagecontentservice.begindownloadcontent(

    "http://jesse2013.cnblogs.com",

    null,

    pagecontentservice);

 

while (!asyncresult.iscompleted)

{

    thread.sleep(100);

}

var content = pagecontentservice.enddownloadcontent(asyncresult);

 // 强制等待结果代码

 

 

var pagecontentservice = new localhost.pagecontent();

iasyncresult asyncresult = pagecontentservice.begindownloadcontent(

    "http://jesse2013.cnblogs.com",

    null,

    pagecontentservice);

 

// 也可以调用waitone()的无参版本，不限制强制等待时间

if (asyncresult.asyncwaithandle.waitone(2000))

{

    var content = pagecontentservice.enddownloadcontent(asyncresult);

}

else

{ 

    // 2s时间已经过了，但是还没有执行完   

}

eap(event-based asynchronous pattern)

 

　　eap是在.net2.0推出的另一种过渡的异步编程模型，也是在.net3.5以后microsoft支持的一种做法，为什么呢？ 如果大家建一个.net4.0或者更高版本的winform项目，再去添加web reference就会发现生成的代理类中已经没有begin和end方法了，记住在3.5的时候是两者共存的，你可以选择任意一种来使用。但是到了.net4.0以后，eap成为了你唯一的选择。（我没有尝试过手动生成代理类，有兴趣的同学可以尝试一下）让我们来看一下在.net4下，我们是如何异步调用web service的。

 

 

private void button1_click(object sender, eventargs e)

{

    var pagecontent = new localhost.pagecontent();

    pagecontent.downloadcontentasync("http://jesse2013.cnblogs.com");

    pagecontent.downloadcontentcompleted += pagecontent_downloadcontentcompleted;

}

 

private void pagecontent_downloadcontentcompleted(object sender, localhost.downloadcontentcompletedeventargs e)

{

    if (e.error == null)

    {

        textbox1.text = e.result;

    }

    else

    { 

        // 出错了

    }

}

线程问题

　　不知道大家还是否记得，在apm模式中，callback是执行在另一个线程中，不能随易的去更新ui。但是如果你仔细看一下上面的代码，我们的downloadcontentcompleted事件绑定的方法中直接就更新了ui，把返回的内容写到了一个文本框里面。通过同样的方法可以发现，在eap这种异步编程模式下，事件绑定的方法也是在调用的那个线程中执行的。也就是说解决了异步编程的时候ui交互的问题，而且是在同一个线程中执行。 看看下面的代码：

 

 

private void button1_click(object sender, eventargs e)

{

    trace.traceinformation("call downloadcontentasync on thread: {0}", thread.currentthread.managedthreadid);

    trace.traceinformation("is current from thread pool? : {0}", thread.currentthread.isthreadpoolthread ? "yes" : "no");

 

    var pagecontent = new localhost.pagecontent();

    pagecontent.downloadcontentasync("http://jesse2013.cnblogs.com");

    pagecontent.downloadcontentcompleted += pagecontent_downloadcontentcompleted;

}

 

private void pagecontent_downloadcontentcompleted(object sender, localhost.downloadcontentcompletedeventargs e)

{

    trace.traceinformation("completed downloadcontentasync on thread: {0}", thread.currentthread.managedthreadid);

    trace.traceinformation("is current from thread pool? : {0}", thread.currentthread.isthreadpoolthread ? "yes" : "no");

}

　　desktop4.vshost.exe information: 0 : call downloadcontentasync on thread: 10

　　desktop4.vshost.exe information: 0 : is current from thread pool? : no

　　desktop4.vshost.exe information: 0 : completed downloadcontentasync on thread: 10

　　desktop4.vshost.exe information: 0 : is current from thread pool? : no

 

async/await 给winfrom带来了什么

 

　　如果说async给asp.net带来的是处理能力的提高，那么在winform中给程序员带来的好处则是最大的。我们再也不用因为要实现异步写回调或者绑定事件了，省事了，可读性也提高了。不信你看下面我们将调用我们那个web service的代码在.net4.5下实现一下：

 

private async void button2_click(object sender, eventargs e)

{

    var pagecontent = new localhost.pagecontentsoapclient();

    var content = await pagecontent.downloadcontentasync("http://jesse2013.cnblogs.com");

 

    textbox1.text = content.body.downloadcontentresult;

}

　　简单的三行代码，像写同步代码一样写异步代码，我想也许这就是async/await的魔力吧。在await之后，ui线程就可以回去响应ui了，在上面的代码中我们是没有新线程产生的，和eap一样拿到结果直接就可以对ui操作了。

 

　　async/await似乎真的很好，但是如果我们await后面的代码执行在另外一个线程中会发生什么事情呢？

 

 

private async void button1_click(object sender, eventargs e)

{

    label1.text = "calculating sqrt of 5000000";

    button1.enabled = false;

    progressbar1.visible = true;

 

    double sqrt = await task<double>.run(() =>

    {

        double result = 0;

        for (int i = 0; i < 50000000; i++)

        {

            result += math.sqrt(i);

 

            progressbar1.maximum = 50000000;

            progressbar1.value = i;

        }

        return result;

    });

 

    progressbar1.visible = false;

    button1.enabled = true;

    label1.text = "the sqrt of 50000000 is " + sqrt;

}

　　我们在界面中放了一个progressbar，同时开一个线程去把从1到5000000的平方全部加起来，看起来是一个非常耗时的操作，于是我们用task.run开了一个新的线程去执行。（注：如果是纯运算的操作，多线程操作对性能没有多大帮助，我们这里主要是想给ui一个进度显示当前进行到哪一步了。）看起来没有什么问题，我们按f5运行吧！

　　bomb~

 

 

 

　　当执行到这里的时候，程序就崩溃了，告诉我们”无效操作，只能从创建porgressbar的线程访问它。“  这也是我们一开始提到的，在winform程序中，只有ui主线程才能对ui进行操作，其它的线程是没有权限的。接下来我们就来看看，如果在winform中实现非ui线程对ui控制的更新操作。 

 

不同线程之间通讯的问题

 

万能的invoke

　　winform中绝大多数的控件包括窗体在内都实现了invoke方法，可以传入一个delegate，这个delegate将会被拥有那个控制的线程所调用，从而避免了跨线程访问的问题。

 

 

trace.traceinformation("ui thread : {0}", thread.currentthread.managedthreadid);

double sqrt = await task<double>.run(() =>

{

    trace.traceinformation("run calculation on thread: {0}", thread.currentthread.managedthreadid);

    double result = 0;

    for (int i = 0; i < 50000000; i++)

    {

        result += math.sqrt(i);

        progressbar1.invoke(new action(() => {

            trace.traceinformation("update ui on thread: {0}", thread.currentthread.managedthreadid);

            progressbar1.maximum = 50000000;

            progressbar1.value = i;

        }));

    }

    return result;

});

　　desktop.vshost.exe information: 0 : ui thread : 9

　　desktop.vshost.exe information: 0 : run calculation on thread: 10

　　desktop.vshost.exe information: 0 : update ui on thread: 9

 

　　invoke方法比较简单，我们就不做过多的研究了，但是我们要考虑到一点，invoke是winform实现的ui跨线程沟通方式，wpf用的却是dispatcher，如果是在asp.net下跨线程之间的同步又怎么办呢。为了兼容各种技术平台下，跨线程同步的问题，microsoft在.net2.0的时候就引入了我们下面的这个对象。

 

synchronizationcontext上下文同步对象

为什么需要synchronizationcontext

 

　　就像我们在winform中遇到的问题一样，有时候我们需要在一个线程中传递一些数据或者做一些操作到另一个线程。但是在绝大多数情况下这是不允许的，出于安全因素的考虑，每一个线程都有它独立的内存空间和上下文。因此在.net2.0，微软推出了synchronizationcontext。

 

　　它主要的功能之一是为我们提供了一种将一些工作任务（delegate)以队列的方式存储在一个上下文对象中，然后把这些上下文对象关联到具体的线程上，当然有时候多个线程也可以关联到同一个synchronizationcontext对象。获取当前线程的同步上下文对象可以使用synchronizationcontext.current。同时它还为我们提供以下两个方法post和send，分别是以异步和同步的方法将我们上面说的工作任务放到我们synchronizationcontext的队列中。

 

synchronizationcontext示例

 

　　还是拿我们上面invoke中用到的例子举例，只是这次我们不直接调用控件的invoke方法去更新它，而是写了一个report的方法专门去更新ui。

 

 

double sqrt = await task<double>.run(() =>

{

    trace.traceinformation("current thread id is:{0}", thread.currentthread.managedthreadid);

 

    double result = 0;

    for (int i = 0; i < 50000000; i++)

    {

        result += math.sqrt(i);

        report(new tuple<int, int>(50000000, i));

    }

    return result;

});

　　每一次操作完之后我们调用一下report方法，把我们总共要算的数字，以及当前正在计算的数字传给它就可以了。接下来就看我们的report方法了。

 

 

private synchronizationcontext m_synchronizationcontext;

private datetime m_previoustime = datetime.now;

 

public form1()

{

    initializecomponent();

    // 在全局保存当前ui线程的synchronizationcontext对象

    m_synchronizationcontext = synchronizationcontext.current;

}

 

public void report(tuple<int, int> value)

{

    datetime now = datetime.now;

    if ((now - m_previoustime).milliseconds > 100)

    {

        m_synchronizationcontext.post((obj) =>

        {

            tuple<int, int> minmax = (tuple<int, int>)obj;

            progressbar1.maximum = minmax.item1;

            progressbar1.value = minmax.item2;

        }, value);

 

        m_previoustime = now;

    }

}

　　整个操作看起来要比inovke复杂一点，与invoke不同的是synchronizationcontext不需要对control的引用，而invoke必须先得有那个控件才能调用它的invoke方法对它进行操作。

 

小结

 

　　这篇博客内容有点长，不知道有多少人可以看到这里:)。最开始我只是想写写winfrom下异步调用web service的一些东西，在一开始这篇文件的题目是”异步编程在winform下的实践“，但是写着写着发现越来越多的迷团没有解开，其实都是一些老的技术以前没有接触和掌握好，所以所幸就一次性把他们都重新学习了一遍，与大家分享。

 

　　我们再来回顾一下文章所涉及到的一些重要的概念：

 

async/await 在asp.net做的最大贡献（早期asp.net的异步开发模式同样也有这样的贡献），是在访问数据库的时候、访问远程io的时候及时释放了当前的处理性程，可以让这些线程回到线程池中，从而实现可以去处理其它请求的功能。

异步的asp.net开发能够在处理能力上带来多大的提高，取决于我们的程序有多少时间是被阻塞的，也就是那些访问数据库和远程service的时间。

除了将代码改成异步，我们还需要在iis上做一些相对的配置来实现最优化。

不管是asp.net、winform还是mobile、还是平板，在大型系统中都只是一个与用户交互的端而已，所以不管你现在是做所谓的前端（javascript + css等)，还是所谓的后端(asp.net mvc、wcf、web api 等 )，又或者是比较时髦的移动端（ios也好，andrioid也罢，哪怕是不争气的wp），都只是整个大型系统中的零星一角而已。当然我并不是贬低这些端的价值，正是因为我们专注于不同，努力提高每一个端的用户体验，才能让这些大型系统有露脸的机会。我想说的是，在你对现在技术取得一定的成就之后，不要停止学习，因为整个软件架构体系中还有很多很多美妙的东西值得我们去发现。

apm和eap是在async/await之前的两种不同的异步编程模式。

apm如果不阻塞主线程，那么完成通知（回调）就会执行在另外一个线程中，从而给我们更新ui带来一定的问题。

eap的通知事件是在主线程中执行的，不会存在ui交互的问题。

最后，我们还学习了在winform下不同线程之间交互的问题，以及synchronizationcontext。

apm是.net下最早的异步编程方法，从.net1.0以来就有了。在.net2.0的时候，微软意识到了apm的回调函数中与ui交互的问题，于是带来了新的eap。apm与eap一直共存到.net3.5，在.net4.0的时候微软带来了tpl，也就是我们所熟知的task编程，而.net4.5就是我们大家知道的async/await了，可以看到.net一直在不停的进步，加上最近不断的和开源社区的合作，跨平台等特性的引入，我们有理由相信.net会越走越好。

　　最后，这篇文章从找资料学习到写出来，差不多花了我两个周未的时间，希望能够给需要的人或者感兴趣想要不断学习的人一点帮助（不管是往前学习，还是往后学习）最后还要感谢@田园里面的蟋蟀，在的时候给我找了一些错别字！

如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复