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

 寫在前面 

　　[[178935]]

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

多線程場景理解

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

 異步編程場景理解

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

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

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

 看著代碼理解

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

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

 額外的好處

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