學習線程安全隊列ConcurrentQueue

首先,基本使用:入隊(EnQueue) 、出隊(TryDequeue) 、是否爲空(IsEmpty)、獲取隊列內元素數量(Count)。

一、ConcurrentQueue內部結構:

wps_clip_image-30166

1.實現原理

衆所周知,在普通的非線程安全隊列有兩種實現方式:

1.使用數組實現的循環隊列。

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

先看看兩種方式的優劣:

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

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

    綜合以上兩種實現方式,在支持多線程併發出隊併發入隊的情況下,ConcurrentQueue使用了分段存儲的概念(如上圖所示),ConcurrentQueue分配內存時以段(Segment)爲單位,一個段內部含有一個默認長度爲32的數組和執行下一個段的指針,有個和Head和Tail指針分別指向了起始段和結束段(這種結構有點像操作系統的段式內存管理和頁式內存管理策略)。這種分配內存的實現方式不但減輕的GC的壓力而且調用者也不用顯示的調用TrimToSize()方法回收內存(在某段內存爲空時,會由GC來回收該段內存)。

2.Segment(段)內部結構

其實對於ConcurrentQueue的操作其實就是對Segment(數據段)的操作。

Segment可抽象出如下數據結構:

wps_clip_image-5493

Segment內部主要方法:

wps_clip_image-6121

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

二、入隊操作

wps_clip_image-24139

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

三、出隊操作

wps_clip_image-3291

如上圖所示,出隊失敗時返回false 而不是像入隊一樣進行回退操作,因爲出隊失敗的原因只有一個就是當隊列內所有段的元素爲空時,所以出隊設計成了返回bool值的函數。

四、判斷是否爲空(IsEmpty)

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

1. 頭節點(段)不爲空返回false

2. 頭節點爲空而且下一個節點也爲空返回true

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

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

wps_clip_image-31544

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

     跟ConcurrentStack一樣 微軟官方文檔和註釋中也說明:判斷隊列是否爲空要使用IsEmpty屬性而不是判斷Count == 0  原因在於GetHeadTailPositions在大量數據入隊和出隊的過程中尋找頭尾節點的位置是比較耗時的操作,要不斷循環確定頭尾節點的位置,所以判斷隊列是否爲空還是使用IsEmpty屬性。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章