自适應自旋鎖
所謂自适應就意味着自旋的次數不再是固定的，它由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀态來決定。
具體怎麼做的呢？
線程如果自旋成功了，那麼下次自旋的次數會更多，因為虛拟機認為既然上次成功了，那麼此次自旋也很有可能會再次成功，那麼它就會允許自旋等待持續的次數更多。反之，如果對于某個鎖，很少有自旋能夠成功的，那麼在以後要或者這個鎖的時候自旋的次數會減少甚至省略掉自旋過程，以免浪費處理器資源。
有了自适應自旋鎖，随着程式運作和性能監控資訊的不斷完善，虛拟機對程式鎖的狀況預測會越來越準确，虛拟機會變得越來越聰明。
鎖消除
為了保證資料的完整性，我們在進行操作時需要對這部分操作進行同步控制，但是在有些情況下，JVM檢測到不可能存在共享資料競争，這時JVM會對這些同步鎖進行鎖消除。
鎖消除的依據是逃逸分析的資料支援。
如果不存在競争，為什麼還需要加鎖呢？是以鎖消除可以節省毫無意義的請求鎖的時間。
變量是否逃逸，對于虛拟機來說需要使用資料流分析來确定，但是對于我們程式員來說這還不清楚麼？但有時候程式并不是我們所想的那樣,我們雖然沒有顯示使用鎖，但是我們在使用一些JDK的内置API時，如StringBuffer、Vector、HashTable等，這時候會存在隐形的加鎖操作。比如StringBuffer的append()方法，Vector的add()方法
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}
System.out.println(vector);
} 在運作這段代碼時，JVM可以明顯檢測到變量vector沒有逃逸出方法vectorTest()之外，是以JVM可以大膽地将vector内部的加鎖操作消除。
鎖粗化
我們知道在使用同步鎖的時候，需要讓同步塊的作用範圍盡可能小,即僅在共享資料的實際作用域中才進行同步，這樣做的目的是為了使需要同步的操作數量盡可能小，如果存在鎖競争，那麼等待鎖的線程也能盡快拿到鎖
在大多數的情況下，上述觀點是正确的，本人也一直堅持着這個觀點。但是如果一系列的連續加鎖解鎖操作，可能會導緻不必要的性能損耗，是以引入鎖粗化的概念:
就是将多個連續的加鎖、解鎖操作連接配接在一起，擴充成一個範圍更大的鎖
如上面執行個體：vector每次add的時候都需要加鎖操作，JVM檢測到對同一個對象（vector）連續加鎖、解鎖操作，會合并一個更大範圍的加鎖、解鎖操作，即加鎖解鎖操作會移到for循環外
輕量級鎖
主要目的是在沒有多線程競争的前提下，減少傳統的重量級鎖使用OS的互斥量(mutex)産生的性能消耗。
當關閉偏向鎖功能或者多個線程競争偏向鎖導緻偏向鎖更新為輕量級鎖，則會嘗試擷取輕量級鎖，其步驟如下：
擷取鎖
1。 判斷目前對象是否處于無鎖狀态（hashcode、0、01）
-
是
JVM将首先在目前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced字首，即Displaced Mark Word）
-
否
執行3
- JVM利用CAS操作嘗試将對象的Mark Word更新為指向Lock Record的指正
-
成功(表示競争到鎖)
将鎖标志位變成00（表示此對象處于輕量級鎖狀态），執行同步操作
- 失敗
- 判斷目前對象的Mark Word是否指向目前線程的棧幀
-
是(表示目前線程已經持有目前對象的鎖)
直接執行同步代碼塊
-
否(隻能說明該鎖對象已經被其他線程搶占)
輕量級鎖需要膨脹為重量級鎖，鎖标志位變成10，後面等待的線程将會進入阻塞狀态
釋放鎖
輕量級鎖的釋放也是通過CAS操作來進行的，主要步驟如下：
- 取出擷取輕量級鎖時儲存在Displaced Mark Word中的資料
- 用CAS操作将取出的資料替換到目前對象的Mark Word中
-
-
成功
說明釋放鎖成功
-
- CAS操作替換失敗，說明有其他線程嘗試擷取該鎖，則需要在釋放鎖的同時需要喚醒被挂起的線程
對于輕量級鎖，其性能提升的依據是
“對于絕大部分的鎖，在整個生命周期内都是不會存在競争的”
如果打破這個依據則除了互斥的開銷外，還有額外的CAS操作，是以在有多線程競争的情況下，輕量級鎖比重量級鎖更慢
下圖是輕量級鎖的擷取和釋放過程
偏向鎖
隻需要把自己的線程 id 記錄到對象對的 markword 的 id 裡即可.
目的：在無多線程競争的情況下盡量減少不必要的輕量級鎖執行路徑。
上面提到了輕量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的。
那麼偏向鎖是如何來減少不必要的CAS操作呢？
我們可以檢視Mark work的結構就明白了。
隻需要檢查是否為偏向鎖、鎖辨別為以及ThreadID即可，處理流程如下：
- 檢測Mark Word是否為可偏向狀态，即是否為偏向鎖1，鎖辨別位為01
- 若為可偏向狀态，則測試線程ID是否為目前線程ID
-
- 執行5
- 如果線程ID不為目前線程ID，則通過CAS操作競争鎖,競争
- 将Mark Word的線程ID替換為目前線程ID，
- 執行4
- CAS競争鎖失敗，證明目前存在多線程競争情況，當到達全局安全點，獲得偏向鎖的線程被挂起，偏向鎖更新為輕量級鎖，然後被阻塞在安全點的線程繼續往下執行同步代碼塊
- 執行同步代碼塊
偏向鎖的釋放采用了一種隻有競争才會釋放鎖的機制，線程是不會主動去釋放偏向鎖，需要等待其他線程來競争。
偏向鎖的撤銷需要等待全局安全點（這個時間點是上沒有正在執行的代碼）。其步驟如下：
- 暫停擁有偏向鎖的線程，判斷鎖對象石是否還處于被鎖定狀态
- 撤銷偏向鎖，恢複到無鎖狀态（01）或者輕量級鎖的狀态
下圖是偏向鎖的擷取和釋放流程
重量級鎖
重量級鎖通過對象内部的螢幕（monitor）實作，其中monitor的本質是依賴于底層作業系統的Mutex Lock實作，作業系統實作線程之間的切換需要從使用者态到核心态的切換，切換成本非常高。