Disruptor中鎖對性能有什么影響

本篇文章給大家分享的是有關Disruptor中鎖對性能有什么影響，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Disruptor是英國外匯交易公司LMAX開發的一個高性能隊列，研發的初衷是解決內存隊列的延遲問題（在性能測試中發現竟然與I/O操作處于同樣的數量級）。基于Disruptor開發的系統單線程能支撐每秒600萬訂單，2010年在QCon演講后，獲得了業界關注。2011年，企業應用軟件專家Martin Fowler專門撰寫長文介紹。同年它還獲得了Oracle官方的Duke大獎。

目前，包括Apache Storm、Camel、Log4j 2在內的很多知名項目都應用了Disruptor以獲取高性能。在美團技術團隊它也有不少應用，有的項目架構借鑒了它的設計機制。本文從實戰角度剖析了Disruptor的實現原理。

需要特別指出的是，這里所說的隊列是系統內部的內存隊列，而不是Kafka這樣的分布式隊列。另外，本文所描述的Disruptor特性限于3.3.4。

介紹Disruptor之前，我們先來看一看常用的線程安全的內置隊列有什么問題。Java的內置隊列如下表所示。

隊列的底層一般分成三種：數組、鏈表和堆。其中，堆一般情況下是為了實現帶有優先級特性的隊列，暫且不考慮。

我們就從數組和鏈表兩種數據結構來看，基于數組線程安全的隊列，比較典型的是ArrayBlockingQueue，它主要通過加鎖的方式來保證線程安全；基于鏈表的線程安全隊列分成LinkedBlockingQueue和ConcurrentLinkedQueue兩大類，前者也通過鎖的方式來實現線程安全，而后者以及上面表格中的LinkedTransferQueue都是通過原子變量compare and swap（以下簡稱“CAS”）這種不加鎖的方式來實現的。

通過不加鎖的方式實現的隊列都是無界的（無法保證隊列的長度在確定的范圍內）；而加鎖的方式，可以實現有界隊列。在穩定性要求特別高的系統中，為了防止生產者速度過快，導致內存溢出，只能選擇有界隊列；同時，為了減少Java的垃圾回收對系統性能的影響，會盡量選擇array/heap格式的數據結構。這樣篩選下來，符合條件的隊列就只有ArrayBlockingQueue。

ArrayBlockingQueue在實際使用過程中，會因為加鎖和偽共享等出現嚴重的性能問題，我們下面來分析一下。

加鎖

現實編程過程中，加鎖通常會嚴重地影響性能。線程會因為競爭不到鎖而被掛起，等鎖被釋放的時候，線程又會被恢復，這個過程中存在著很大的開銷，并且通常會有較長時間的中斷，因為當一個線程正在等待鎖時，它不能做任何其他事情。如果一個線程在持有鎖的情況下被延遲執行，例如發生了缺頁錯誤、調度延遲或者其它類似情況，那么所有需要這個鎖的線程都無法執行下去。如果被阻塞線程的優先級較高，而持有鎖的線程優先級較低，就會發生優先級反轉。

Disruptor論文中講述了一個實驗：

• 這個測試程序調用了一個函數，該函數會對一個64位的計數器循環自增5億次。

• 機器環境：2.4G 6核

• 運算： 64位的計數器累加5億次

CAS操作比單線程無鎖慢了1個數量級；有鎖且多線程并發的情況下，速度比單線程無鎖慢3個數量級。可見無鎖速度最快。

單線程情況下，不加鎖的性能 > CAS操作的性能 > 加鎖的性能。

在多線程情況下，為了保證線程安全，必須使用CAS或鎖，這種情況下，CAS的性能超過鎖的性能，前者大約是后者的8倍。

以上就是Disruptor中鎖對性能有什么影響，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。