文章目錄
- 物件頭
- Monitor(synchronized的重量鎖通過它來實作)
- 機制
- wait()、notify()
- 偏向鎖
- 存在意義
- 應用場景(就是通過什么場景發現synchronized需要優化，進而誕生偏向鎖)
- 偏向鎖的設計
- 主體思想
- 開啟了偏向鎖的無鎖->偏向鎖->輕量鎖
- 重偏向
- 執行緒復用執行緒id
- 列印初始化資訊
- 批量重偏向
- 批量重偏向撤銷
- 輕量鎖
- 存在意義
- 使用場景
- 輕量鎖的設計
- 加鎖
- 解鎖
- 鎖的優缺點及整體設計思想
- 🔗
物件頭
假如物件是非陣列型別，則沒有 Array Length這一項，
從上往下分別是 無鎖，偏向鎖，輕量鎖，重量鎖，GC標記，
Monitor(synchronized的重量鎖通過它來實作)
機制
- _owner 指向持有ObjectMonitor物件的執行緒地址，
- _WaitSet 存放呼叫wait方法，而進入等待狀態的執行緒的佇列，
- _EntryList 這里是等待鎖block狀態的執行緒的佇列，
- _recursions 鎖的重入次數，
- _count 執行緒獲取鎖的次數，
wait()、notify()
偏向鎖
存在意義
偏向鎖的目標是減少昂貴的原子指令CAS(Compare And Swap)等的使用(相比輕量鎖減少了CAS,當然更減少了os的介入)，Monitor里面也有可重入機制，就不會重新將該物件對應的Monitor里面的Owner改變了，(個人認為：這里應該不涉及到互斥信號量的分配問題，就算是 不是同一個執行緒競爭到了鎖也不會重新分配mutex呀，這個物件對應的monitor早都分配好了呀不需重新分配，)
應用場景(就是通過什么場景發現synchronized需要優化，進而誕生偏向鎖)
- 類加載程序有很多方法都是加sychronized鎖的，雖然可以并發地進行類加載，但大多數情況都是由main執行緒完成，(我不知道！網上看的，不知道是不是main執行緒！錯了別打我，就是舉個例子)
- 一些舊版本的庫(Vector、HashTable等？)
偏向鎖的設計
如若默認情況下偏向鎖開啟被延遲的話，-XX:BiasedLockingStartupDelay=0 可關于延遲，
如果確定應用程式里所有的鎖通常情況下處于競爭狀態，可以通過JVM引數關閉偏向鎖，
(畢竟，，，，，，，，，，，，，，，，，，，，，，，)
主體思想
%%%%%%%%%%%%%%
假如開啟了偏向鎖，當一個執行緒訪問同步塊并獲取鎖時，會在物件頭存盤鎖偏向的執行緒ID，以后該執行緒在進入和退出同步塊時不需要進行CAS操作來加鎖和解鎖：
開啟了偏向鎖的無鎖->偏向鎖->輕量鎖
biased_lock=1，
剛開始無鎖(這個無鎖指的是沒被任何執行緒進入過，不是不具備偏向鎖，偏向鎖不是一個真正的鎖，就是代碼層面去控制它而已)，假如一個執行緒需要訪問該同步塊，則：
這個時候物件頭的MarkWord(threId=null)沒有存盤著當前執行緒的偏向鎖，通過CAS將物件頭偏向鎖的執行緒ID指向當前執行緒來競爭鎖，變為：
這次CAS也可能競爭失敗，也許被其他執行緒搶先了，(T__T)
- 一個執行緒在執行完同步代碼塊以后， 并不會嘗試將 MarkWord 中的 thread ID 賦回原來的值 ，這樣做的好處是： 如果該執行緒需要再次對這個物件加鎖，而這個物件之前一直沒有被其他執行緒嘗試獲取過鎖，依舊停留在可偏向的狀態下， 即可在不修改物件頭的情況下(即不使用CAS)， 直接認為偏向成功，
- (只要threadID有值,且epoch不過期，CAS就一定會失敗) 如果 CAS 操作失敗， 則說明， 有另外一個執行緒 Thread B 搶先獲取了偏向鎖， 這種狀態說明該物件的競爭比較激烈， 此時需要撤銷 Thread B 獲得的偏向鎖，將 Thread B 持有的鎖升級為輕量級鎖(也可能重偏向)， 該操作需要等待全域安全點 JVM safepoint ( 此時間點， 沒有執行緒在執行位元組碼) ，
重偏向
%%%%%%%%%%%%%%%%%
執行緒復用執行緒id
注釋代碼開啟空執行緒后，執行緒id不同，不會被復用，而列印結果如下：(只是一種現象，沒去看底層原始碼)
列印初始化資訊
-XX:+PrintFlagsInitial
批量重偏向
批量重偏向撤銷
輕量鎖
輕量級鎖加鎖方式：
CAS（設定物件頭輕量級鎖標志）-> 執行代碼塊 -> CAS（重置物件頭輕量級鎖標志）
CAS相對于monitorenter和monitorexit的代價更小
存在意義
輕量級鎖不是為了替換重量級鎖的而是為了減少使用重量級鎖，當輕量級鎖失敗后，會升級為重量級鎖，輕量鎖的目標是減少os的介入,減少系統呼叫(導致內核用戶來回切換)，重量鎖會讓得不到鎖的執行緒阻塞，回涉及到內核用戶態的切換，很耗費時間，
使用場景
輕量鎖會先讓執行緒自旋一下等待鎖，往往使用于多個執行緒串行訪問同步塊，或者競爭沒那么大的時候，
輕量鎖的設計
一個執行緒能同時訪問一個加鎖的方法嗎？好像不行吧(偏向鎖的出現是因為：同一個執行緒多次串行訪問一個同步塊，每次采用重鎖又要每次都要嘗試CAS將Monitor里面的ower(指的是擁有Monitor鎖的執行緒)從null改為自己,是否成功，而且就算成功了，也需要通過底層os的實作，其實這里我是不太懂的，)，所以根本不會出現輕量鎖重入的情況，同一個執行緒只是串行訪問一個同步塊，輕量鎖每次訪問完就解鎖，怎么會重入呢？一些博客簡直在胡扯，
加鎖
否則自旋獲取鎖一段事件后還是失敗，則膨脹為重量級鎖，
解鎖
使用CAS將物件頭替換為當前執行緒的堆疊幀中存盤鎖記錄空間的MarkWord，若果成功，則表示沒有競爭發生，解鎖成功，若失敗，表示當前鎖存在競爭，鎖可能已經升級為重量鎖，則采用重量級解鎖(見Monitor)，
鎖的優缺點及整體設計思想
🔗
大佬太強了%%%%%：Java精通并發-通過openjdk原始碼分析ObjectMonitor底層實作
好想去找男朋友啊啊啊
不要男朋友了
我看不懂看不懂看不懂！：關于偏向鎖,安全點,JIT的一些暗坑.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/187672.html
標籤：其他
上一篇：并發一（基本概念及理論準備）