計算機組成-無鎖程式設計追求極致效能

雕爺的架構之路 發表於 2020-12-04

前言

​ 現代計算機通常由CPU,以及主機板、記憶體、硬碟等主要硬體結構組成,而決定計算機效能的最核心部件是CPU+記憶體,CPU負責處理程式指令,記憶體負責儲存指令執行結果。在這個工作機制當中CPU的讀寫效率其實是遠遠高於記憶體的,為提升執行效率減少CPU與記憶體的互動,一般在CPU上設計了快取結構,常見的為三級快取結構:

  • L1 Cache,分為資料快取和指令快取,邏輯核獨佔

  • L2 Cache,物理核獨佔,邏輯核共享

  • L3 Cache,所有物理核共享

下圖為CPU-Core(TM)I7-10510U型號快取結構

1604646633836

儲存器儲存空間大小:記憶體>L3>L2>L1>暫存器。

儲存器速度快慢排序:暫存器>L1>L2>L3>記憶體。

快取行大小


[[email protected] ~]# getconf -a|grep CACHE
LEVEL1_ICACHE_SIZE                 32768 #L1快取大小
LEVEL1_ICACHE_ASSOC                8 #L1快取行大小
LEVEL1_ICACHE_LINESIZE             64
LEVEL1_DCACHE_SIZE                 32768
LEVEL1_DCACHE_ASSOC                8
LEVEL1_DCACHE_LINESIZE             64
LEVEL2_CACHE_SIZE                  262144 #L2快取大小
LEVEL2_CACHE_ASSOC                 4
LEVEL2_CACHE_LINESIZE              64 #L2快取行大小
LEVEL3_CACHE_SIZE                  8388608 #L3快取大小
LEVEL3_CACHE_ASSOC                 16
LEVEL3_CACHE_LINESIZE              64 #L3快取行大小
LEVEL4_CACHE_SIZE                  0
LEVEL4_CACHE_ASSOC                 0
LEVEL4_CACHE_LINESIZE              0
[[email protected] ~]# cat /proc/cpuinfo |grep -i cache
cache size	: 8192 KB
cache_alignment	: 64
cache size	: 8192 KB
cache_alignment	: 64

JAVA程式毫無疑問也必須是執行在硬體機器之上,如何利用底層硬體工作原理,提升效能也必然是我們需要考慮的,筆者今天以無鎖併發高效能框架Disruptor為例分析如何高效的利用CPU快取。

Who is Disruptor?

​ Disruptor是一個開源框架,研發的初衷是為了解決高併發下佇列鎖的問題,最早由LMAX(一種新型零售金融交易平臺)提出並使用,能夠在無鎖的情況下實現佇列的併發操作,並號稱能夠在一個執行緒裡每秒處理6百萬筆訂單。

快取行填充

下方示例為Disruptor框架的內部程式碼:

abstract class RingBufferPad
{
    protected long p1, p2, p3, p4, p5, p6, p7;
}

分析:

  1. 變數p1~p7本身沒有實際意義,只能用於快取行填充,為了儘可能地用上CPU Cache
  2. 訪問CPU裡的L1 Cache或者L2 Cache、L3 Cache,訪問延時是記憶體的1/15乃至1/100(記憶體的訪問速度,是遠遠慢於CPU Cache的)
    • 因此,為了追求極限效能,需要儘可能地從CPU Cache裡面讀取資料
  3. CPU Cache裝載記憶體裡面的資料,不是一個個欄位載入的,而是載入一整個快取行
    • 64位的Intel CPU,快取行通常是64 Bytes,一個long型別的資料需要8 Bytes,因此會一下子載入8個long型別的資料
  • 1604710347879
    • 遍歷陣列元素速度很快,後面連續7次的資料訪問都會命中CPU Cache,不需要重新從記憶體裡面去讀取資料

快取行失效

p1-p7僅用來填充快取行,我們跟本用不到它,但是我們為什麼要填充滿一個快取行呢?

  1. CPU在載入資料的時候,會把這個資料從記憶體載入到CPU Cache裡面

  2. 此時,CPU Cache裡面除了這個資料,還會載入這個資料前後定義的其他變數

    • 釋義:在高併發場景下,假定併發訪問變數p0,在p0後定義的其它變數也一併會被快取load
  3. Disruptor是一個多執行緒的伺服器框架,在這個資料前後定義的其他變數,可能會被多個不同的執行緒去更新資料,讀取資料

    • 這些寫入和讀取請求,可能會來自於不同的CPU Core
    • 為了保證資料的同步更新,不得不把CPU Cache裡面的資料,重新寫回到記憶體裡面或者重新從記憶體裡面載入
    • CPU Cache的寫回載入,都是以整個Cache Line作為單位的
  4. 如果常量的快取失效,當再次讀取這個值的時候,需要重新從記憶體讀取,讀取速度會大大變慢

計算機組成-無鎖程式設計追求極致效能

快取行填充

abstract class RingBufferPad
{
    protected long p1, p2, p3, p4, p5, p6, p7;
}

abstract class RingBufferFields<E> extends RingBufferPad
{
    ...
    private final long indexMask;
    private final Object[] entries;
    protected final int bufferSize;
    protected final Sequencer sequencer;
    ...
}

public final class RingBuffer<E> extends RingBufferFields<E> implements Cursored, EventSequencer<E>, EventSink<E>
{
    ...
    protected long p1, p2, p3, p4, p5, p6, p7;
    ...
}
  1. Disruptor在RingBufferFields裡面定義的變數前後分別定義了7個long型別的變數
    • 前面7個繼承RingBufferPad,後面7個直接定義RingBuffer類中
    • 這14個變數沒有任何實際用途,既不會去,也不會去
  2. RingBufferFields裡面定義的變數都是final的,第一次寫入之後就不會再進行修改
    • 一旦被載入到CPU Cache之後,只要被頻繁地讀取訪問,就不會被換出CPU Cache
    • 無論在記憶體的什麼位置,這些變數所在的Cache Line都不會有任何寫更新的請求

計算機組成-無鎖程式設計追求極致效能

空間區域性性+分支預測

  1. Disruptor整個框架是一個高速的生產者-消費者模型下的佇列
    • 生產者不停地往佇列裡面生產新的需要處理的任務
    • 消費者不停地從佇列裡面處理掉這些任務
  2. 要實現一個佇列,最合適的資料結構應該是連結串列,如Java中的LinkedBlockingQueue
  3. Disruptor並沒有使用LinkedBlockingQueue,而是使用了RingBuffer的資料結構
    • RingBuffer的底層實現是一個固定長度的陣列
    • 比起連結串列形式的實現,陣列的資料在記憶體裡面會存在空間區域性性
      • 陣列的連續多個元素會一併載入到CPU Cache裡面,所以訪問遍歷的速度會更快
      • 連結串列裡面的各個節點的資料,多半不會出現在相鄰的記憶體空間
    • 資料的遍歷訪問還有一個很大的優勢,就是CPU層面的分支預測會很準確
      • 可以更有效地利用CPU裡面的多級流水線

計算機組成-無鎖程式設計追求極致效能

計算機組成-無鎖程式設計追求極致效能

CAS無鎖

鎖對效能的影響

  1. Disruptor作為一個高效能的生產者-消費者佇列系統,一個核心的設計:通過RingBuffer實現一個無鎖佇列
  2. Java裡面的LinkedBlockingQueue,比起Disruptor的RingBuffer要慢很多,主要原因
    • 連結串列的資料在記憶體裡面的佈局對於快取記憶體不友好
    • LinkedBlockingQueue對於鎖的依賴
      • 一般來說消費者比生產者快(不然佇列會堆積),因為大部分時候,佇列是的,生產者和消費者一樣會產生競爭
  3. LinkedBlockingQueue的鎖機制是通過ReentrantLock,需要JVM進行裁決
    • 鎖的爭奪,會把沒有拿到鎖的執行緒掛起等待,也需要進行一次上下文切換
    • 上下文切換的過程,需要把當前執行執行緒的暫存器等資訊,儲存到記憶體中的執行緒棧裡面
      • 意味:已經載入到快取記憶體裡面的指令或者資料,又回到主記憶體裡面,進一步拖慢效能

計算機組成-無鎖程式設計追求極致效能

RingBuffer 無鎖方案

  1. 加鎖很慢,所以Disruptor的解決方案是無鎖(沒有作業系統層面的鎖)
  2. Disruptor利用了一個CPU硬體支援的指令,稱之為CAS(Compare And Swap)
  3. Disruptor的RingBuffer建立一個Sequence物件,用來指向當前的RingBuffer的頭和尾
    • 頭和尾的標識,不是通過一個指標來實現的,而是通過一個序號
  4. RingBuffer在進行生產者和消費者之間的資源協調,採用的是對比序號的方式
    • 當生產者想要往佇列裡面加入新資料的時候,會把當前生產者的Sequence的序號,加上需要加入的新資料的數量
    • 然後和實際的消費者所在的位置進行對比,看下佇列裡是不是有足夠的空間加入這些資料
      • 而不是直接覆蓋掉消費者還沒處理完的資料
  5. CAS指令,既不是基礎庫裡的一個函式,也不是作業系統裡面實現的一個系統呼叫,而是一個CPU硬體支援的機器指令
    • 在Intel CPU上,為cmpxchg指令:compxchg [ax] (隱式引數,EAX累加器), [bx] (源運算元地址), [cx] (目標運算元地址)
    • 第一個運算元不在指令裡面出現,是一個隱式的運算元,即EAX累加暫存器裡面的值
    • 第二個運算元就是源運算元,指令會對比這個運算元和上面EAX累加暫存器裡面的值
    • 虛擬碼:IF [ax]== [bx] THEN [ZF] = 1, [bx] = [cx] ELSE [ZF] = 0, [ax] = [bx]
    • 單個指令是原子的,意味著使用CAS操作的時候,不需要單獨進行加鎖,直接呼叫即可

計算機組成-無鎖程式設計追求極致效能

Sequence關鍵程式碼如下:

public long addAndGet(final long increment)
{
    long currentValue;
    long newValue;

    // 如果CAS操作沒有成功,會不斷等待重試
    do
    {
        currentValue = get();
        newValue = currentValue + increment;
    }
    while (!compareAndSet(currentValue, newValue));

    return newValue;
}

public boolean compareAndSet(final long expectedValue, final long newValue)
{
    // 呼叫CAS指令
    return UNSAFE.compareAndSwapLong(this, VALUE_OFFSET, expectedValue, newValue);
}

Benchmark

互斥鎖競爭、CAS樂觀鎖與無鎖測試:

public class LockBenchmark {

    private static final long MAX = 500_000_000L;

    private static void runIncrement() {
        long counter = 0;
        long start = System.currentTimeMillis();
        while (counter < MAX) {
            counter++;
        }
        long end = System.currentTimeMillis();
        System.out.println("Time spent is " + (end - start) + "ms without lock");
    }

    private static void runIncrementWithLock() {
        Lock lock = new ReentrantLock();
        long counter = 0;
        long start = System.currentTimeMillis();
        while (counter < MAX) {
            if (lock.tryLock()) {
                counter++;
                lock.unlock();
            }
        }
        long end = System.currentTimeMillis();
        System.out.println("Time spent is " + (end - start) + "ms with lock");
    }

    private static void runIncrementAtomic() {
        AtomicLong counter = new AtomicLong(0);
        long start = System.currentTimeMillis();
        while (counter.incrementAndGet() < MAX) {
        }
        long end = System.currentTimeMillis();
        System.out.println("Time spent is " + (end - start) + "ms with cas");
    }

    public static void main(String[] args) {
        runIncrement();
        runIncrementWithLock();
        runIncrementAtomic();

        // Time spent is 153ms without lock
        // Time spent is 7801ms with lock
        // Time spent is 3164ms with cas
        // 7801 / 153 ≈ 51
        // 3164 / 153 ≈ 21   
    }
}得出

** 結論:無鎖效能要遠高於cas與lock,cas要大於lock**

更多好文章,請關注公眾號:奇客時間,原創JAVA架構技術棧社群

相關文章