1. 程式人生 > >面試必備知識點:悲觀鎖和樂觀鎖的那些事兒

面試必備知識點:悲觀鎖和樂觀鎖的那些事兒

程式安全

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

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

樂觀鎖和悲觀鎖

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

悲觀鎖

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

使用案例

悲觀鎖的使用場景並不少見,資料庫很多地方就用到了這種鎖機制,比如行鎖,表鎖,讀鎖,寫鎖等,都是在做操作之前先上鎖,悲觀鎖的實現往往依靠資料庫本身的鎖功能實現。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知識的文章出來,歡迎大家多來踩踩!


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

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