前段時間寫了一篇關於C 非同步編程入門的文章，你可以點擊《 "C 非同步編程入門看這篇就夠了" 》查看。這篇文章我們來討論下關於C 非同步編程幾個不成文的建議，希望對你寫出高性能的非同步編程代碼有所幫助。註：本文的很多內容都是學習《Effective C 》的總結。 作者：依樂祝 原文地址：https:// ...
前段時間寫了一篇關於C#非同步編程入門的文章，你可以點擊《C#非同步編程入門看這篇就夠了》查看。這篇文章我們來討論下關於C#非同步編程幾個不成文的建議，希望對你寫出高性能的非同步編程代碼有所幫助。註：本文的很多內容都是學習《Effective C#》的總結。
作者：依樂祝
儘量不要編寫返回值類型為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:
- WhenAll：會根據現有的一批任務創建出一項新的任務，只有當那批任務全部執行完畢時，這項新人物才能夠完成。對Task.WhenAll所返回的新任務進行
await操作會獲得一份列表，早前的那些任務的執行結果就位於該列表中。 - 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的執行結果。
總結
今天分享的內容比較多，而且很多都比較難理解，不過確實是寫出高性能非同步方法所必須要掌握的技巧。由於時間較短，因此也沒來得及通過代碼進行講述，所以需要有一定的基礎才能看懂，不過還是希望對您有所幫助。
