Java的Lock接口到底有什么用

本篇內容介紹了“Java的Lock接口到底有什么用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

并發(fā)編程的關鍵是什么，知道嗎?

我淡淡一笑，還好平時就玩的高并發(fā)架構設計，不然真被你唬住了!

• 互斥

同一時刻，只允許一個線程訪問共享資源

• 同步

線程之間通信、協(xié)作

這倆問題，管程都能一把梭。JUC是通過Lock、Condition接口實現(xiàn)的管程：

• Lock

解決互斥

• Condition

解決同步

只見 P8 不慌不忙，又開始問道：

提起這個管程啊，synchronized也是管程的實現(xiàn)呀，既然 JDK 已經(jīng)實現(xiàn)了管程，為什么還要提供另一個實現(xiàn)?

這絕非重復造輪子，它們有很大區(qū)別。最簡單的，在JDK  1.5，synchronized性能差于Lock，但1.6后，synchronized被優(yōu)化，將性能提高，所以1.6后又推薦使用synchronized。但性能問題只要優(yōu)化一下就行了，根本無需“重復造輪子”。

問題的關鍵在于，死鎖問題的破壞“不可搶占”條件，synchronized無法達到該目的。因為synchronized申請資源時，若申請不到，線程直接就被阻塞了，而阻塞態(tài)的線程是無所作為，自然也釋放不了線程已經(jīng)占有的資源。

但我們希望：對于“不可搶占”條件，占用部分資源的線程進一步申請其他資源時，若申請不到，可以主動釋放它已占有的資源，這樣“不可搶占”條件就被破壞掉了。

若重新設計一把互斥鎖去解決這個問題，咋搞呢?如下設計都能破壞“不可搶占”條件：

能響應中斷

使用synchronized持有 鎖X 后，若嘗試獲取 鎖Y  失敗，則線程進入阻塞，一旦死鎖，就再無機會喚醒阻塞線程。但若阻塞態(tài)的線程能夠響應中斷信號，即當給阻塞線程發(fā)送中斷信號時，能喚醒它，那它就有機會釋放曾經(jīng)持有的  鎖X。

支持超時

若線程在一段時間內，都沒有獲取到鎖，不是進入阻塞態(tài)，而是返回一個錯誤，則該線程也有機會釋放曾經(jīng)持有的鎖

非阻塞地獲取鎖

如果嘗試獲取鎖失敗，并不進入阻塞狀態(tài)，而是直接返回，那這個線程也有機會釋放曾經(jīng)持有的鎖

其實就是Lock接口的如下方法：

lockInterruptibly() 支持中斷

tryLock(long time, TimeUnit unit) 支持超時

tryLock() 支持非阻塞獲取鎖

那你知道它是如何保證可見性的嗎?

Lock經(jīng)典案例就是try/finally，必須在finally塊里釋放鎖。Java多線程的可見性是通過Happens-Before規(guī)則保證的，而Happens-Before  并沒有提到 Lock 鎖。那Lock靠什么保證可見性呢?

肯定的，它是利用了volatile的Happens-Before規(guī)則。因為 ReentrantLock 的內部類繼承了  AQS，其內部維護了一個volatile 變量state

• 獲取鎖時，會讀寫state

• 解鎖時，也會讀寫state

所以，執(zhí)行value+=1前，程序先讀寫一次volatile state，在執(zhí)行value+=1后，又讀寫一次volatile  state。根據(jù)Happens-Before的如下規(guī)則判定：

順序性規(guī)則

• 線程t1的value+=1 Happens-Before 線程t1的unlock()

volatile變量規(guī)則

• 由于此時 state為1，會先讀取state，所以線程t1的unlock() Happens-Before 線程t2的lock()

傳遞性規(guī)則

• 線程t的value+=1 Happens-Before 線程t2的lock()

說說什么是可重入鎖?

可重入鎖，就是線程可以重復獲取同一把鎖，示例如下：

聽說過可重入方法嗎?orz，這是什么鬼?P8 看我一時靚仔語塞，就懂了，說到：沒關系，就隨便問問，看看你的知識面。

其實就是多線程可以同時調用該方法，每個線程都能得到正確結果;同時在一個線程內支持線程切換，無論被切換多少次，結果都是正確的。多線程可以同時執(zhí)行，還支持線程切換。所以，可重入方法是線程安全的。

那你來簡單說說公平鎖與非公平鎖吧?

比如ReentrantLock有兩個構造器，一個是無參構造器，一個是傳入fair參數(shù)的。fair參數(shù)代表鎖的公平策略，true：需要構造一個公平鎖，false：構造一個非公平鎖(默認)。

知道鎖的入口等待隊列嗎?

鎖都對應一個等待隊列，如果一個線程沒有獲得鎖，就會進入等待隊列，當有線程釋放鎖的時候，就需要從等待隊列中喚醒一個等待的線程。若是公平鎖，喚醒策略就是誰等待的時間長，就喚醒誰，這很公平  若是非公平鎖，則不提供這個公平保證，所以可能等待時間短的線程被先喚醒。非公平鎖的場景應該是線程釋放鎖之后，如果來了一個線程獲取鎖，他不必去排隊直接獲取到，不會入隊。獲取不到才入隊。

說說你對鎖的一些最佳實踐

鎖并非解決并發(fā)問題的銀彈，風險很高，比如各種隨處可見的死鎖，還影響性能。并發(fā)大師Doug Lea的最佳實踐：

• 永遠只在更新對象的成員變量時加鎖

• 永遠只在訪問可變的成員變量時加鎖

• 永遠不在調用其他對象的方法時加鎖  因為調用其他對象的方法，實在是太不安全了，也許“其他”方法里面有線程sleep()的調用，也可能會有奇慢無比的I/O操作，這些都會嚴重影響性能。更可怕的是，“其他”類的方法可能也會加鎖，然后雙重加鎖就可能導致死鎖。

還有一些常見的比如只在該加鎖的地方加鎖。

最后拓展一些小知識點：

• notifyAll()  在面對公平鎖和非公平鎖的時候，效果一樣。所有等待隊列中的線程全部被喚醒，統(tǒng)統(tǒng)到入口等待隊列中排隊?這些被喚醒的線程不用根據(jù)等待時間排隊再放入入口等待隊列中了吧?都被喚醒。理論上是同時進入入口等待隊列，等待時間是相同的。

• CPU層面的原子性是單條cpu指令。Java層面的互斥(管程)保證了原子性。這兩個原子性意義不一樣。cpu的原子性是不受線程調度影響，指令要不執(zhí)行了，要么沒執(zhí)行。而Java層面的原子性是在鎖的機制下保證只有一個線程執(zhí)行，其余等待，此時cpu還是可以進行線程調度，使運行中的那個線程讓出cpu時間，當然了該線程還是掌握鎖。

“Java的Lock接口到底有什么用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！