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

本文轉自(https://segmentfault.com/a/1190000023866733),版權歸原作者所有,僅備份

 

程序安全

線程安全是程序開發中非常需要我們注意的一環,當程序存在併發的可能時,如果我們不做特殊的處理,很容易就出現數據不一致的情況。

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

樂觀鎖和悲觀鎖

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

悲觀鎖

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

使用案例

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

在數據庫中,悲觀鎖的調用一般是在所要查詢的語句後面加上 for update

select * from db_stock where goods_id = 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 where goods_id and stock_num 0

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

最後

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章