計算機組成-無鎖編程追求極致性能

前言

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

• L1 Cache，分為數據緩存和指令緩存，邏輯核獨占

• L2 Cache，物理核獨占，邏輯核共享

• L3 Cache，所有物理核共享

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

存儲器存儲空間大小：內存>L3>L2>L1>寄存器。

存儲器速度快慢排序：寄存器>L1>L2>L3>內存。

緩存行大小

---

[root@192 ~]# 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
[root@192 ~]# 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類型的數據

• 
  • 遍歷數組元素速度很快，后面連續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架構技術棧社區