前言
鎖的原因都是由并發問題發生的,在此我只是寫一些面試中可能會問到的問題以及問題的答案,并不是給大家深入的講解鎖機制
一般面試官問都是從一個點引入一個點的問問題,所以我就先從執行緒問題引入到鎖問題
正文
1.說說執行緒安全問題
執行緒安全是多執行緒領域的問題,執行緒安全可以簡單理解為一個方法或者一個實體可以在多執行緒環境中使用而不會出現問題
在 Java 多執行緒編程當中,提供了多種實作 Java 執行緒安全的方式:
- 最簡單的方式,使用 Synchronization 關鍵字
- 使用 java.util.concurrent.atomic 包中的原子類,例如 AtomicInteger
- 使用 java.util.concurrent.locks 包中的鎖
- 使用執行緒安全的集合 ConcurrentHashMap
- 使用 volatile 關鍵字,保證變數可見性(直接從記憶體讀,而不是從執行緒 cache 讀)
2.volatile 實作原理
在 JVM 底層 volatile 是采用“記憶體屏障”來實作的
快取一致性協議(MESI協議)它確保每個快取中使用的共享變數的副本是一致的,其核心思想如下:當某個 CPU 在寫資料時,如果發現操作的變數是共享變數,則會通知其他 CPU 告知該變數的快取行是無效的,因此其他 CPU 在讀取該變數時,發現其無效會重新從主存中加載資料
3.synchronize 實作原理
同步代碼塊是使用 monitorenter 和 monitorexit 指令實作的,同步方法(在這看不出來需要看 JVM 底層實作)依靠的是方法修飾符上的 ACC_SYNCHRONIZED 實作
4.synchronized 與 lock 的區別
synchronized 和 lock 的用法區別
- synchronized(隱式鎖):在需要同步的物件中加入此控制,synchronized
可以加在方法上,也可以加在特定代碼塊中,括號中表示需要鎖的物件 - lock(顯示鎖):需要顯示指定起始位置和終止位置,一般使用 ReentrantLock 類做為鎖,多個執行緒中必須要使用一個
ReentrantLock 類做為物件才能保證鎖的生效,且在加鎖和解鎖處需要通過 lock() 和 unlock()
顯示指出,所以一般會在 finally 塊中寫 unlock() 以防死鎖
synchronized 和 lock 性能區別
synchronized 是托管給 JVM 執行的,而 lock 是 Java 寫的控制鎖的代碼,在 JDK 1.5 中,synchronize 是性能低效的,因為這是一個重量級操作,需要呼叫操作介面,導致有可能加鎖消耗的系統時間比加鎖以外的操作還多,相比之下使用 Java 提供的 Lock 物件,性能更高一些,但是到了 JDK 1.6,發生了變化,synchronize 在語意上很清晰,可以進行很多優化,有適應自旋,鎖消除,鎖粗化,輕量級鎖,偏向鎖等等,導致在 JDK 1.6 上 synchronize 的性能并不比 Lock 差
synchronized 和 lock 機制區別
synchronized 原始采用的是 CPU 悲觀鎖機制,即執行緒獲得的是獨占鎖,獨占鎖意味著其 他執行緒只能依靠阻塞來等待執行緒釋放鎖
Lock 用的是樂觀鎖方式,所謂樂觀鎖就是,每次不加鎖而是假設沒有沖突而去完成某項操作,如果因為沖突失敗就重試,直到成功為止,樂觀鎖實作的機制就是 CAS 操作(Compare and Swap)
由此面試官就可能下一個問題就接入到鎖的問題上,當然也可能前面的問題回答不上,引入不到鎖上,但是面試官想問時會主動問到吧
5.說說悲觀鎖
悲觀鎖悲觀的認為每一次操作都會造成更新丟失問題,在每次查詢時加上排他鎖
每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖,傳統的關系型資料庫里邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖
6.說說常用的 CAS 樂觀鎖
CAS 是項樂觀鎖技術,當多個執行緒嘗試使用 CAS 同時更新同一個變數時,只有其中一個執行緒能更新變數的值,而其它執行緒都失敗,失敗的執行緒并不會被掛起,而是被告知這次競爭中失敗,并可以再次嘗試
CAS 操作包含三個運算元 —— 記憶體位置(V)、預期原值(A)和新值(B),如果記憶體位置的值與預期原值相匹配,那么處理器會自動將該位置值更新為新值,否則,處理器不做任何操作,無論哪種情況,它都會在 CAS 指令之前回傳該位置的值,(在 CAS 的一些特殊情況下將僅回傳 CAS 是否成功,而不提取當前值,)CAS 有效地說明了“我認為位置 V 應該包含值 A;如果包含該值,則將 B 放到這個位置;否則,不要更改該位置,只告訴我這個位置現在的值即可,”這其實和樂觀鎖的沖突檢查 + 資料更新的原理是一樣的
每次查詢都不會造成更新丟失,利用版本欄位控制
7.說說 CAS ‘ABA’ 問題
CAS 演算法實作一個重要前提需要取出記憶體中某時刻的資料,而在下時刻比較并替換,那么在這個時間差類會導致資料的變化
比如說一個執行緒 one 從記憶體位置 V 中取出 A,這時候另一個執行緒 two 也從記憶體中取出 A,并且 two 進行了一些操作變成了 B,然后 two 又將 V 位置的資料變成 A,這時候執行緒 one 進行 CAS 操作發現記憶體中仍然是 A,然后 one 操作成功,盡管執行緒 one 的 CAS 操作成功,但是不代表這個程序就是沒有問題的,部分樂觀鎖的實作是通過版本號(version)的方式來解決 ABA 問題,樂觀鎖每次在執行資料的修改操作時,都會帶上一個版本號,一旦版本號和資料的版本號一致就可以執行修改操作并對版本號執行 +1 操作,否則就執行失敗,因為每次操作的版本號都會隨之增加,所以不會出現 ABA 問題,因為版本號只會增加不會減少
8.樂觀鎖的業務場景及實作方式
樂觀鎖(Optimistic Lock):
每次獲取資料的時候,都不會擔心資料被修改,所以每次獲取資料的時候都不會進行加鎖,但是在更新資料的時候需要判斷該資料是否被別人修改過,如果資料被其他執行緒修改,則不進行資料更新,如果資料沒有被其他執行緒修改,則進行資料更新,由于資料沒有進行加鎖,期間該資料可以被其他執行緒進行讀寫操作
比較適合讀取操作比較頻繁的場景,如果出現大量的寫入操作,資料發生沖突的可能性就會增大,為了保證資料的一致性,應用層需要不斷的重新獲取資料,這樣會增加大量的查詢操作,降低了系統的吞吐量
8.簡單講講自旋鎖
自旋鎖是采用讓當前執行緒不停地的在回圈體內執行實作的,當回圈的條件被其他執行緒改變時 才能進入臨界區
當一個執行緒 呼叫這個不可重入的自旋鎖去加鎖的時候沒問題,當再次呼叫lock()的時候,因為自旋鎖的持有參考已經不為空了,該執行緒物件會誤認為是別人的執行緒持有了自旋鎖
使用了CAS原子操作,lock函式將owner設定為當前執行緒,并且預測原來的值為空,unlock函式將owner設定為null,并且預測值為當前執行緒,
當有第二個執行緒呼叫lock操作時由于owner值不為空,導致回圈一直被執行,直至第一個執行緒呼叫unlock函式將owner設定為null,第二個執行緒才能進入臨界區,
由于自旋鎖只是將當前執行緒不停地執行回圈體,不進行執行緒狀態的改變,所以回應速度更快,但當執行緒數不停增加時,性能下降明顯,因為每個執行緒都需要執行,占用CPU時間,如果執行緒競爭不激烈,并且保持鎖的時間段,適合使用自旋鎖
題外
本文章限于篇幅只放出了部分資料,近段時間正值找作業的最佳時間,本人將一些各大廠商的面試題和今年(2020)最新資料的收集,以下是部分資料截圖(所有資料均已整合成檔案,pdf壓縮打包處理),
如果你需要全部的關于JAVA面試題和2020最新的資料可以點擊這里來獲取,暗號:qf

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/83844.html
標籤:其他
上一篇:Java深入篇~03.陣列的排序演算法(JDK1.8)
下一篇:最通俗易懂的ssm框架整合講解
