關于C#異步編程你應該了解的幾點建議

前段時間寫了一篇關于C#異步編程入門的文章，你可以點擊《C#異步編程入門看這篇就夠了》查看，這篇文章我們來討論下關于C#異步編程幾個不成文的建議，希望對你寫出高性能的異步編程代碼有所幫助，注：本文的很多內容都是學習《Effective C#》的總結，

作者：依樂祝

原文地址：https://www.cnblogs.com/yilezhu/p/12099219.html

盡量不要撰寫回傳值型別為void的異步方法

在通常情況下，建議大家不要撰寫那種回傳值型別為void的異步方法，因為這樣做會破壞該方法的啟動者與方法本身之間的約定，這套約定本來可以確保主調方能夠捕獲到異步方法所發生的例外，
正常的異步方法是通過它回傳的Task物件來匯報例外的，如果執行程序中發生了例外，那么Task物件就進入了faulted（故障）狀態，主調方在對異步方法所回傳的Task物件做await操作時，該物件若已處在faulted狀態，系統則會將執行異步方法的程序中所發生的例外拋出，反之，若Task尚未執行到拋出例外的那個地方，則主調方的執行進度會暫停在await陳述句這里，等系統稍后安排某個執行緒繼續執行該陳述句下方的那些代碼時，例外才會拋出，

總結一句話就是：void的異步方法發生例外時，開發者得不到任何通知，程式既不會觸發普通的例外處理程式，也不會把這些例外記錄下來，總之，這會讓相關的執行緒默默的終止掉，

不要把同步方法與異步方法組合起來使用

用async關鍵字來修飾的方法意味著該方法有可能會在執行完所有作業之前就把控制權回傳給主調方，而且，它回傳給主調方的是個代表作業進度的Task物件，主調方可以查詢此物件的狀態，以了解該作業是否已經完成、尚未完成還是在執行程序中發生了故障，此外，這種方法還在暗示主調方：本方法所執行的作業可能要花費很長時間，因此建議你先去做其他一些事情，稍后再來向我索要結果，
與此相反，如果把某個方法設計成同步方法，那么意味著當該方法執行完畢時，它的后置條件必定能夠得到滿足，無論這個方法要花多長時間去完成作業，它都會采用與主調方相同的資源來完成，主調方必須等這個方法徹底執行完畢才能向下執行，
這兩種方法單獨寫起來都很清晰，但是如果把他們組合在一起就會讓方法變得十分難用，而且有可能導致各種bug，如死鎖，因此，這里提出兩條重要的原則，第一，不要讓同步方法必須等待異步方法執行完畢才能往下執行（盡量不用Wait()以及.result這些阻塞式的方法），第二，不要讓異步方法把雖然耗時很長、計算量很大但是完全可以由自己執行的作業轉交給另一個異步任務去做，’
當然對于第二點，這并不是說計算量較大的任務絕對不能放在單獨的執行緒中執行，而是說不應該把只用一個執行緒就能迅速做好的任務刻意的拆解成許多個較小的部分，并把他們分別放在多個新的執行緒上執行，而是應該把整個任務都交給某個執行緒來執行才對，

使用異步方法時應盡量避免執行緒分配

異步任務看上去好像很神奇，因為這種任務刻意轉移到另一個地方去做，使得開啟這項任務的異步方法可以在該任務完成之后，從早前暫停的地方繼續往下推進，不過，要想發揮異步任務的功效，就必須保證把這項任務交出去確實能夠少占用一些資源，而不是僅僅會在相似的資源之間進行背景關系切換，
如：對于一個控制臺程式，如果只是執行一項計算量較大且耗時較長的任務（或者說，運行時間較長的CPU密集型的任務），那么把該任務單獨放在另一個執行緒中并沒有多大好處，因為這樣做只能讓作業執行緒始終處于繁忙狀態，而主執行緒則必須一直卡在那里等待作業執行緒把任務做完，在這種情況下，實際上是用兩個執行緒來完成原本只需要一個執行緒就能做好的作業，造成了資源的浪費，

避免不必要的背景關系切換

目前C#代碼中使用async以及await實作的異步方法默認是把await之后的代碼放在早前捕獲的那個背景關系中執行的，這是因為這樣做比較穩妥，它最多只會引發幾次無謂的背景關系切換，而不會使程式出現重大的錯誤，與之相反，如果系統不把山下文切換回去，那么萬一遇到的是只能在特定的背景關系中才能執行的代碼，那么程式就有可能崩潰，因此，無論有沒有必要切換背景關系，系統都會切換至早前捕獲到的那個背景關系，并把await之后的陳述句放在那個背景關系執行，
如果不想讓系統做出這樣的安排，那么可以呼叫ConfigureAwait()方法，這表示接下來的那些代碼無須放在早前捕獲的背景關系中執行，例如在很多程式集中，await陳述句之后的那些代碼一般都與背景關系無關，因此與，可以呼叫Task物件的ConfigureAwait()方法告訴系統，在執行完這項任務之后，不必專門把await下面的代碼放在早前捕獲的背景關系中運行，如下所示：

public static async Task<XElement> ReadPacket(string url)
{
	var result=await DownloadAsync(url)
				.ConfigureAwait(false);
	return XElement.Parse(result);			
}

C#語言默認讓程式把await下面的陳述句都放在早前捕獲的背景關系中執行，這樣做雖然較為安全，但是會降低程式的效率，因此為了讓用戶能夠更加順暢的使用程式，我們應該調整代碼的結構，把必須運行在特定背景關系的代碼剝離出來，并盡量考慮在await陳述句那里呼叫ConfigureAwait(false)，使得程式可以把陳述句下面的代碼放在默認背景關系中運行，而不是切換回早前的背景關系，

通過Task物件來進行異步開發

Task（任務）是一種抽象機制，可以用來表示某項作業，于是，就能夠把該作業轉交給其他資源去完成，Task型別以及與之相關的類與結構體提供了豐富的API，讓開發者可以操控Task物件以及由該物件所表示的作業，此外，Task物件自身也具備一些方法與屬性，可以用來操作本物件所表示的任務，這些Task物件可以合起來構成一項比較大的任務，他們之間既能夠按照順序執行，也能夠平行的執行，
可以通過await陳述句來確保某些任務之間能夠按照一定的順序執行，也就是說，只有當該陳述句所要等待的那項作業完畢之后，陳述句下方的代碼才能夠執行，
總之，由于C#提供了一套豐富的API，因此可以寫出相當優雅的演算法來處理Task物件，并對這些物件所表示的任務進行安排，對任務的用法理解的越透徹，寫出來的異步代碼越清晰，
這里簡單說明兩個常用的API:

1. WhenAll：會根據現有的一批任務創建出一項新的任務，只有當那批任務全部執行完畢時，這項新人物才能夠完成，對Task.WhenAll所回傳的新任務進行await操作會獲得一份串列，早前的那些任務的執行結果就位于該串列中，
2. WhenAny：為了盡早的獲得某個結果，可能啟動多項任務，使得他們分別從不同的途徑去獲取該結果，只要其中有一項任務完成，你的目標就達成了，針對這項需求，可以考慮使用Task.WhenAny方法，并把自己所創建的那批任務傳進去，對WhenAny方法所回傳的Task物件進行await操作可以獲取到一項任務，它指的就是這批任務中最先執行完畢的那項任務，

考慮實作任務的取消協議

異步任務的編程模型（也叫基于任務的異步編程模型）提供了標準的API，用來取消任務或者廣播任務的執行進度，雖然這些API是可選的，但如果某項任務確實能夠匯報其進度，或者能夠予以取消，那就可以考慮用合適的辦法來實作這些API，

針對需要取消的任務，我們可以通過CanclelationTokenSource物件來進行取消操作，這種物件是一種起到中介作用的物件，該物件處在有可能發出取消請求的客戶代碼與支持取消功能的那項操作之間，

如果正在執行的任務發現客戶端想要取消該操作，那么它就會通過ThrowIfCanclellationRequested()方法拋出TaskCanclledException例外，庸醫表示整個作業流程沒有能夠完全得到執行，

此外，回傳值型別為void型別的異步方法不應該支持取消功能，

快取泛型異步方法的回傳值

可能你在進行異步編程的時候對異步方法設定的回傳型別都是Task或者Task<T>，然而有些時候把回傳值型別設為Task可能會影響性能，如果某個回圈或某段代碼需要頻繁的運行，那么系統就有可能分配很多個Task物件，從而占用相當多的資源，好在C#提供了一種新的型別，叫做ValueTask<T>物件，他用起來比普通的Task更為高效，該型別是值型別，因此創建這種型別的物件時，不需要再分配額外的空間，這個好處使得我們可以多創建一些這樣的物件，而不用擔心它會像Task物件那樣占據過多的資源，如果你的異步方法可以根據早前快取起來的結果直接回傳相應的值，那么尤其應該考慮把回傳值型別設定為ValueTask<T>，

其次，ValueTask提供了一個能夠接受Task引數的建構式，這個建構式會在其內部等候該Task的執行結果，

總結

今天分享的內容比較多，而且很多都比較難理解，不過確實是寫出高性能異步方法所必須要掌握的技巧，由于時間較短，因此也沒來得及通過代碼進行講述，所以需要有一定的基礎才能看懂，不過還是希望對您有所幫助，

標籤：.NET Core

上一篇：如何運用領域驅動設計 - 存盤庫

下一篇：最新表格編輯器與大資料交換軟體更新啦。輕松寫表格無需等待。