樂觀鎖與悲觀鎖

處理多執行緒併發訪問最常用的就是加鎖，鎖又分成樂觀鎖和悲觀鎖。

悲觀鎖

在多執行緒訪問共享資源時，同時只允許一個執行緒獨享此資源，其他執行緒都被悲觀鎖阻塞，只有當前擁有鎖的執行緒釋放鎖，其他執行緒才能被喚起競爭這個資源，每個執行緒在獲取資源前都要悲觀的檢查該資源是否已經被佔用，所以悲觀鎖的開銷是巨大的，但安全性高，用synchronized關鍵字或者ReentrantLock都是悲觀鎖。

樂觀鎖

樂觀鎖假定在多執行緒修改共享資源時是有先後順序的，不會發生同時修改的衝突，所以操作都不進行加鎖，只是提交時檢查是否有衝突，有衝突則失敗，解決衝突的方法就是不斷自旋重試，直到成功，所以樂觀鎖效率比悲觀鎖效率高，但也引入了自旋過多和ABA問題。

CAS

CAS全稱是compareAndSwap，1.5中引入了java.util.concurrent包,其中樂觀鎖的實現就是基於CAS，它是建立在“硬體指令集”上來控制原子性的，常見的CAS操作有：

    public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);

    public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x);

    public final native boolean compareAndSwapLong(Object o, long offset, long expected, long x);
 

CAS的執行步驟是將指定地址的值與期待的值比較，如果相等則修改成新值，如果不相等則放棄修改，在AtomicInteger中就使用了CAS，自增中如果修改失敗則自旋，重新獲取新值繼續自增

    public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }
 

CAS帶來的問題

既然CAS能解決併發問題，那我們都使用CAS怎麼樣？ CAS雖然是一種多執行緒的解決方案，但其實是需要根據業務場景區分的，CAS帶來的第一個問題就是ABA。

ABA問題

CAS比較的是該地址預期的值，如果在執行CAS期間，有其他的執行緒修改了值並且最終此值與原值相同，CAS是會忽略修改歷史的，比如：

CAS前記錄值為A，修改成B，在修改前值A被修改成C又修改成A，這時再執行CAS就會通過，程式無法知道修改歷史，如果只是數值自增這樣的邏輯不用在乎ABA問題，但如果業務邏輯需要關心值是否被修改過就需要解決ABA問題。

下面的例子存在ABA問題

        Unsafe unsafe = getUnsafeInstance();
        long offSet = 0;
        try {
            offSet = unsafe.objectFieldOffset(Integer.class.getDeclaredField("value"));
        } catch (Exception ex) {
            throw new Error(ex);
        }
        Integer value = 0;

        long finalOffSet = offSet;
        Thread thread1 = new Thread(()->{
            boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 1);
            boolean b1 = unsafe.compareAndSwapInt(value, finalOffSet, 1, 0);
            System.out.println("result "+b +"-"+b1+" value "+ value);

        });

        Thread thread2 = new Thread(()->{
            boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 3);
            System.out.println("result "+b +" final value "+value);
        });

        thread1.start();
        thread1.join();

        thread2.start();
        thread2.join();
        

取到Unsafe需要反射

    public static Unsafe getUnsafeInstance() throws Exception{
        Field unsafeStaticField =
                Unsafe.class.getDeclaredField("theUnsafe");
        unsafeStaticField.setAccessible(true);
        return (Unsafe) unsafeStaticField.get(Unsafe.class);
    }

輸出

result true-true value 0
result true final value 3

可以看出有ABA問題並且修改都成功了。

解決這個問題可以引入版號，java中可以使用AtomicStampedReference來解決ABA問題

執行緒1將值從0自增成1，stamp增加1，執行緒2自增2，但stamp已經改變，修改失敗

   public static void main(String[] args) throws Exception {

        AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference(0, 0);

        Integer reference = atomicStampedReference.getReference();
        int stamp = atomicStampedReference.getStamp();

        Thread th1 = new Thread(() -> {
            int stampT = stamp;
            int newStamp = stampT + 1;
            boolean b = atomicStampedReference.compareAndSet(reference, reference + 1, stampT, newStamp);
            System.out.println("th1 result " + b);
        });

        Thread th2 = new Thread(() -> {
            int stampT = stamp;
            int newStamp = stampT + 1;
            boolean b = atomicStampedReference.compareAndSet(reference, reference + 2, stampT, newStamp);
            System.out.println("th2 result " + b);
        });

        th1.start();
        th1.join();

        th2.start();
        th2.join();
    }

輸出

th1 result true
th2 result false

自旋過多問題

如果併發的比較厲害，修改失敗的概率就會增加，失敗後的自旋相應的也會增多，會影響效率。

所以CAS適用於預期不太會發生衝突或者衝突不多的情況，如果併發概率很大還是用悲觀鎖。