在2010年的PDC上，微軟發(fā)布了Visual Studio Async CTP，大大地降低了異步編程的難度，讓我們可以像寫(xiě)同步的方法那樣去編寫(xiě)異步代碼。Async CTP也在社區(qū)里掀起了不小的波瀾。在這之后，我也學(xué)習(xí)了一段時(shí)間，這個(gè)系列會(huì)將這段時(shí)間的學(xué)習(xí)作個(gè)梳理。

　　好了，下面進(jìn)入本文的正題。

　　為什么需要異步編程

　　既然同步的寫(xiě)法更自然簡(jiǎn)單，異步的代碼（傳統(tǒng)的）不好寫(xiě)，還容易出錯(cuò)，那我們?yōu)槭裁葱枰ゾ帉?xiě)異步的代碼呢？微軟還要費(fèi)這么大勁投入對(duì)Async CTP的開(kāi)發(fā)呢？這其中肯定有一些原因。

　　快速響應(yīng)的用戶(hù)界面

　　作為電腦的資深用戶(hù)，我們肯定有多次“漏斗式鼠標(biāo)”，“轉(zhuǎn)圈式鼠標(biāo)”的體驗(yàn)吧。點(diǎn)擊一個(gè)按鈕，然后鼠標(biāo)就在那兒不停的轉(zhuǎn)圈，再在界面上點(diǎn)兩下，界面變灰，標(biāo)題欄上出現(xiàn)“沒(méi)有響應(yīng)”。然后我們束手無(wú)策，性子好點(diǎn)的就在那兒等待一會(huì)兒，看看能不能恢復(fù)過(guò)來(lái)；性子不好的就打開(kāi)任務(wù)管理器殺掉進(jìn)程，殺掉進(jìn)程容易，但有可能會(huì)破壞重要數(shù)據(jù)。

　　那造成這種情況到底是什么原因呢？概括成一句話就是：耗時(shí)的操作阻塞了UI線程，造成UI線程不能響應(yīng)用戶(hù)操作。關(guān)于更底層的原因請(qǐng)移步我的這篇文章:WinForm二三事（一）消息循環(huán)。那么這個(gè)時(shí)候我們就需要一種機(jī)制，在發(fā)起耗時(shí)操作的請(qǐng)求之后要立即返回，不要阻塞UI線程，讓UI線程可以繼續(xù)響應(yīng)用用戶(hù)的操作。然后等耗時(shí)操作返回后，通過(guò)回調(diào)來(lái)處理耗時(shí)操作返回的結(jié)果。下面是在UI上使用同步的方式和異步的方式的示意圖：

　　更高的伸縮性

　　對(duì)于服務(wù)器端應(yīng)用來(lái)說(shuō)，一般都是一個(gè)線程處理一個(gè)請(qǐng)求。另外一點(diǎn)是，線程的創(chuàng)建和銷(xiāo)毀是昂貴的（這一點(diǎn)可以參考《CLR via C#》中Thread Baisc一章的描述），而服務(wù)器的資源肯定是有限的；并且，線程創(chuàng)建的越多，線程上下文切換就會(huì)變得越頻繁。所以，為了創(chuàng)建高可伸縮性的服務(wù)，我們必須用最少的線程處理更多的請(qǐng)求，這樣不僅能夠做到消耗更少的資源（創(chuàng)建更少的線程），而且在應(yīng)對(duì)請(qǐng)求突發(fā)增長(zhǎng)的情況也很有用處，那么這里非常重要的一點(diǎn)就是不要阻塞線程，讓線程池能夠高效的工作。而且，在服務(wù)端應(yīng)用中，有非常多的IO操作：數(shù)據(jù)庫(kù)訪問(wèn)，磁盤(pán)操作，Socket訪問(wèn)等。對(duì)于這些IO操作，不屬于計(jì)算密集型操作，是不需要單獨(dú)分配一個(gè)線程來(lái)處理的。

　　要做到高可伸縮性，異步是一劑良藥。假設(shè)現(xiàn)在這是一個(gè)web應(yīng)用，當(dāng)用戶(hù)的HTTP request到來(lái)時(shí)，線程池提供一個(gè)線程來(lái)處理（忽略前面的排隊(duì)等過(guò)程），然后到某一點(diǎn)，我們肯定需要讀取磁盤(pán)、訪問(wèn)數(shù)據(jù)庫(kù)，這個(gè)時(shí)候我們使用異步的方式，發(fā)起IO請(qǐng)求，然后處理HTTP request的線程就可以返回到線程池了，它可以繼續(xù)處理其他請(qǐng)求，不需要在這里等待IO操作的返回。當(dāng)IO操作完成之后，會(huì)通過(guò)回調(diào)（具體實(shí)現(xiàn)方式請(qǐng)參照后續(xù)文章）完成剛才那個(gè)HTTP reqeust后續(xù)的處理。

　　下面是使用同步方式和異步方式的示意圖：

　　上圖只畫(huà)出了一個(gè)請(qǐng)求，高亮顯示的那一段其實(shí)是不需要占用線程的，其實(shí)這段時(shí)間該線程可以返回線程池，然后分配去做其他請(qǐng)求，而數(shù)據(jù)庫(kù)返回結(jié)果之后，再?gòu)木€程池里分配一個(gè)線程來(lái)處理后續(xù)操作。這樣，如果請(qǐng)求多的話，線程池就會(huì)創(chuàng)建更多的線程來(lái)處理請(qǐng)求，最后結(jié)果大家應(yīng)該都知道了。

　　從上圖可以看出，開(kāi)始的時(shí)候來(lái)自線程池的thread1處理請(qǐng)求，然后發(fā)起對(duì)數(shù)據(jù)庫(kù)的請(qǐng)求，發(fā)起操作完畢后，thread1被線程池回收；當(dāng)數(shù)據(jù)庫(kù)將結(jié)果返回時(shí)線程池選擇另外一個(gè)線程thread2（有可能是原來(lái)的那個(gè)線程，如果空閑的話）來(lái)處理數(shù)據(jù)庫(kù)返回的結(jié)果，完成后續(xù)的操作。對(duì)于IO操作非常多的服務(wù)來(lái)說(shuō)，所獲得的益處是不可估量的。

　　后記

　　本文主要從創(chuàng)建響應(yīng)靈敏的用戶(hù)界面和創(chuàng)建高可伸縮性的服務(wù)應(yīng)用這兩種不同的應(yīng)用場(chǎng)景來(lái)闡釋我們?yōu)槭裁葱枰惒健Ｖ劣谌绾芜M(jìn)行異步開(kāi)發(fā)在后續(xù)的文章我會(huì)首先介紹傳統(tǒng)的異步和Async CTP以及F#中的Async Workflow。

NET技術(shù)：.NET中的異步編程（一）-為什么需要異步，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。