.Net中的並行編程-3.ConcurrentQueue實現與分析

標籤：style   blog   http   io   os   使用   ar   strong   資料   

     在上文《.Net中的並行編程-2.ConcurrentQueue的實現與分析》 中解釋了無鎖的相關概念，無專屬偶BCL提供的ConcurrentQueue也是基於原子操作實現, 由於ConcurrentQueue的代碼較多所以本文主要分析幾個常用操作：

入隊(EnQueue) 、出隊(TryDequeue) 、是否為空白(IsEmpty)、擷取隊列內元素數量(Count)。

一、ConcurrentQueue內部結構:

1.實現原理

眾所周知，在普通的非安全執行緒隊列有兩種實現方式:

1.使用數組實現的迴圈隊列。

2.使用鏈表實現的隊列。

先看看兩種方式的優劣：

     .Net Farmework中的普通隊列Queue的實現使用了第一種方式，缺點是當隊列空間不足會進行擴容，擴容的主要實現是開闢一個原始長度2倍的新數組，然後將原始數組裡面的資料複製到新數組中，所以當擴容時就會產生不小的記憶體開銷，在並發的環境中對效能的影響不可小視。當然在調用Queue的建構函式時可以指定預設空間的大小，但是一般情況下資料量是不可預測的，選大了會照成空間浪費，選小了會有複製記憶體的開銷，而且隊列擴容以後需要顯示調用TrimToSize()方法才能回收掉不使用的記憶體空間。

     第二種鏈表實現方式雖然消除了空間浪費的問題但是又增加了GC的壓力，當入隊時會分配一個新節點，出隊時要對該節點進行廢棄，對於大量的出隊入隊操作時該實現方式效能不高。

    綜合以上兩種實現方式，在支援多線程並發出隊並發入隊的情況下，ConcurrentQueue使用了分段儲存的概念（如所示），ConcurrentQueue分配記憶體時以段(Segment)為單位，一個段內部含有一個預設長度為32的數組和執行下一個段的指標，有個和Head和Tail指標分別指向了起始段和結束段（這種結構有點像作業系統的段式記憶體管理和頁式記憶體管理原則）。這種分配記憶體的實現方式不但減輕的GC的壓力而且調用者也不用顯示的調用TrimToSize()方法回收記憶體（在某段記憶體為空白時，會由GC來回收該段記憶體）。

2.Segment(段)內部結構

其實對於ConcurrentQueue的操作其實就是對Segment(資料區段)的操作。

Segment可抽象出如下資料結構:

Segment內部主要方法:

    Segment內部和用數組實現的普通隊列相當，只不過對於入隊和出隊操作使用了原子操作來防止多線程競爭問題，使用隨機退讓等技術保證活鎖等問題，實現機制和ConcurrentStack差別不大，跟多TryAppend的實現細節在源碼注釋中已經闡述的非常清楚這裡就再做不過多的解釋。

二、入隊操作

如所示，入隊操作是在尾部的段中進行，當資料進入段內失敗時會先進行一個後援動作然後再不斷嘗試直到成功，這裡失敗的原因（tail.Append(item)返回false）只有一個就是當該段內的空間不夠時正在分配新的段，這段時間內會進入該段的元素會失敗。

三、出隊操作

如所示，出隊失敗時返回false 而不是像入隊一樣進行後援動作，因為出隊失敗的原因只有一個就是當隊列內所有段的元素為空白時，所以出隊設計成了返回bool值的函數。

四、判斷是否為空白(IsEmpty)

  整個判斷為O(1)的複雜度 主要有三種情況:

1. 前端節點（段）不為空白返回false

2. 前端節點為空白而且下一個節點也為空白返回true

3. 前端節點為空白而且下一個節點不為空白返回false，這種情況說明隊列正在擴容，所以要自選等待擴容完畢時再次進行判斷

五、擷取隊列內元素數量(Count)

     找到前端節點的low的位置和尾節點的high的位置，由於每個段內記錄了當前段在隊列中的索引，所以很容易求出整個隊列中元素的數量。

     跟ConcurrentStack一樣 微軟官方文檔和注釋中也說明：判斷隊列是否為空白要使用IsEmpty屬性而不是判斷Count == 0  原因在於GetHeadTailPositions在大量資料入隊和出隊的過程中尋找頭尾節點的位置是比較耗時的操作，要不斷迴圈確定頭尾節點的位置，所以判斷隊列是否為空白還是使用IsEmpty屬性。

.Net中的並行編程-3.ConcurrentQueue實現與分析