半年前翻譯了一系列很糟糕的異步編程文章，用異步的常用語來說：”在將來的某個時間“ 我還會重新翻譯Async in C#5.0 。

 寫在前面 

　　[[178935]]

異步編程在處理并發(fā)方面被使用的越來越多，之所以說上面一句話，是為了區(qū)分多線程編程。各位司機都知道，實際上異步編程的核心目標正并發(fā)處理。可還是經(jīng)常有一些讓人感到很無奈的說法和問題，比如說，異步編程能提高應用性能嗎？他能縮短我處理任務的時間嗎？他阻塞線程嗎？如果不阻塞線程，斷點為什么不繼續(xù)向下執(zhí)行，我的哥!線程釋放到哪兒去了？我都讀書少你別騙我，線程都釋放了程序怎么運行？前臺我用了Ajax,后臺使用Async有必要嗎？也許如果作為司機的你看到***一個問題，你只好攤手┑(￣Д ￣)┍。

多線程場景理解

也許在某些時刻，你想提高應用程序執(zhí)行速度，盡快拿到一個結果。這個時候，應該選擇的絕對不是Async和Task。打個比方說，你和你老婆周末去超市購物，剛一進超市門你發(fā)現(xiàn)結賬的每條隊伍都幾十人，于是你用到了多線程，你去排隊，一個人一個人的往前走，你老婆在另一頭抓緊購物，在你快走到收銀臺的時候，你老婆來把購物車推給了你，于是你們直接結賬回家。雖然這種行為很不文明，但這就是多線程，和異步編程一點關系都沒有。

 異步編程場景理解

那異步編程是什么情況，能解決什么問題呢？你和你老婆開了一家面包店，在初期只有你倆為顧客服務。沒想到新店開張這么火，每分鐘來一個顧客，而烤好一份面包需要兩分鐘。每來一位顧客你都拿著一片面包去后廚烤箱烤，并且你要和你老婆要花兩分鐘來等各自的烤箱完成任務。可是你等待的這兩分鐘，又來了兩位顧客，著這樣的速度下去，根本不能滿足顧客們的需求呀！你已經(jīng)發(fā)現(xiàn)你和你老婆的問題了：那就是你和你老婆這兩條線程，都被烤箱花費的時間阻塞了！

你和你老婆為了解決阻塞的問題，又買了兩臺烤箱，并且為了避免新進顧客沒人服務，每當你把面包送進烤箱后,標記其屬于哪位顧客后立即返回，準備接待新的顧客，再有顧客光臨，立馬接待，并將新的面包送進另一個烤箱并標記，并立即返回等待為其他人服務。在面包烤好后，烤箱會以“叮”一聲，注意在這一信號到達后，并不是一定要你去后廚烤箱取面包，而是你和你老婆誰不忙誰去取。這樣處理后，高并發(fā)的顧客量，對你來說就顯得得心應手了。你和你老婆做為兩條線程，可以不斷地以非阻塞的形式（不等烤箱），返回到顧客面前。但是需要注意的是不阻塞的概念，他不是讓你的程序繼續(xù)向下執(zhí)行。就烤面包而言你的一個烤面包方法是這樣的：

1.送入面包到烤箱 2.烤箱處理面包并給你結果 3.拿到面包送到顧客。所以說“不阻塞”的概念，不能讓你直接做到第三步。在不阻塞期間，是沒有線程在你的這個方法中的，這個方法還是要按照時間等待，等待在未來某個時刻的信號喚醒你或者你老婆，此時該方法恢復執(zhí)行。所以說程序執(zhí)行的時間依然不變，得到優(yōu)化的是處理并發(fā)的能力，你店里（服務器）的吞吐量。

 看著代碼理解

 異步編程應當被適用于IO密集型場景，非CPU計算密集場景。大家知道線程受CPU調度，如果你是四核CPU，那么在你的線程池中，擁有四個線程，進程每個虛擬CPU分配一個線程的時候，性能表現(xiàn)會最棒。既能高效運用CPU，又不用來回切換上下文損耗性能。你想想，CPU密集的場景中，CPU就是要占用你的線程，在這個時候異步編程沒有任何用處。然而在IO場景中，文件IO由win32用戶模式的API到windows內核模式，在內核模式中操作磁盤驅動程序。這期間，你的線程阻塞在驅動程序的響應中。而異步編程中，你的操作通知到磁盤驅動程序后，線程立即返回而非等待，在將來的某個時刻，驅動程序處理結束，處理結果放入CLR線程池隊列中，恢復狀態(tài)機，線程池中任意線程取出結果，方法繼續(xù)向下執(zhí)行。在網(wǎng)絡IO中也是如此，只不過驅動程序變成了網(wǎng)絡驅動程序。請看如下代碼：

public static async Task<string> DoSomeAsync() 
        { 
            using (var client = new HttpClient()) 
            { 
                var result = await client.GetAsync( 
                    "http://stackoverflow.com/questions/37991851/jenkins-configure-page-not-loading-version1-651-3-chrome-browser") .Result.Content.ReadAsStringAsync(); Console.WriteLine(result); //做一些其他操作 var res = 1 + 1; //---------------- return ""; 
            } 
        } 

在編譯的時候，DosomeAsync會被編譯成一個狀態(tài)機方法，狀態(tài)機是什么先別管，你可以把它當成一個黑盒子。在遇到GetAsync的時候，在DoSomeAsync中返回一個Task任務對象，并由await在Task對象上傳遞用于恢復狀態(tài)機的方法，相當于調用了ContinueWith().這個方法顧名思義，以xxx繼續(xù)。然后線程從DoSomeAsync中返回。返回后干嘛去了？該線程可以去處理其他事情了。在將來某一時刻，服務器向我們發(fā)送了一個相應，網(wǎng)絡驅動程序得知請求完畢，恢復該方法繼續(xù)執(zhí)行剩下的其他代碼。配一張亂糟糟的圖

 額外的好處

在GC的垃圾清理執(zhí)行過程中，應用程序的所有線程都會被掛起，使用異步編程意味著在相同的并發(fā)量下，你可以使用更少的線程來完成處理，額外帶來的好處就是，所需要清理的線程是更少的。還有一點就是，所使用的線程少了，CPU線程切換也變得更少。