程式安全

執行緒安全是程式開發中非常需要我們注意的一環，當程式存在併發的可能時，如果我們不做特殊的處理，很容易就出現資料不一致的情況。

通常情況下，我們可以用加鎖的方式來保證執行緒安全，通過對共享資源 (也就是要讀取的資料) 的加上"隔離的鎖"，使得多個執行緒執行的時候也不會互相影響，而悲觀鎖和樂觀鎖正是併發控制中較為常用的技術手段。

樂觀鎖和悲觀鎖

什麼是悲觀鎖？什麼是樂觀鎖？其實從字面上就可以區分出兩者的區別，通俗點說，

悲觀鎖

悲觀鎖就好像一個有迫害妄想症的患者，總是假設最壞的情況，每次拿資料的時候都以為別人會修改，所以每次拿資料的時候都會上鎖，直到整個資料處理過程結束，其他的執行緒如果要拿資料就必須等當前的鎖被釋放後才能操作。

使用案例

悲觀鎖的使用場景並不少見，資料庫很多地方就用到了這種鎖機制，比如行鎖，表鎖，讀鎖，寫鎖等，都是在做操作之前先上鎖，悲觀鎖的實現往往依靠資料庫本身的鎖功能實現。Java程式中的Synchronized和ReentrantLock等實現的鎖也均為悲觀鎖。

在資料庫中，悲觀鎖的呼叫一般是在所要查詢的語句後面加上 for update，

select * from db_stock where goods_id = 1 for update

當有一個事務呼叫這條 sql 語句時，會對goods_id = 1 這條記錄加鎖，其他的事務如果也對這條記錄做 for update

當然，如果其他事務只是簡單的查詢而沒有用 for update的話，那麼查詢還是不會受影響的，只是說更新時一樣要等待當前事務結束才行。

值得注意的是，MySQL預設使用autocommit模式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交，就是說，如果我們不僅要讀，還要更新資料的話，需要手動控制事務的提交，比如像下面這樣：

set autocommit=0;
//開始事務
begin;
//查詢出商品id為1的庫存表資料
select * from db_stock where goods_id = 1 for update;
//減庫存
update db_stock set stock_num = stock_num - 1 where goods_id = 1 ;
//提交事務
commit;
 

雖然悲觀鎖能有效保證資料執行的順序性和一致性，但在高併發場景下並不適用，試想，如果一個事務用悲觀鎖對資料加鎖之後，其他事務將不能對加鎖的資料進行除了查詢以外的所有操作，如果該事務執行時間很長，那麼其他事務將一直等待，這無疑會降低系統的吞吐量。

這種情況下，我們可以有更好的選擇，那就是樂觀鎖。

樂觀鎖

樂觀鎖的思想和悲觀鎖相反，總是假設最好的情況，認為別人都是友好的，所以每次獲取資料的時候不會上鎖，但更新資料那一刻會判斷資料是否被更新過了，如果資料的值跟自己預期一樣的話，那麼就可以正常更新資料。

場景

這種思想應用到實際場景的話，可以用版本號機制和CAS演算法實現。

CAS

CAS是一種無鎖的思想，它假設執行緒對資源的訪問是沒有衝突的，同時所有的執行緒執行都不需要等待，可以持續執行。如果遇到衝突的話，就使用一種叫做CAS (比較交換) 的技術來鑑別執行緒衝突，如果檢測到衝突發生，就重試當前操作到沒有衝突為止。

原理

CAS的全稱是Compare-and-Swap，也就是比較並交換，它包含了三個引數：V，A，B，V表示要讀寫的記憶體位置，A表示舊的預期值，B表示新值

具體的機制是，當執行CAS指令的時候，只有當V的值等於預期值A時，才會把V的值改為B，如果V和A不同，有可能是其他的執行緒修改了，這個時候，執行CAS的執行緒就會不斷的迴圈重試，直到能成功更新為止。

正是基於這樣的原理，CAS即時沒有使用鎖，也能發現其他執行緒對當前執行緒的干擾，從而進行及時的處理。

缺點

CAS算是比較高效的併發控制手段，不會阻塞其他執行緒。但是，這樣的更新方式是存在問題的，看流程就知道了，如果C的結果一直跟預期的結果不一樣的話，執行緒A就會一直不斷的迴圈重試，重試次數太多的話對CPU也是一筆不小的開銷。

而且，CAS的操作範圍也比較侷限，只能保證一個共享變數的原子操作，如果需要一段程式碼塊的原子性的話，就只能通過Synchronized等工具來實現了。

除此之外，CAS機制最大的缺陷就是"ABA"問題。

ABA問題

前面說過，CAS判斷變數操作成功的條件是V的值和A是一致的，這個邏輯有個小小的缺陷，就是如果V的值一開始為A，在準備修改為新值前的期間曾經被改成了B，後來又被改回為A，經過兩次的執行緒修改物件的值還是舊值，那麼CAS操作就會誤任務該變數從來沒被修改過，這就是CAS中的“ABA”問題。

看完流程圖相信也不用我說太多了吧，執行緒多發的情況下，這樣的問題是非常有可能發生的，那麼如何避免ABA問題呢？

加標誌位，例如搞個自增的欄位，沒操作一次就加一，或者是一個時間戳，每次更新比較時間戳的值，這也是資料庫版本號更新的思想（下面會說到）

在Java中，自JDK1.5以後就提供了這麼一個併發工具類AtomicStampedReference，該工具內部維護了一個內部類，在原有基礎上維護了一個物件，及一個int型別的值（可以理解為版本號），在每次進行對比修改時，都會先判斷要修改的值，和記憶體中的值是否相同，以及版本號是否相同，如果全部相等，則以原子方式將該引用和該標誌的值設定為給定的更新值。

private static class Pair<T> {
        final T reference;
        final int stamp;
        private Pair(T reference, int stamp) {
            this.reference = reference;
            this.stamp = stamp;
        }
        static <T> Pair<T> of(T reference, int stamp) {
            return new Pair<T>(reference, stamp);
        }
    }

適用場景

CAS一般適用於讀多寫少的場景，因為這種情況執行緒的衝突不會太多，也只有執行緒衝突不嚴重的情況下，CAS的執行緒迴圈次數才能有效的降低，效能也能更高。

版本號機制

版本號機制是資料庫更新操作裡非常實用的技巧，其實原理很簡單，就是獲取資料的時候會拿一個能對應版本的欄位，然後更新的時候判斷這個欄位是否跟之前拿的值是否一致，一致的話證明資料沒有被別人更新過，這時就可以正常實現更新操作。

還是上面的那張表為例，我們加上一個版本號欄位version，然後每次更新資料的時候就把版本號加1，

select goods_id,stock_num,version from db_stock where goods_id = 1

update db_stock set stock_num = stock_num - 1,version = version + 1 where goods_id = 1 and version = #{version}

這樣的話，如果有兩個事務同時對goods_id = 1這條資料做更新操作的話，一定會有一個事務先執行完成，然後version欄位就加1，另一個事務更新的時候發現version已經不是之前獲取到的那個值了，就會重新執行查詢操作，從而保證了資料的一致性。

這種鎖的方式也不會影響吞吐量，畢竟大家都可以同時讀和寫，但高併發場景下，sql更新報錯的可能性會大大增加，這樣對業務處理似乎也不友好。

這種情況下，我們可以把鎖的粒度縮小，比如說減庫存的時候，我們可以這麼處理：

update db_stock set stock_num = stock_num - 1  where goods_id = 1 and stock_num > 0

這樣一來，sql更新衝突的概率會大大降低，而且也不用去單獨維護類似version的欄位了。

最後

關於悲觀鎖和樂觀鎖的例子介紹就到這兒了，當然，本文也只是略微講解，更多的知識點還要靠大家研究，而且，除了這兩種鎖，併發控制中還有很多其他的控制手段，像什麼Synchronized、ReentrantLock、公平鎖，非公平鎖之類的都是很常見的併發知識，不管是為了日常開發還是應付面試，掌握這些知識點還是很有必要的，而且，併發程式設計的知識思想是共通的，知道一塊知識點後很容易就能延伸去學習其他的知識點。

拿我自己來說，最近也在認真研究Java併發程式設計的一些知識點，也因為要寫樂觀鎖的緣故，順道複習了一下CAS和它的使用案例，從而也瞭解到了ReentrantLock底層其實就是通過CAS機制來實現鎖的，而且還了解了獨佔鎖，共享鎖，可重入鎖等使用場景，由點到面，也讓我知識體系儲備更加的豐富，近期也有打算擼幾篇關於ReentrantLock知識的文章出來，歡迎大家多來踩踩！

作者：鄙人薛某，一個不拘於技術的網際網路人，技術三流，吹水一流，想看更多精彩文章可以關注我的公眾號哦~~~

原創不易，您的 【點贊】 將是我創作的最大動力，感謝各位的支援！