京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

面試官:瞭解鎖嗎?

小明:瞭解,還經常用過。

面試官:說說synchronized和lock的區別吧

小明:synchronized是可重入鎖,由於lock是一個接口,重入性取決於實現,synchronized不支持中斷,而lock可以。。。。。。。。。。。。。。。。

面試官:好了,那有沒有比這兩種鎖更快的鎖呢?

小明:在讀多寫少的情況下,讀寫鎖比他們的效率更高。

面試官:那有沒有比讀寫鎖更快的鎖呢?

小明:。。。。。。。。。。

我靠,問的這麼深的嗎?小明當時就矇蔽了,因為它項目中使用比較多的就是synchronized,讀寫鎖都很少用到,因為很少牽扯到多線程問題,這個面試讓他知道了多線程的重要性。

什麼是讀寫鎖

讀寫鎖:允許多個線程同時讀,但是隻允許一個線程寫,在線程獲取到寫鎖的時候,其他寫操作和讀操作都會處於阻塞狀態,讀鎖和寫鎖也是互斥的,所以在讀的時候是不允許寫的,那如何實現一個讀寫鎖呢?

讀寫鎖比傳統的synchronized速度要快很多,原因就是在於讀寫鎖支持讀併發,而synchronized要求所有操作都是串行化,舉個例子,我需要查詢某個用戶的基本信息,這些信息很少發生變化,所以我們會將這部分信息存放到緩存中,我們的查詢操作為:

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

按照上面流程圖,如果使用synchronized的時候,查詢緩存都會阻塞,但是使用讀寫鎖,查詢緩存時併發的,查詢數據庫是阻塞的,所以,讀寫鎖在讀多寫少的情況下,性能明顯要優於synchronized。

人類的文明在進步,java也在進步,對知識的渴望也在不斷的增加,所以我們就不斷的在想這麼一個問題,讀寫鎖的讀和寫是互斥,那我們能不能做到讀和寫支持併發呢?

StampedLock橫空出世

StampedLock其實是對讀寫鎖的一種改進,它支持在讀同時進行一個寫操作,也就是說,它的性能將會比讀寫鎖更快。

更通俗的講就是在讀鎖沒有釋放的時候是可以獲取到一個寫鎖,獲取到寫鎖之後,讀鎖阻塞,這一點和讀寫鎖一致,唯一的區別在於讀寫鎖不支持在沒有釋放讀鎖的時候獲取寫鎖。

StampedLock三種模式

悲觀讀:與讀寫鎖的讀寫類似,允許多個線程獲取悲觀讀鎖

寫鎖:與讀寫鎖的寫鎖類似,寫鎖和悲觀讀是互斥的。

樂觀讀:無鎖機制,類似於數據庫中的樂觀鎖,它支持在不是放寫鎖的時候是可以獲取到一個寫鎖的,這點和讀寫鎖不同。

基本語法

我們先來看看悲觀讀於與寫鎖的基本語法

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

我們看到,StampedLock語法和讀寫鎖ReentrantReadWriteLock有了一點點區別,

獲取鎖的返回值:

StampedLock:long

ReentrantReadWriteLock:Lock

釋放鎖的方式:

StampedLock:unlock(stamp),需要傳入獲取鎖返回的那個long值。

ReentrantReadWriteLock:unlock(),直接調用unlock方法即可。

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

這是悲觀讀+寫鎖的使用方式,達到的效果與讀寫鎖(ReentrantReadWriteLock) 是一樣的,我們一起來驗證一下,我將代碼稍微做了一點改動,打印了兩個線程的執行日誌,同時當調用線程是zhangsan的時候休眠三秒,目的是為了看lisi的線程能否成功的獲取到寫鎖,代碼如下

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

如果在zhansan的線程休眠階段李四的線程獲取到了寫鎖,那麼代表悲觀讀和寫鎖不是互斥的,反之互斥,請看代碼運行結果:

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

我們仔細看打印日誌的輸出時間, 11:30:58 lisi和zhangsan都獲取到了悲觀讀鎖,並且zhangsan開始休眠,然後11:31:01的時候休眠結束,zhangsan獲取到了寫鎖,所以悲觀讀與寫鎖肯定是互斥的,那這樣的效率不是和讀寫鎖一樣嗎?為什麼說它比讀寫鎖更快呢?這不是矛盾嗎?

客官,別急啊,要記住精彩的永遠在最後,StampedLock特鎖模式我們只用了其中的兩個,還有一個沒有出場呢,下面我們來看看樂觀讀。

讓StampedLock性能更上一樓的樂觀讀

樂觀讀並不是一種鎖,所以請不要和悲觀讀聯繫在一起,它是一種無鎖機制,相當於java的原子類操作,所以理論上性能會比讀寫鎖(ReentrantReadWriteLock)更快一點,但不絕對。

當樂觀讀讀取了成員變量的時候,需要將變量賦值給局部變量,然後再判斷程序運行期間是否存在寫鎖,如果存在,升級為悲觀讀。

我們一起來看一下樂觀讀的實現

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

解釋代碼,定義了兩個成員變量,讓後利用t1線程去計算兩個成員變量的和,為了能體現出樂觀讀的效果,我在sum()中休眠了3秒,目的是讓main主線程去修改掉成員變量的值,main函數中的休眠是為了讓t1線程能準確地執行到讀取成員變量階段。

我們來看看執行的結果:

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

我們發現,t1首先讀取了兩個成員變量的值,然後發現了存在寫操作,那是因為main函數利用寫鎖修改了兩個成員變量的值,這個時候升級為了悲觀讀,再次獲取成員變量的值,然後再計算兩個值的和,為什麼要升級悲觀讀鎖呢?因為再文章開頭的時候說過悲觀讀鎖與寫鎖互斥,悲觀讀鎖之前並行,所以樂觀讀升級到悲觀讀鎖之後再獲取一次成員變量,可以保證再當前悲觀讀鎖中數據是線程安全的。

使用StampedLock的注意事項

1.StampedLock屬於ReadWriteLock的子類,ReentrantReadWriteLock也是屬於ReadWriteLock的子類,你們發現他們的區別了嗎?看名字就能看出來StampedLock不支持重入鎖。

2.它適用於讀多寫少的情況,如果不是這中情況,請慎用,性能可能還不如synchronized。

3.StampedLock的悲觀讀鎖、寫鎖不支持條件變量。

4.千萬不能中斷阻塞的悲觀讀鎖或寫鎖,如果調用阻塞線程的interrupt(),會導致cpu飆升,如果希望StampedLock支持中斷操作,請使用readLockInterruptibly(悲觀讀鎖)與writeLockInterruptibly(寫鎖)。

總結

在讀多寫少的情況下推薦使用StampedLock,因為它的樂觀讀,性能比讀寫鎖提升了很多,但是再其他應用場景中,使用它還需要慎重。

樂觀讀支持併發一個寫鎖,而悲觀讀和寫鎖互斥,所以在使用過程中,我們可以先使用樂觀讀。然後判斷是否存在寫鎖,如果存在,可以升級悲觀讀鎖,由於悲觀讀鎖和寫鎖的互斥性,他能保證線程的安全性問題,如果小明再平時的時候多看看我的博客的話,可能就不會被這個問題難住了。


讓面試不慌張的精選面試資料

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

京東面試追魂三連!有沒有比讀寫鎖更快的鎖?當時我就慌了

領取步驟:
1、轉發+點贊文章
2、關注我,私信“電子書”,即可免費領取



分享到:


相關文章: