.NET中的異步編程（二）：傳統(tǒng)的異步編程
上一篇文章中，我們討論了為什么需要異步編程，異步編程能給我們帶來哪些好處。這篇文章是要介紹傳統(tǒng)的一步編程Async CTP。
如何實現(xiàn)異步
對于很多人來說，異步就是使用后臺線程運行耗時的操作。在有些時候這是對的，而在我們?nèi)粘４蟛糠謭鼍爸袇s不對。
比如現(xiàn)在我們有這么一個需求：使用HttpWebRequest請求某個指定URI的內(nèi)容，然后輸出在界面上的文本域中。同步代碼很容易編寫：
- 1: private void btnDownload_Click(object sender,EventArgs e)
- 2: {
- 3: var request = HttpWebRequest.Create("http://www.sina.com.cn");
- 4: var response = request.GetResponse();
- 5: var stream = response.GetResponseStream();
- 6: using(StreamReader reader = new StreamReader(stream))
- 7: {
- 8: var content = reader.ReadToEnd();
- 9: this.txtContent.Text = content;
- 10: }
- 11: }
是吧，很簡單。但是正如上一篇文章所說，這個簡短的程序體驗會非常差。特別是在URI所指向的資源非常大，網(wǎng)絡(luò)非常慢的情況下，在點擊下載按鈕到獲得結(jié)果這段時間界面會假死。
哦，這個時候你想起了異步。回憶上篇文章的示意圖。我們發(fā)現(xiàn)只要我們將耗時的操作放到另外一個線程上執(zhí)行就可以了，這樣我們的UI線程可以繼續(xù)響應(yīng)用戶的操作。
使用獨立的線程實現(xiàn)異步
如是你寫下了下面的代碼：
- 1: private void btnDownload_Click(object sender,EventArgs e)
- 2: {
- 3: var downloadThread = new Thread(Download);
- 4: downloadThread.Start();
- 5: }
- 6:
- 7: private void Download()
- 8: {
- 9: var request = HttpWebRequest.Create("http://www.sina.com.cn");
- 10: var response = request.GetResponse();
- 11: var stream = response.GetResponseStream();
- 12: using(StreamReader reader = new StreamReader(stream))
- 13: {
- 14: var content = reader.ReadToEnd();
- 15: this.txtContent.Text = content;
- 16: }
- 17: }
然后，F(xiàn)5運行。很不幸，這里出現(xiàn)了異常：我們不能在一個非UI線程上更新UI的屬性，我們暫時忽略這個異常（在release模式下是不會出現(xiàn)的，但這是不推薦的做法）。
哦，你寫完上面的代碼后發(fā)現(xiàn)UI不再阻塞了。心里想，異步也不過如此嘛。過了一會兒你突然想起，你好像在哪本書里看到過說盡量不要自己聲明Thread，而應(yīng)用使用線程池。如是你搜索了一下MSDN，將上面的代碼改成下面這個樣子：
- 1: private void btnDownload_Click(object sender,EventArgs e)
- 2: {
- 3: ThreadPool.QueueUserWorkItem(Download);
- 4: }
- 5:
- 6: private void Download()
- 7: {
- 8: var request = HttpWebRequest.Create("http://www.sina.com.cn");
- 9: var response = request.GetResponse();
- 10: var stream = response.GetResponseStream();
- 11: using(StreamReader reader = new StreamReader(stream))
- 12: {
- 13: var content = reader.ReadToEnd();
- 14: this.txtContent.Text = content;
- 15: }
- 16: }
嗯，很容易完成了。你都有點佩服自己了，這么短的時間居然連線程池這么“高級的技術(shù)”都給使用上了。就在你沾沾自喜的時候，你的一個同事走過來說：你這種實現(xiàn)方式是非常低效的，這里要進(jìn)行的耗時操作屬于IO操作，不是計算密集型，可以不分配線程給它（雖然不算準(zhǔn)確，但如果不深究的話就這么認(rèn)為吧）。
你的同事說的是對的。對于IO操作（比如讀寫磁盤，網(wǎng)絡(luò)傳輸，數(shù)據(jù)庫查詢等），我們是不需要占用一個thread來執(zhí)行的。現(xiàn)代的磁盤等設(shè)備，都可以與CPU同時工作，在磁盤尋道讀取這段時間CPU可以干其他的事情，當(dāng)讀取完畢之后通過中斷再讓CPU參與進(jìn)來。所以上面的代碼，雖然構(gòu)建了響應(yīng)靈敏的界面，但是卻創(chuàng)建了一個什么也不干的線程（當(dāng)進(jìn)行網(wǎng)絡(luò)請求這段時間內(nèi)，該線程會被一直阻塞）。所以，如果你要進(jìn)行異步時首先要考慮，耗時的操作屬于計算密集型還是IO密集型，不同的操作需要采用不同的策略。對于計算密集型的操作你是可以采用上面的方法的：比如你要進(jìn)行很復(fù)雜的方程的求解。是采用專門的線程還是使用線程池，也要看你的操作的關(guān)鍵程度。
這個時候你又在思考，不讓我使用線程，又要讓我實現(xiàn)異步。這該怎么辦呢？微軟早就幫你想到了這點，在.NET Framework中，幾乎所有進(jìn)行IO操作的方法幾乎都提供了同步版本和異步版本，而且微軟為了簡化異步的使用難度還定義了兩種異步編程模式：
Classic Async Pattern
這種方式就是提供兩個方法實現(xiàn)異步編程：比如System.IO.Stream的Read方法：
public int Read(byte[] buffer,int offset,int count);
它還提供了兩個方法實現(xiàn)異步讀取：
public IAsyncResult BeginRead(byte[] buffer, int offset,int count,AsyncCallback callback);
public int EndRead(IAsyncResult asyncResult);
以Begin開頭的方法發(fā)起異步操作，Begin開頭的方法里還會接收一個AsyncCallback類型的回調(diào)，該方法會在異步操作完成后執(zhí)行。然后我們可以通過調(diào)用EndRead獲得異步操作的結(jié)果。關(guān)于這種模式更詳細(xì)的細(xì)節(jié)我不在這里多闡述，感興趣的同學(xué)可以閱讀《CLR via C#》26、27章，以及《.NET設(shè)計規(guī)范》里對異步模式的描述。在這里我會使用這種模式重新實現(xiàn)上面的代碼片段：
- 1: private static readonly int BUFFER_LENGTH = 1024;
- 2:
- 3: private void btnDownload_Click(object sender,EventArgs e)
- 4: {
- 5: var request = HttpWebRequest.Create("http://www.sina.com.cn");
- 6: request.BeginGetResponse((ar) => {
- 7: var response = request.EndRequest(ar);
- 8: var stream = response.GetResponseStream();
- 9: ReadHelper(stream,0);
- 10: },null);
- 11: }
- 12:
- 13: private void ReadHelper(Stream stream,int offset)
- 14: {
- 15: var buffer = new byte[BUFFER_LENGTH];
- 16: stream.BeginRead(buffer,offset,BUFFER_LENGTH,(ar) =>{
- 17: var actualRead = stream.EndRead(ar);
- 18:
- 19: if(actualRead == BUFFER_LENGTH)
- 20: {
- 21: var partialContent = Encoding.Default.GetString(buffer);
- 22: Update(partialContent);
- 23: ReadHelper(stream,offset+BUFFER_LENGTH);
- 24: }
- 25: else
- 26: {
- 27: var latestContent = Encoding.Default.GetString(buffer,0,actualRead);
- 28: Update(latestContent);
- 29: stream.Close();
- 30: }
- 31: },null);
- 32: }
- 33:
- 34: private void Update(string content)
- 35: {
- 36: this.BeginInvoke(new Action(()=>{this.txtContent.Text += content;}));
- 37: }
感謝lambda表達(dá)式，讓我少些了很多方法聲明，也少引入了很多實例成員。不過上面的代碼還是非常難以讀懂，原本簡簡單單的同步代碼被改寫成了分段式的，而且我們再也無法使用using了，所以需要顯示的寫stream.Close()。哦，我的代碼還沒有進(jìn)行異常處理，這令我非常頭痛。實際上要寫出一個健壯的異步代碼是非常困難的，而且非常難以調(diào)試。但是，上面的代碼不僅僅能創(chuàng)建響應(yīng)靈敏的界面，還能更高效的利用線程。在這種異步模式中，BeginXXX方法會返回一個IAsyncResult對象，在進(jìn)行異步編程時也非常有效。
除此之外，因為我們在這里不能使用while等循環(huán)，我們想要從stream里讀取完整的內(nèi)容并不是一件容易事兒，我們必須將很好的循環(huán)結(jié)果替換成遞歸調(diào)用：ReadHelper。
Event-based Async Pattern(EAP)
.NET Framework除了提供上面這種編程模式外，還提供了基于事件的異步編程模式。比如WebClient的很多方法就提供了異步版本，比如DownloadString方法。
同步版本：
public string DownloadString(string url);
異步版本：
public void DownloadStringAsync(string url);
public event DownloadStringCompleteEventHandler DownloadStringComplete;
（在這里請注意，這兩種異步編程模式以及未來要介紹的Async CTP中的TAP方法的命名，參數(shù)的傳遞都是有一定規(guī)則的，弄清楚這些規(guī)則在進(jìn)行異步編程時會事半功倍）
基于事件的異步模式我也不作過多闡述，同樣可以參考《CLR via C#》以及MSDN。基于事件的異步編程模式點相比上一種的優(yōu)點是實現(xiàn)了該模式的類一般從Component派生，所以可以獲得更好的設(shè)計器支持，但如此一來也會在性能上稍微差一點點。
尷尬
雖然微軟費盡心思，提出兩種異步編程的模式，讓我們編寫異步代碼能稍微輕松那么一點點；但不管是使用回調(diào)還是基于事件的異步模式，都會將順序的同步方式的代碼拆成兩個部分：一個部分發(fā)起異步操作，而另外一個部分獲得結(jié)果。當(dāng)有多個異步操作要進(jìn)行時（比如上面的代碼首先使用異步的方式獲得response，然后又使用異步的方式讀取stream中的內(nèi)容）就會回調(diào)里嵌套著另外一個異步調(diào)用，代碼更加混亂。而且方法打散之后，像using、for、while、常規(guī)的異常處理都變得難以進(jìn)行。代碼的可讀性也急劇降低，代碼又容易出錯，如是我們舍爾求其次，轉(zhuǎn)而去使用低效的同步版本。
不過作為.NET程序員我們是幸運的，因為.NET提供的一些特性讓我們可以開發(fā)一些類庫輔助異步開發(fā)，比如Jeffrey Richter的AsyncEnumerator，以及微軟的CCR。我們會在接下來的文章里討論這些第三方類庫的使用以及背后的原理。
最后還是套用Async CTP的程序經(jīng)理Lucian Wischik的那句話：異步并不意味著后臺線程結(jié)束本文。
參考文獻(xiàn)
《CLR via C#》
【編輯推薦】
- .NET中的異步編程（一）:異步編程的原因
- .Net reflector兩款神器 Deblector和reflexil
- 淺談ASP.NET MVC 3中如何使用Model
- 手把手教你實現(xiàn).NET程序打包
