前言:最近給客戶開發一個伙食費計算系統,大概須要計算2000我的的伙食。需求是按照員工的預約報餐計劃對消費記錄進行檢查,若有未報餐有刷卡或者有報餐沒刷卡的要進行必定的金額扣減等一系列規則。一開始個人想法比較簡單,直接用一個for循環搞定,統計結果卻是沒問題,可是計算出來太慢了須要7,8分鐘。這樣系統服務是報超時錯誤的,讓人以爲有點不太爽。因爲時間也很少就就先提交給用戶使用了,後面邏輯又增長了,計算時間變長,整個計算一遍竟然要將近10分鐘了。這個對用戶來講是能接收的(原來本身手算須要好幾天呢),可是我本身接受不了,因而就開始優化了,怎麼優化呢,用多線程唄。數據庫
一提到多線程,最早想到的是Task了,畢竟.net4.0以上Task封裝了不少好用的方法。可是Task畢竟是多開一些線程去執行任務,最後整合結果,這樣能夠快一些,但我想更加快速一些,因而想到了另一個對象:Parallel。以前在維護代碼是確實有遇到過別人寫的Parallel.Invoke,只是指定這個函數的做用是併發執行多項任務,若是遇到多個耗時的操做,他們之間又不貢獻變量這個方法不錯。個人狀況是要併發執行一個集合,因而就用了List.ForAll 這個方法實際上是拓展方法,完整的調用爲:List.AsParallel().ForAll,須要先轉換成支持併發的集合,等同於Parallel.ForEach,目的是對集合裏面的元素併發執行一系列操做。安全
因而乎,把原來的foreach換成了List.AsParallel().ForAll,運行起來,果真速度驚人,不到兩分鐘就插入結果了,但最後倒是報主鍵重複的錯誤,這個錯誤的緣由是,因爲使用了併發,這個時候變量自增,實際上是在強着自增,當多個線程同時獲取到了id值,都去自增而後就重複了,舉個例子以下:多線程
int num = 1; List<int> list = new List<int>(); for (int i = 1; i <= 2000; i++) { list.Add(i); } Console.WriteLine($"num初始值爲:" + num.ToString()); list.AsParallel().ForAll(n => { num++; }); Console.WriteLine($"不加鎖,併發{list.Count}次後爲:" + num.ToString()); Console.ReadKey();
這段代碼是讓一個變量執行2000次自增,正常結果應該是2001,但實際結果以下:併發
有經驗的同窗,立馬能想到須要加鎖了,C#內置了不少鎖對象,如lock 互斥鎖,Interlocked 內部鎖,Monitor 這幾個比較常見,lock內部實現其實就是使用了Monitor對象。對變量自增,Interlocked對象提供了,變量自增,自減、或者相加等方法,咱們使用自增方法Interlocked.Increment,函數定義爲:int Increment(ref int num),該對象提供原子性的變量自增操做,傳入目標數值,返回或者ref num都是自增後的結果。 在以前的基礎上咱們增長一些代碼:dom
num = 1; Console.WriteLine($"num初始值爲:" + num.ToString()); list.AsParallel().ForAll(n => { Interlocked.Increment(ref num); }); Console.WriteLine($"使用內部鎖,併發{list.Count}次後爲:" + num.ToString()); Console.ReadKey();
咱們來看運行結果:函數
加了鎖以後ID重複算是解決了,其實別高興太早,因爲正常的環境有了ID咱們還有用這些ID來構建對象呢,因而又寫了寫代碼,用集合來添加這些ID,爲了更真實的模擬生產環境,我在forAll裏面又加了一層循環代碼以下:測試
num = 1; Random random = new Random(); var total = 0; var m = new ConcurrentBag<int>(); list.AsParallel().ForAll(n => { var c = random.Next(1, 50); Interlocked.Add(ref total, c); for (int i = 0; i < c; i++) { Interlocked.Increment(ref num); m.Add(num); } }); Console.WriteLine($"使用內部鎖,併發+內部循環{list.Count}次後爲:" + num.ToString()); Console.WriteLine($"實際值爲:{total + 1}"); var l = m.GroupBy(n => n).Where(o => o.Count() > 1); Console.WriteLine($"併發裏面使用安全集合ConcurrentBag添加num,集合重複值:{l.Count()}個"); Console.ReadKey();
上面的代碼裏面我用到了線程安全集合ConcurrentBag<T>它的命名空間是:using System.Collections.Concurrent,儘管使用了線程安全集合,可是在併發面前仍然是不安全的,到了這裏其實比較鬱悶了,自增長鎖,安全集合內部應該也使用了鎖,但仍是重複了。有點說不過去了,想一想多線程執行時有個上下文對象,即當多個線程同時執行任務,共享了變量他們一開始傳進去的對象數值應該是相同的,因爲變量自增時加了鎖,因此ID是不會重複了。我猜想問題應該出在Add方法了,就是說當num值自增後尚未來得及傳出去就已經執行了Add方法,故添加了重複變量。因而乎,我從新寫了段代碼,讓ID自增和集合添加都放到鎖裏面:優化
num = 1; total = 0; using (var q = new BlockingCollection<int>()) { list.AsParallel().ForAll(n => { var c = random.Next(1, 50); Interlocked.Add(ref total, c); for (int i = 0; i < c; i++) { // Task.Delay(100); q.Add(Interlocked.Increment(ref num)); //可控 //lock (objLock) //{ // num++; // q.Add(num); //} } }); q.CompleteAdding(); Console.WriteLine($"num累計值爲:{total},併發以後值爲:{num}"); var x = q.GroupBy(n => n).Where(o => o.Count() > 1); Console.WriteLine($"併發使用安全集合BlockingCollection+Interlocked添加num,集合重複值:{x.Count()}個"); Console.ReadKey(); }
這裏我測試了另一個線程安全的集合BlockingCollection,關於這個集合的使用請自行查找MSDN文檔,上面的關鍵代碼直接添加安全集合的返回值,能夠保證集合不會重複,但其實下面的lock更適用與正式環境,由於咱們添加的通常都是對象不會是基礎類型數值,運行結果以下:spa
至此,咱們的問題解決了,計算時間由原來的9分多降至110秒左右,可見Parallel的處理仍是很給力的,惟一不足的是,很佔CPU,執行計算後CPU達到了88%。附上計算結果:.net
優化先後對比
總結:C#安全集合在併發的狀況下其實不必定是安全的,仍是須要結合實際應用場景和驗證結果爲準。Parallel.ForEach在對循環數量可觀的狀況下是能夠去使用的,若是有共享變量,必定要配合鎖作同步處理。仍是得慎用這個方法,若是方法內部有操做數據庫的記得增長事務處理,不然就呵呵了。