寫在前面
優秀軟件的一個關鍵特徵就是具有併發性。過去的幾十年，我們可以進行併發編程，但是難度很大。以前，併發性軟件的編寫、調試和維護都很難，這導致很多開發人員爲圖省事放棄了併發編程。新版 .NET 中的程序庫和語言特徵，已經讓併發編程變得簡單多了。隨着 Visual Studio 2012 的發佈，微軟明顯降低了併發編程的門檻。以前只有專家才能做併發編程，而今天，每一個開發人員都能夠（而且應該）接受併發編程。
解答疑問：.NET Core 同步和異步的差別
public ActionResult PushFileData([FromBody] Web_PushFileData file) //同步
public async ActionResult PushFileData([FromBody] Web_PushFileData file) //異步
疑問：對於同步方法，每個請求都是使用同個線程嗎？如客戶A請求同步Action，還未執行完畢時，客戶B請求會阻塞。
對於異步方法，每個請求都是從線程池拿空閒線程出來執行方法？也就是客戶A和客戶B請求方法，都是在不同子線程裏分別執行的。
導航
基本概念
- 併發編程
- TPL
線程基礎
- windows爲什麼要支持線程
- 線程開銷
- CPU的發展
- 使用線程的理由
如何寫一個簡單Parallel.For循環
- 數據並行
- Parallel.For剖析
數據和任務並行中潛在的缺陷
- 不要假設並行總是很快
- 避免寫入共享緩存
- 避免調用非線程安全的方法
許多個人電腦和工作站都有多核CPU,可以同時執行多個線程。爲了充分利用硬件，您可以將代碼並行化，以便跨多個處理器分發工作。
在過去，並行需要對線程和鎖進行低級操作。Visual Studio和.NET框架通過提供運行時、類庫類型和診斷工具來增強對並行編程的支持。這些特性是在.NET Framework 4中引入的，它們使得並行編程變得簡單。您可以用自然的習慣用法編寫高效、細粒度和可伸縮的並行代碼，而無需直接處理線程或線程池。
下圖展示了.NET框架中並行編程體系結構。
1 基本概念
1.1 併發編程
併發
同時做多件事情
這個解釋直接表明了併發的作用。終端用戶程序利用併發功能，在輸入數據庫的同時響應用戶輸入。服務器應用利用併發，在處理第一個請求的同時響應第二個請求。只要你希望程序同時做多件事情，你就需要併發。
多線程
併發的一種形式，它採用多個線程來執行程序。從字面上看，多線程就是使用多個線程。多線程是併發的一種形式，但不是唯一的形式。
並行處理
把正在執行的大量的任務分割成小塊，分配給多個同時運行的線程。
爲了讓處理器的利用效率最大化，並行處理（或並行編程）採用多線程。當現代多核 CPU行大量任務時，若只用一個核執行所有任務，而其他覈保持空閒，這顯然是不合理的。
並行處理把任務分割成小塊並分配給多個線程，讓它們在不同的核上獨立運行。並行處理是多線程的一種，而多線程是併發的一種。
異步編程
併發的一種形式，它採用 future 模式或回調（callback）機制，以避免產生不必要的線程。
一個 future（或 promise）類型代表一些即將完成的操作。在 .NET 中，新版 future 類型
有 Task 和 Task 。在老式異步編程 API 中，採用回調或事件（event），而不是
future。異步編程的核心理念是異步操作：啓動了的操作將會在一段時間後完成。這個操作
正在執行時，不會阻塞原來的線程。啓動了這個操作的線程，可以繼續執行其他任務。當
操作完成時，會通知它的future，或者調用回調函數，以便讓程序知道操作已經結束。
NOTE:通常情況下，一個併發程序要使用多種技術。大多數程序至少使用了多線程（通過線程池）和異步編程。要大膽地把各種併發編程形式進行混合和匹配，在程序的各個部分使用
合適的工具。
1.2 TPL
任務並行庫（TPL）是System.Threading和System.Threading.Tasks命名空間中的一組公共類型和API。
TPL動態地擴展併發度，以最有效地使用所有可用的處理器。通過使用TPL，您可以最大限度地提高代碼的性能，同時專注於您的代碼的業務實現。
從.NET Framework 4開始，TPL是編寫多線程和並行代碼的首選方式。
2 線程基礎
2.1 Windows 爲什麼要支持線程
在計算機的早期歲月,操作系統沒提供線程的概念。事實上,整個系統只運行着一個執行線程(單線程),其中同時包含操作系統代碼和應用程序代碼。只用一個執行線程的問題在於,長時間運行的任務會阻止其他任務執行。
例如,在16位Windows的那些日子裏,打印一個文檔的應用程序很容易“凍結”整個機器,造成OS和其他應用程序停止響應。有的程序含有bug,會造成死循環。遇到這個問題,用戶只好重啓計算機。用戶對此深惡痛絕。
於是微軟下定決心設計一個新的OS,這個OS必須健壯,可靠,易於是伸縮以安全,同同時必須改進16位windows的許多不足。
微軟設計這個OS內核時,他們決定在一個進程(Process)中運行應用程序的每個實例。進程不過是應用程序的一個實例要使用的資源的一個集合。每個進程都被賦予一個虛擬地址空間,確保一個進程使用的代碼和數據無法由另一個進程訪問。這就確保了應用程序實例的健壯性。由於應用程序破壞不了其他應用程序或者OS本身,所以用戶的計算體驗變得更好了。
聽起來似乎不錯,但CPU本身呢？如果一個應用程序進入無限循環,會發生什麼呢?如果機器中只有一個CPU,它會執行無限循環,不能執行其它任何東西。所以,雖然數據無法被破壞,而且更安全,但系統仍然可能停止響應。微軟要修復這個問題,他們拿出的方案就是線程。作爲Windows概念,線程的職責是對CPU進行虛擬化。Windows爲每個進程都提供了該進程專用的專用的線程(功能相當於一個CPU,可將線程理解成一個邏輯CPU)。如果應用程序的代碼進入無限循環,與那個代碼關聯的進程會被“凍結”,但其他進程(他們有自己的線程)不會凍結:他們會繼續執行！
2.2 線程開銷
線程是一個非常強悍的概念,因爲他們使windows即使在執行長時間運行的任務時也能隨時響應。另外,線程允許用戶使用一個應用程序(比如“任務管理器”)強制終止似乎凍結的一個應用程序(它也有可能正在執行一個長時間運行的任務)。但是,和一切虛擬化機制一樣,線程會產生空間(內存耗用)和時間(運行時的執行性能)上的開銷。
創建線程,讓它進駐系統以及最後銷燬它都需要空間和時間。另外,還需要討論一下上下文切換。單CPU的計算機一次只能做一件事情。所以,windows必須在系統中的所有線程(邏輯CPU)之間共享物理CPU。
在任何給定的時刻,Windows只將一個線程分配給一個CPU。那個線程允許運行一個時間片。一旦時間片到期,Windows就上下文切換到另一個給線程。每次上下文切換都要求Windows執行以下操作：
- 將CPU寄存器中的值保存到當前正在運行的線程的內核對象內部的一個上下文結構中。
- 從現有線程集合中選一個線程供調度(切換到的目標線程)。如果該線程由另一個進程擁有,Window在開始執行任何代碼或者接觸任何數據之前,還必須切換CPU“看得見”的虛擬地址空間。
- 將所選上下文結構中的值加載到CPU的寄存器中。
上下文切換完成後,CPU執行所選的線程,直到它的時間片到期。然後,會發生新一輪的上下文切換。Windows大約每30ms執行一次上下文切換。
上下文切換是淨開銷:也就是說上下文切換所產生的開銷不會換來任何內存或性能上的收益。
根據上述討論,我們的結論是必須儘可能地避免使用線程,因爲他們要耗用大量的內存,而且需要相當多的時間來創建，銷燬和管理。Windows在線程之間進行上下文切換,以及在發生垃圾回收的時候,也會浪費不少時間。然而,根據上述討論,我們還得出一個結論,那就是有時候必須使用線程,因爲它們使Windows變得更健壯,反應更靈敏。
應該指出的是,安裝了多個CPU或者一個多核CPU)的計算機可以真正同時運行幾個線程,這提升了應用程序的可伸縮性(在少量的時間裏做更多工作的能力)。Windows爲每個CPU內核都分配一個線程,每個內核都自己執行到其他線程的上下文切換。Windows確保單個線程不會在多個內核上同時被調度,因爲這會代理巨大的混亂。今天,許多計算機都包含了多個CPu,超線程CPU或者多核CPU。但是,windows最初設計時,單CPU計算機纔是主流,所以Windows設計了線程來增強系統的響應能力和可靠性。今天,線程還被用於增強應用程序的可伸縮性,但在只有多CPU(或多核CPU)計算機上纔有可能發生。
TIP：一個時間片結束時,如果Windows決定再次調度同一個線程(而不是切換到另外給一個線程),那麼Windows不會執行上下文切換。線程將繼續執行,這顯著改進了性能。設計自己的代碼時注意,上下文切換能避免的就要儘量避免。
2.3 CPU的發展
過去,CPU速度一直隨着時間在變快。所以,在一臺舊機器上運行得慢的程序在新機器上一般會快些。然而,CPU 廠商沒有延續CPU越來越快的趨勢。由於CPU廠商不能做到一直提升CPU的速度,所以它們側重於將晶體管做得越來越小,使一個芯片上能夠容納更多的晶體管。今天,一個硅芯片可以容納2個或者更多的CPU內核。這樣一來,如果在寫軟件時能利用多個內核,軟件就能運行得更快些。
今天的計算機使用了以下三種多CPU技術。
- 多個CPU
- 超線程芯片
- 多核芯片
2.4 使用線程的理由
使用線程有以下三方面的理由。
- 使用線程可以將代碼同其他代碼隔離
這將提高應用程序的可靠性。事實上,這正是Windows在操作系統中引入線程概念的原因。Windows之所以需要線程來獲得可靠性,是因爲你的應用程序對於操作系統來說是的第三方組件,而微軟不會在你發佈應用程序之前對這些代碼進行驗證。如果你的應用程序支持加載由其它廠商生成的組件，那麼應用程序對健壯性的要求就會很高,使用線程將有助於滿足這個需求。 - 可以使用線程來簡化編碼
有的時候,如果通過一個任務自己的線程來執行該任務,或者說單獨一個線程來處裏該任務,編碼會變得更簡單。但是,如果這樣做,肯定要使用額外的資源,也不是十分“經濟”(沒有使用盡量少的代碼達到目的)。現在,即使要付出一些資源作爲代價,我也寧願選擇簡單的編碼過程。否則,乾脆堅持一直用機器語言寫程序好了,完全沒必要成爲一名C#開發人員。但有的時候,一些人在使用線程時,覺得自己選擇了一種更容易的編碼方式,但實際上,它們是將事情(和它們的代碼)大大複雜化了。通常,在你引入線程時,引入的是要相互協作的代碼,它們可能要求線程同步構造知道另一個線程在什麼時候終止。一旦開始涉及協作,就要使用更多的資源,同時會使代碼變得更復雜。所以,在開始使用線程之前,務必確定線程真的能夠幫助你。 - 可以使用線程來實現併發執行
如果(而且只有)知道自己的應用程序要在多CPU機器上運行,那麼讓多個任務同時運行,就能提高性能。現在安裝了多個CPU(或者一個多核CPU)的機器相當普遍,所以設計應用程序來使用多個內核是有意義的。
3 數據並行(Data Parallelism)
3.1 數據並行
數據並行是指對源集合或數組中的元素同時（即並行）執行相同操作的情況。在數據並行操作中，源集合被分區，以便多個線程可以同時在不同的段上操作。
數據並行性是指對源集合或數組中的元素同時任務並行庫（TPL）通過system.threading.tasks.parallel類支持數據並行。這個類提供了for和for each循環的基於方法的並行實現。
您爲parallel.for或parallel.foreach循環編寫循環邏輯，就像編寫順序循環一樣。您不必創建線程或將工作項排隊。在基本循環中，您不必使用鎖。底層工作TPL已經幫你處理。
下面代碼展示順序和並行：
// Sequential version foreach (var item in sourceCollection) { Process(item); } // Parallel equivalent Parallel.ForEach(sourceCollection, item => Process(item));
並行循環運行時，TPL對數據源進行分區，以便循環可以同時在多個部分上運行。在後臺，任務調度程序根據系統資源和工作負載對任務進行分區。如果工作負載變得不平衡，調度程序會在多個線程和處理器之間重新分配工作。
下面的代碼來展示如何通過Visual Studio調試代碼:
public static void test() { int[] nums = Enumerable.Range(0, 1000000).ToArray(); long total = 0; // Use type parameter to make subtotal a long, not an int Parallel.For<long>(0, nums.Length, () => 0, (j, loop, subtotal) => { subtotal += nums[j]; return subtotal; }, (x) => Interlocked.Add(ref total, x) ); Console.WriteLine("The total is {0:N0}", total); Console.WriteLine("Press any key to exit"); Console.ReadKey(); }
- 選擇調試 > 開始調試，或按F5。
- 應用在調試模式下啓動，並會在斷點處暫停。
- 在中斷模式下打開線程通過選擇窗口調試 > Windows > 線程。 您必須位於一個調試會話以打開或請參閱線程和其他調試窗口。
![在這裏插入圖片描述]()
3.2 Parallel.For剖析
查看Parallel.For的底層,
public static ParallelLoopResult For<TLocal>(int fromInclusive, int toExclusive, Func<TLocal> localInit, Func<int, ParallelLoopState, TLocal, TLocal> body, Action<TLocal> localFinally);
清楚的看到有個func函數,看起來很熟悉。
[TypeForwardedFrom("System.Core, Version=3.5.0.0, Culture=Neutral, PublicKeyToken=b77a5c561934e089")] public delegate TResult Func<out TResult>();
原來是定義的委託,有多個重載，具體查看文檔：https://docs.microsoft.com/en-us/dotnet/api/system.func-4?view=netframework-4.7.2
實際上TPL之前,實現併發或多線程,基本都要使用委託。
TIP:關於委託,大家可以查看(https://docs.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/delegates)。或者《細說委託》(https://www.cnblogs.com/laoyu/archive/2013/01/13/2859000.html)
4 數據和任務並行中潛在的缺陷
在許多情況下,parallel.for和parallel.foreach可以比普通的順序循環提供顯著的性能改進。然而，並行循環的工作引入了複雜性，這可能會導致在順序代碼中不常見或根本不會遇到的問題。本主題列舉了一些實踐來幫您避免這些問題,當你在寫並行代碼的時候。
4.1 不要假設並行總是很快
在某些情況下，並行循環的運行速度可能比其順序等效循環慢。基本的經驗法則是，具有很少迭代和快速用戶委託的並行循環不太可能加快速度。但是,由於有很多因素會影響性能,我建議您測量實際結果。
4.2 避免寫入共享緩存
在順序代碼中,讀寫靜態變量或者字段是很正常的。然而，每當多個線程同時訪問這些變量時，就有很大的競爭條件潛力。即使您可以使用鎖來同步對變量的訪問，同步成本也會損害性能。因此，我們建議您儘可能避免或至少限制對並行循環中共享狀態的訪問。最好的方式是使用Parallel.For 和 Parallel.ForEach的重載方法,在並行循環期間,它們使用System.Threading.ThreadLocal泛型類型的變量來存儲線程本地狀態。通過使用並行循環，您將產生劃分源集合和同步工作線程的開銷。並行化的好處進一步受到計算機上處理器數量的限制。在一個處理器上運行多個計算綁定線程並不能加快速度。因此,要注意不要過度使用並行。
過度使用並行最常見的場景發生在嵌套循環中。在大多數情況下,最好僅在外層循環使用並行,除非以下幾種場景適用：
- 內層循環很長
- 您正在對每筆訂單執行昂貴的計算。
- 目標系統有足夠的處理器來處理通過並行處理對客戶訂單的查詢而產生的線程數。
在所有情況下，確定最佳查詢形狀的最佳方法都是測試和度量。
4.3 避免調用非線程安全的方法
從並行循環中寫入非線程安全的實例方法可能會導致數據損壞，這在程序中可能會被檢測到，也可能不會被檢測到。它可能導致異常。在以下示例中,多線程會嘗試同時調用FileStream.WriteByte方法,但是這個是不被支持的。
FileStream fs = File.OpenWrite(path); byte[] bytes = new Byte[10000000]; // ... Parallel.For(0, bytes.Length, (i) => fs.WriteByte(bytes[i]));
參考文獻：
- https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
- https://docs.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/delegates
- https://www.cnblogs.com/laoyu/archive/2013/01/13/2859000.html
- 《C#併發經典實例》
- 《CLR via C#》第3版
- https://www.52interview.com/solutions/38
 歡迎關注訂閱我的微信公衆平臺【熊澤有話說】，更多好玩易學知識等你來取
作者：熊澤-學習中的苦與樂 公衆號：熊澤有話說 當前出處： https://www.cnblogs.com/xiongze520/p/14271739.html 原文出處： https://www.52interview.com/solutions/38 創作不易，版權歸作者和博客園共有，轉載或者部分轉載、摘錄，請在文章明顯位置註明作者和原文鏈接。
|