鎖的四種狀態與鎖升級過程
一、前言
鎖的狀態總共有四種，級別由低到高依次為：無鎖、偏向鎖、輕量級鎖、重量級鎖，這四種鎖狀態分別代表什么，為什么會有鎖升級?其實在 JDK 1.6之前，synchronized 還是一個重量級鎖，是一個效率比較低下的鎖，但是在JDK 1.6后，Jvm為了提高鎖的獲取與釋放效率對(synchronized )進行了優化，引入了 偏向鎖 和 輕量級鎖 ，從此以后鎖的狀態就有了四種(無鎖、偏向鎖、輕量級鎖、重量級鎖)，并且四種狀態會隨著競爭的情況逐漸升級，而且是不可逆的過程，即不可降級，也就是說只能進行鎖升級(從低級別到高級別)，不能鎖降級(高級別到低級別)，意味著偏向鎖升級成輕量級鎖后不能降級成偏向鎖。這種鎖升級卻不能降級的策略，目的是為了提高獲得鎖和釋放鎖的效率。
二、鎖的四種狀態
在 synchronized 最初的實現方式是 “阻塞或喚醒一個Java線程需要操作系統切換CPU狀態來完成，這種狀態切換需要耗費處理器時間，如果同步代碼塊中內容過于簡單，這種切換的時間可能比用戶代碼執行的時間還長”，這種方式就是 synchronized實現同步最初的方式，這也是當初開發者詬病的地方，這也是在JDK6以前 synchronized效率低下的原因，JDK6中為了減少獲得鎖和釋放鎖帶來的性能消耗，引入了“偏向鎖”和“輕量級鎖”。
所以目前鎖狀態一種有四種，從級別由低到高依次是：無鎖、偏向鎖，輕量級鎖，重量級鎖，鎖狀態只能升級，不能降級
如圖所示：
三、鎖狀態的思路以及特點
四、鎖對比
五、Synchronized鎖
synchronized 用的鎖是存在Java對象頭里的，那么什么是對象頭呢?
5.1 Java 對象頭
我們以 Hotspot 虛擬機為例，Hopspot 對象頭主要包括兩部分數據：MarkWord(標記字段)和KlassPointer(類型指針)
Mark Word：默認存儲對象的HashCode，分代年齡和鎖標志位信息。這些信息都是與對象自身定義無關的數據，所以Mark Word被設計成一個非固定的數據結構以便在極小的空間內存存儲盡量多的數據。它會根據對象的狀態復用自己的存儲空間，也就是說在運行期間Mark Word里存儲的數據會隨著鎖標志位的變化而變化。
Klass Point：對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。
在上面中我們知道了， synchronized 用的鎖是存在Java對象頭里的，那么具體是存在對象頭哪里呢?答案是：存在鎖對象的對象頭的Mark Word中，那么MarkWord在對象頭中到底長什么樣，它到底存儲了什么呢?
在64位的虛擬機中：
在32位的虛擬機中：
下面我們以 32位虛擬機為例，來看一下其 Mark Word 的字節具體是如何分配的
無鎖：對象頭開辟 25bit 的空間用來存儲對象的 hashcode ，4bit 用于存放對象分代年齡，1bit 用來存放是否偏向鎖的標識位，2bit 用來存放鎖標識位為01
偏向鎖： 在偏向鎖中劃分更細，還是開辟 25bit 的空間，其中23bit 用來存放線程ID，2bit 用來存放 Epoch，4bit 存放對象分代年齡，1bit 存放是否偏向鎖標識， 0表示無鎖，1表示偏向鎖，鎖的標識位還是01
輕量級鎖：在輕量級鎖中直接開辟 30bit 的空間存放指向棧中鎖記錄的指針，2bit 存放鎖的標志位，其標志位為00
重量級鎖： 在重量級鎖中和輕量級鎖一樣，30bit 的空間用來存放指向重量級鎖的指針，2bit 存放鎖的標識位，為11
GC標記： 開辟30bit 的內存空間卻沒有占用，2bit 空間存放鎖標志位為11。
其中無鎖和偏向鎖的鎖標志位都是01，只是在前面的1bit區分了這是無鎖狀態還是偏向鎖狀態
關于內存的分配，我們可以在git中openJDK中 markOop.hpp 可以看出：
- public:
- // Constants
- enum { age_bits = 4,
- lock_bits = 2,
- biased_lock_bits = 1,
- max_hash_bits = BitsPerWord - age_bits - lock_bits - biased_lock_bits,
- hash_bits = max_hash_bits > 31 ? 31 : max_hash_bits,
- cms_bits = LP64_ONLY(1) NOT_LP64(0),
- epoch_bits = 2
- };
- age_bits： 就是我們說的分代回收的標識，占用4字節
- lock_bits： 是鎖的標志位，占用2個字節
- biasedlockbits： 是是否偏向鎖的標識，占用1個字節
- maxhashbits： 是針對無鎖計算的hashcode 占用字節數量，如果是32位虛擬機，就是 32 - 4 - 2 -1 = 25 byte，如果是64 位虛擬機，64 - 4 - 2 - 1 = 57 byte，但是會有 25 字節未使用，所以64位的 hashcode 占用 31 byte
- hash_bits： 是針對 64 位虛擬機來說，如果最大字節數大于 31，則取31，否則取真實的字節數
- cms_bits： 不是64位虛擬機就占用 0 byte，是64位就占用 1byte
- epoch_bits： 就是 epoch 所占用的字節大小，2字節。
5.2 Monitor
Monitor 可以理解為一個同步工具或一種同步機制，通常被描述為一個對象。每一個 Java 對象就有一把看不見的鎖，稱為內部鎖或者 Monitor 鎖。
Monitor 是線程私有的數據結構，每一個線程都有一個可用 monitor record 列表，同時還有一個全局的可用列表。每一個被鎖住的對象都會和一個 monitor 關聯，同時 monitor 中有一個 Owner 字段存放擁有該鎖的線程的唯一標識，表示該鎖被這個線程占用。
Synchronized是通過對象內部的一個叫做監視器鎖(monitor)來實現的，監視器鎖本質又是依賴于底層的操作系統的 Mutex Lock(互斥鎖)來實現的。而操作系統實現線程之間的切換需要從用戶態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間，這就是為什么 Synchronized 效率低的原因。因此，這種依賴于操作系統 Mutex Lock 所實現的鎖我們稱之為重量級鎖。
隨著鎖的競爭，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖(但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級)。JDK 1.6中默認是開啟偏向鎖和輕量級鎖的，我們也可以通過-XX:-UseBiasedLocking=false來禁用偏向鎖。
六、鎖的分類
6.2 無鎖
無鎖是指沒有對資源進行鎖定，所有的線程都能訪問并修改同一個資源，但同時只有一個線程能修改成功。
無鎖的特點是修改操作會在循環內進行，線程會不斷的嘗試修改共享資源。如果沒有沖突就修改成功并退出，否則就會繼續循環嘗試。如果有多個線程修改同一個值，必定會有一個線程能修改成功，而其他修改失敗的線程會不斷重試直到修改成功。
6.3 偏向鎖
初次執行到synchronized代碼塊的時候，鎖對象變成偏向鎖(通過CAS修改對象頭里的鎖標志位)，字面意思是“偏向于第一個獲得它的線程”的鎖。執行完同步代碼塊后，線程并不會主動釋放偏向鎖。當第二次到達同步代碼塊時，線程會判斷此時持有鎖的線程是否就是自己(持有鎖的線程ID也在對象頭里)，如果是則正常往下執行。由于之前沒有釋放鎖，這里也就不需要重新加鎖。如果自始至終使用鎖的線程只有一個，很明顯偏向鎖幾乎沒有額外開銷，性能極高。
偏向鎖是指當一段同步代碼一直被同一個線程所訪問時，即不存在多個線程的競爭時，那么該線程在后續訪問時便會自動獲得鎖，從而降低獲取鎖帶來的消耗，即提高性能。
當一個線程訪問同步代碼塊并獲取鎖時，會在 Mark Word 里存儲鎖偏向的線程 ID。在線程進入和退出同步塊時不再通過 CAS 操作來加鎖和解鎖，而是檢測 Mark Word 里是否存儲著指向當前線程的偏向鎖。輕量級鎖的獲取及釋放依賴多次 CAS 原子指令，而偏向鎖只需要在置換 ThreadID 的時候依賴一次 CAS 原子指令即可。
偏向鎖只有遇到其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程才會釋放鎖，線程是不會主動釋放偏向鎖的。
關于偏向鎖的撤銷，需要等待全局安全點，即在某個時間點上沒有字節碼正在執行時，它會先暫停擁有偏向鎖的線程，然后判斷鎖對象是否處于被鎖定狀態。如果線程不處于活動狀態，則將對象頭設置成無鎖狀態，并撤銷偏向鎖，恢復到無鎖(標志位為01)或輕量級鎖(標志位為00)的狀態。
6.4 輕量級鎖(自旋鎖)
輕量級鎖是指當鎖是偏向鎖的時候，卻被另外的線程所訪問，此時偏向鎖就會升級為輕量級鎖，其他線程會通過自旋(關于自旋的介紹見文末)的形式嘗試獲取鎖，線程不會阻塞，從而提高性能。
輕量級鎖的獲取主要由兩種情況：① 當關閉偏向鎖功能時;② 由于多個線程競爭偏向鎖導致偏向鎖升級為輕量級鎖。
一旦有第二個線程加入鎖競爭，偏向鎖就升級為輕量級鎖(自旋鎖)。這里要明確一下什么是鎖競爭：如果多個線程輪流獲取一個鎖，但是每次獲取鎖的時候都很順利，沒有發生阻塞，那么就不存在鎖競爭。只有當某線程嘗試獲取鎖的時候，發現該鎖已經被占用，只能等待其釋放，這才發生了鎖競爭。
在輕量級鎖狀態下繼續鎖競爭，沒有搶到鎖的線程將自旋，即不停地循環判斷鎖是否能夠被成功獲取。獲取鎖的操作，其實就是通過CAS修改對象頭里的鎖標志位。先比較當前鎖標志位是否為“釋放”，如果是則將其設置為“鎖定”，比較并設置是原子性發生的。這就算搶到鎖了，然后線程將當前鎖的持有者信息修改為自己。
長時間的自旋操作是非常消耗資源的，一個線程持有鎖，其他線程就只能在原地空耗CPU，執行不了任何有效的任務，這種現象叫做忙等(busy-waiting)。如果多個線程用一個鎖，但是沒有發生鎖競爭，或者發生了很輕微的鎖競爭，那么synchronized就用輕量級鎖，允許短時間的忙等現象。這是一種折衷的想法，短時間的忙等，換取線程在用戶態和內核態之間切換的開銷。
6.4 重量級鎖
重量級鎖顯然，此忙等是有限度的(有個計數器記錄自旋次數，默認允許循環10次，可以通過虛擬機參數更改)。如果鎖競爭情況嚴重，某個達到最大自旋次數的線程，會將輕量級鎖升級為重量級鎖(依然是CAS修改鎖標志位，但不修改持有鎖的線程ID)。當后續線程嘗試獲取鎖時，發現被占用的鎖是重量級鎖，則直接將自己掛起(而不是忙等)，等待將來被喚醒。
重量級鎖是指當有一個線程獲取鎖之后，其余所有等待獲取該鎖的線程都會處于阻塞狀態。
簡言之，就是所有的控制權都交給了操作系統，由操作系統來負責線程間的調度和線程的狀態變更。而這樣會出現頻繁地對線程運行狀態的切換，線程的掛起和喚醒，從而消耗大量的系統資
五、總結
文中講述了鎖的四種狀態以及鎖是如何一步一步升級的過程，
