面試必問系列：悲觀鎖和樂觀鎖的那些事兒

程序安全

線程安全是程序開發中很是須要咱們注意的一環，當程序存在併發的可能時，若是咱們不作特殊的處理，很容易就出現數據不一致的狀況。

一般狀況下，咱們能夠用加鎖的方式來保證線程安全，經過對共享資源 (也就是要讀取的數據) 的加上"隔離的鎖"，使得多個線程執行的時候也不會互相影響，而悲觀鎖和樂觀鎖正是併發控制中較爲經常使用的技術手段。

樂觀鎖和悲觀鎖

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

悲觀鎖

悲觀鎖就好像一個有迫害妄想症的患者，老是假設最壞的狀況，每次拿數據的時候都覺得別人會修改，因此每次拿數據的時候都會上鎖，直到整個數據處理過程結束，其餘的線程若是要拿數據就必須等當前的鎖被釋放後才能操做。

使用案例

悲觀鎖的使用場景並很多見，數據庫不少地方就用到了這種鎖機制，好比行鎖，表鎖，讀鎖，寫鎖等，都是在作操做以前先上鎖，悲觀鎖的實現每每依靠數據庫自己的鎖功能實現。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知識的文章出來，歡迎你們多來踩踩！

---

做者：鄙人薛某，一個不拘於技術的互聯網人，技術三流，吹水一流，想看更多精彩文章能夠關注個人公衆號哦~~~

---

原創不易，您的 【三連】 將是我創做的最大動力，感謝各位的支持！