synchronized 鎖優化:html
JDK1.6對鎖的實現引入了大量的優化,如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減小鎖操做的開銷。 三種不一樣的鎖:偏向鎖、輕量級鎖和重量級鎖。java
所謂鎖的升級,降級就是JVM優化synchronized運行的機制,當JVM檢測到不一樣的競爭狀態時,會自動切換到適合的鎖實現,這種切換就是鎖的升級,降級。程序員
偏向鎖:當沒有競爭出現時,默認會使用偏向鎖。JVM會利用CAS操做,在對象頭上的Mark Word部分設置線程ID,以表示這個對象偏向與當前線程,因此並不涉及真正的戶斥鎖。數組
輕量級鎖:當有另外的線程試圖鎖定某個已經被偏向過的對象,JVM就撤銷偏向鎖,切換到輕量級鎖。安全
synchronized用的鎖是存在Java對象頭裏的,那麼什麼是Java對象頭呢?多線程
Hotspot虛擬機的對象頭主要包括兩部分數據:Mark Word(標記字段)、Klass Pointer(類型指針)。其中Klass Point是是對象指向它的類元數據的指針,虛擬機經過這個指針來肯定這個對象是哪一個類的實例,Mark Word用於存儲對象自身的運行時數據,它是實現輕量級鎖和偏向鎖的關鍵。併發
Mark Word用於存儲對象自身的運行時數據,如哈希碼(HashCode)、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程 ID、偏向時間戳等等。Java對象頭通常佔有兩個機器碼(在32位虛擬機中,1個機器碼等於4字節,也就是32bit),可是若是對象是數組類型,則須要三個機器碼,由於JVM虛擬機能夠經過Java對象的元數據信息肯定Java對象的大小,可是沒法從數組的元數據來確認數組的大小,因此用一塊來記錄數組長度。app
鎖主要存在四中狀態,依次是:無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態。他們會隨着競爭的激烈而逐漸升級。注意鎖能夠升級不可降級,這種策略是爲了提升得到鎖和釋放鎖的效率。性能
---------------------------總結----------------------------------測試
自旋鎖:就是讓該線程等待一段時間,不會被當即掛起,看持有鎖的線程是否會很快釋放鎖。
自旋鎖就是競爭失敗的線程,並不會馬上在操做系統層面掛起等待,而是JVM讓線程作幾個空循環,基於預測在不久的未來就能得到鎖,在通過幾回循環後,若是能夠得到鎖,那麼進入臨界區,若是尚未得到,纔會真正將線程在操做系統層面掛起等待。優勢減小上下文切換,在競爭不激烈且鎖佔用時間很是短但代碼塊來講會有較大的性能提高,由於自旋的消耗小雨線程阻塞掛起的消耗。但對於競爭激烈和鎖佔用時間較長的代碼塊,會更多的額外作空轉操做,作無用功,消耗CPU。
在JDK1.6中默認開啓。同時自旋的默認次數爲10次,能夠經過參數-XX:PreBlockSpin來調整。
適應自旋鎖:JDK 1.6引入了更加聰明的自旋鎖,即自適應自旋鎖。所謂自適應就意味着自旋的次數再也不是固定的,它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定,動態調整:線程若是自旋成功了,那麼下次自旋的次數會更加多。
鎖消除:JVM檢測到不可能存在共享數據競爭,這時JVM會對這些同步鎖進行鎖消除。鎖消除的依據是逃逸分析的數據支持。
鎖粗化:就是將多個連續的加鎖、解鎖操做鏈接在一塊兒,擴展成一個範圍更大的鎖。
若是一系列的連續加鎖解鎖操做,可能會致使沒必要要的性能損耗,因此引入鎖粗化的概念。
偏向鎖:在無多線程競爭的狀況下儘可能減小沒必要要的輕量級鎖執行路徑。
比輕量級鎖,減小CAS執行次數。只須要檢查是否爲偏向鎖、鎖標識爲以及ThreadID便可
檢測Mark Word是否爲可偏向狀態,
測試線程ID是否爲當前線程ID,
不是當前線程ID,則經過CAS操做競爭鎖,競爭成功,則將Mark Word的線程ID替換爲當前線程ID
經過CAS競爭鎖失敗,證實當前存在多線程競爭狀況,當到達全局安全點,得到偏向鎖的線程被掛起,偏向鎖升級爲輕量級鎖,而後被阻塞在安全點的線程繼續往下執行同步代碼塊;
執行同步代碼塊。
輕量級鎖:減小傳統的重量級鎖使用操做系統互斥量產生的性能消耗。
當關閉偏向鎖功能或者多個線程競爭偏向鎖致使偏向鎖升級爲輕量級鎖,則會嘗試獲取輕量級鎖
比偏向鎖多的:
在線程中增長鎖記錄(Lock Record),用於存儲鎖對象目前的Mark Word的拷貝,
利用CAS操做嘗試將對象的Mark Word更新爲指向Lock Record的指正,若是成功表示競爭到鎖,則將鎖標誌位變成00
判斷當前對象的Mark Word是否指向當前線程的棧幀,若是是則表示當前線程已經持有當前對象的鎖,則直接執行同步代碼塊;
不然只能說明該鎖對象已經被其餘線程搶佔了,這時輕量級鎖須要膨脹爲重量級鎖,鎖標誌位變成10,後面等待的線程將會進入阻塞狀態;
重量級鎖:經過Monitor實現
-------------------------------------------------------------
自旋鎖
線程的阻塞和喚醒須要CPU從用戶態轉爲核心態,頻繁的阻塞和喚醒對CPU來講是一件負擔很重的工做,勢必會給系統的併發性能帶來很大的壓力。同時咱們發如今許多應用上面,對象鎖的鎖狀態只會持續很短一段時間,爲了這一段很短的時間頻繁地阻塞和喚醒線程是很是不值得的。
因此引入自旋鎖。
何謂自旋鎖?
所謂自旋鎖,就是讓該線程等待一段時間,不會被當即掛起,看持有鎖的線程是否會很快釋放鎖。
怎麼等待呢?
執行一段無心義的循環便可(自旋)。
自旋等待不能替代阻塞,先不說對處理器數量的要求(多核,貌似如今沒有單核的處理器了),雖然它能夠避免線程切換帶來的開銷,可是它佔用了處理器的時間。若是持有鎖的線程很快就釋放了鎖,那麼自旋的效率就很是好;反之,自旋的線程就會白白消耗掉處理的資源,它不會作任何有意義的工做,典型的佔着茅坑不拉屎,這樣反而會帶來性能上的浪費。
因此說,自旋等待的時間(自旋的次數)必需要有一個限度,若是自旋超過了定義的時間仍然沒有獲取到鎖,則應該被掛起。自旋鎖在JDK 1.4.2中引入,默認關閉,可是可使用-XX:+UseSpinning開開啓,在JDK1.6中默認開啓。同時自旋的默認次數爲10次,能夠經過參數-XX:PreBlockSpin來調整。
若是經過參數-XX:preBlockSpin來調整自旋鎖的自旋次數,會帶來諸多不便。假如我將參數調整爲10,可是系統不少線程都是等你剛剛退出的時候就釋放了鎖(假如你多自旋一兩次就能夠獲取鎖),你是否是很尷尬?因而JDK1.6引入自適應的自旋鎖,讓虛擬機會變得愈來愈聰明。
適應自旋鎖
JDK 1.6引入了更加聰明的自旋鎖,即自適應自旋鎖。所謂自適應就意味着自旋的次數再也不是固定的,它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。
它怎麼作呢?
線程若是自旋成功了,那麼下次自旋的次數會更加多,由於虛擬機認爲既然上次成功了,那麼這次自旋也頗有可能會再次成功,那麼它就會容許自旋等待持續的次數更多。反之,若是對於某個鎖,不多有自旋可以成功的,那麼在之後要或者這個鎖的時候自旋的次數會減小甚至省略掉自旋過程,以避免浪費處理器資源。有了自適應自旋鎖,隨着程序運行和性能監控信息的不斷完善,虛擬機對程序鎖的情況預測會愈來愈準確,虛擬機會變得愈來愈聰明。
鎖消除
爲了保證數據的完整性,咱們在進行操做時須要對這部分操做進行同步控制,可是在有些狀況下,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內部的加鎖操做消除。
鎖粗化
咱們知道在使用同步鎖的時候,須要讓同步塊的做用範圍儘量小,僅在共享數據的實際做用域中才進行同步。這樣作的目的是爲了使須要同步的操做數量儘量縮小,若是存在鎖競爭,那麼等待鎖的線程也能儘快拿到鎖。
在大多數的狀況下,上述觀點是正確的,LZ也一直堅持着這個觀點。可是若是一系列的連續加鎖解鎖操做,可能會致使沒必要要的性能損耗,因此引入鎖粗化的概念。
那什麼是鎖粗化?
就是將多個連續的加鎖、解鎖操做鏈接在一塊兒,擴展成一個範圍更大的鎖。
如上面實例:vector每次add的時候都須要加鎖操做,JVM檢測到對同一個對象(vector)連續加鎖、解鎖操做,會合並一個更大範圍的加鎖、解鎖操做,即加鎖解鎖操做會移到for循環以外。
輕量級鎖
引入輕量級鎖的主要目的是在多沒有多線程競爭的前提下,減小傳統的重量級鎖使用操做系統互斥量產生的性能消耗。
當關閉偏向鎖功能或者多個線程競爭偏向鎖致使偏向鎖升級爲輕量級鎖,則會嘗試獲取輕量級鎖,其步驟以下:獲取鎖。
判斷當前對象是否處於無鎖狀態(hashcode、0、01),如果,則JVM首先將在當前線程的棧幀中創建一個名爲鎖記錄(Lock Record)的空間,用於存儲鎖對象目前的Mark Word的拷貝(官方把這份拷貝加了一個Displaced前綴,即Displaced Mark Word);不然執行步驟(3);
JVM利用CAS操做嘗試將對象的Mark Word更新爲指向Lock Record的指正,若是成功表示競爭到鎖,則將鎖標誌位變成00(表示此對象處於輕量級鎖狀態),執行同步操做;若是失敗則執行步驟(3);
判斷當前對象的Mark Word是否指向當前線程的棧幀,若是是則表示當前線程已經持有當前對象的鎖,則直接執行同步代碼塊;不然只能說明該鎖對象已經被其餘線程搶佔了,這時輕量級鎖須要膨脹爲重量級鎖,鎖標誌位變成10,後面等待的線程將會進入阻塞狀態;
釋放鎖輕量級鎖的釋放也是經過CAS操做來進行的,主要步驟以下:
取出在獲取輕量級鎖保存在Displaced Mark Word中的數據;
用CAS操做將取出的數據替換當前對象的Mark Word中,若是成功,則說明釋放鎖成功,不然執行(3);
若是CAS操做替換失敗,說明有其餘線程嘗試獲取該鎖,則須要在釋放鎖的同時須要喚醒被掛起的線程。
對於輕量級鎖,其性能提高的依據是「對於絕大部分的鎖,在整個生命週期內都是不會存在競爭的」,若是打破這個依據則除了互斥的開銷外,還有額外的CAS操做,所以在有多線程競爭的狀況下,輕量級鎖比重量級鎖更慢;
偏向鎖
引入偏向鎖主要目的是:爲了在無多線程競爭的狀況下儘可能減小沒必要要的輕量級鎖執行路徑。上面提到了輕量級鎖的加鎖解鎖操做是須要依賴屢次CAS原子指令的。那麼偏向鎖是如何來減小沒必要要的CAS操做呢?咱們能夠查看Mark work的結構就明白了。
只須要檢查是否爲偏向鎖、鎖標識爲以及ThreadID便可,處理流程以下:獲取鎖。
檢測Mark Word是否爲可偏向狀態,便是否爲偏向鎖1,鎖標識位爲01;
若爲可偏向狀態,則測試線程ID是否爲當前線程ID,若是是,則執行步驟(5),不然執行步驟(3);
若是線程ID不爲當前線程ID,則經過CAS操做競爭鎖,競爭成功,則將Mark Word的線程ID替換爲當前線程ID,不然執行線程(4);
經過CAS競爭鎖失敗,證實當前存在多線程競爭狀況,當到達全局安全點,得到偏向鎖的線程被掛起,偏向鎖升級爲輕量級鎖,而後被阻塞在安全點的線程繼續往下執行同步代碼塊;
執行同步代碼塊。
釋放鎖偏向鎖的釋放採用了一種只有競爭纔會釋放鎖的機制,線程是不會主動去釋放偏向鎖,須要等待其餘線程來競爭。偏向鎖的撤銷須要等待全局安全點(這個時間點是上沒有正在執行的代碼)。
其步驟以下:
暫停擁有偏向鎖的線程,判斷鎖對象石是否還處於被鎖定狀態;
撤銷偏向蘇,恢復到無鎖狀態(01)或者輕量級鎖的狀態。
重量級鎖
重量級鎖經過對象內部的監視器(monitor)實現,其中monitor的本質是依賴於底層操做系統的Mutex Lock實現,操做系統實現線程之間的切換須要從用戶態到內核態的切換,切換成本很是高。
https://mp.weixin.qq.com/s/wHz0uL_LEe4OgLsSFGEZEg
四種自旋轉的特色和實現
https://mp.weixin.qq.com/s/WzO6DbVH6EApryGFC23aZA
java 幾種鎖機制
(偏向鎖,輕量級鎖,重量級鎖,自旋鎖)
http://blog.csdn.net/u014470581/article/details/53559100
synchronized & 偏向鎖 & 輕量級鎖 & 重量級鎖 & 各自優缺點及場景 & AtomicReference
http://www.cnblogs.com/charlesblc/p/5994162.html