异步编程 In .NET(转载)
概述
在之前寫的一篇關于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世紀看長篇的首選之道，是良好溝通的開端，想知道是什么會讓你與眾不同嗎？想知道為什么上海今天會下這么大的雨么？請記住先頂后看，你頂的不是我的文章，而是我們冒著大雨還要去上班的可貴精神！先頂后看，你值得擁有！
目錄
- async/await如何提升IIS響應能力
- 并行處理的步驟
- 哪些因素影響了我們的響應能力
- async 和 await做了什么？
- 幾點建議
- 早期Web Service的異步模式APM
- 當WinForm遇到Web Service
- WinForm異步調用Web Service
- APM異步編程詳解
- 線程問題
- 從Delegate開始
- 再次認識APM
- EAP(Event-Based Asynchroronous Pattern)
- 線程問題
- async/await 給WinForm編程帶來了什么？
- 不同線程之間通訊的問題
- 萬能的InvokeI
- SynchronizationContex上下文同步對象
- 小結
- 引用 & 擴展閱讀
async/await如何提升IIS處理能力
首先響應能力并不完全是說我們程序性能的問題，有時候可能你的程序沒有任何問題，而且精心經過優化，可是響應能力還是沒有上去，網站性能分析是一個復雜的活，有時候只能靠經驗和不斷的嘗試才能達到比較好的效果。當然我們今天討論的主要是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隊列的長度
這個我覺得不需要額外解釋，默認值是1000。這個值取決于我們我們后面IIS IO線程和Worker線程的處理速度，如果它們兩個都處理不了，這個數字再大也沒有用。因為最后他們會被存儲到進程池級別的隊列中，所以只會造成內存的浪費。
最大Worker線程數量
這個值是可以在web.config中進行配置的。
maxWorkerThreads: CLR中真實處理請求的最大Worker線程數量
minWorkerThreads:CLR中真實處理請求的最小Worker線程數量
minWorkerThreads的默認值是1，合理的加大他們可以避免不必要的線程創建和銷毀工作。
最大并行處理請求數量
進程池級別的隊列給我們的CLR一定的緩沖，這里面要注意的是，這個隊列還沒有進入到CLR，所以它不會占用我們托管環境的任何資源，也就是把請求卡在了CLR的外面。我們需要在aspnet.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的代碼
?| 1 2 3 4 5 6 7 8 9 | 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的代碼
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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這種模式是如何工作的，但是首先我們要回答上面留下來的問題，這種異步的編程方式有沒有為我們開啟新的線程？讓代碼說話：
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | 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這種模式。我們來看一個很簡單的例子：
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 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個方法：
在我們調用EndDownloadContent方法的時候，如果我們的web service調用還沒有返回，那這個時候就會用阻塞的方式去拿結果。但是在我們傳到BeginDownloadContent中的callback被調用的時候，那操作一定是已經完成了，也就是說IAsyncResult.IsCompleted = true。而在APM異步編程模式中Begin方法總是返回IAsyncResult這個接口的實現。IAsyncReuslt僅僅包含以下4個屬性：
WaitHanlde通常作為同步對象的基類，并且可以利用它來阻塞線程，更多信息可以參考MSDN?。 借助于IAsyncResult的幫助，我們就可以通過以下幾種方式去獲取當前所執行操作的結果。
完成通知就是們在"WinForm異步調用WebService"那結中用到的方法，調完Begin方法之后，主線程就算完成任務了。我們也不用監控該操作的執行情況，當該操作執行完之后，我們在Begin方法中傳進去的callback就會被調用了，我們可以在那個方法中調用End方法去獲取結果。下面我們再簡單說一下前面兩種方式。
//輪詢獲取結果代碼
?| 1 2 3 4 5 6 7 8 9 10 11 | 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); |
?// 強制等待結果代碼
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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的。
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 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交互的問題，而且是在同一個線程中執行。 看看下面的代碼：
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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下實現一下：
?| 1 2 3 4 5 6 7 | 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后面的代碼執行在另外一個線程中會發生什么事情呢？
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | 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將會被擁有那個控制的線程所調用，從而避免了跨線程訪問的問題。
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | 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。
?| 1 2 3 4 5 6 7 8 9 10 11 12 | 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方法了。
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | 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下的實踐“，但是寫著寫著發現越來越多的迷團沒有解開，其實都是一些老的技術以前沒有接觸和掌握好，所以所幸就一次性把他們都重新學習了一遍，與大家分享。
我們再來回顧一下文章所涉及到的一些重要的概念：
最后，這篇文章從找資料學習到寫出來，差不多花了我兩個周未的時間，希望能夠給需要的人或者感興趣想要不斷學習的人一點幫助（不管是往前學習，還是往后學習）最后還要感謝@田園里面的蟋蟀，在閱讀的時候給我找了一些錯別字！
引用 & 擴展閱讀
http://blogs.msdn.com/b/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx
http://blog.stevensanderson.com/2008/04/05/improve-scalability-in-aspnet-mvc-using-asynchronous-requests
http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx?
http://blogs.msdn.com/b/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx
http://mohamadhalabi.com/2014/05/08/thread-throttling-in-iis-hosted-wcf-sync-vs-async/
Pro Asynchronous Programs with .NET by Richard Blewett and Andrew Clymer
轉載于:https://www.cnblogs.com/heroxiaohuihui/p/8056124.html
總結
以上是生活随笔為你收集整理的异步编程 In .NET(转载)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java基础进阶一：String源码和S
- 下一篇： js 闭包的用法详解