記得剛剛開始學習Java的時候,一遇到多線程狀況就是synchronized。對於當時的咱們來講,synchronized是如此的神奇且強大。咱們賦予它一個名字「同步」,也成爲咱們解決多線程狀況的良藥,百試不爽。可是,隨着學習的深刻,咱們知道synchronized是一個重量級鎖,相對於Lock,它會顯得那麼笨重,以致於咱們認爲它不是那麼的高效。隨着Javs SE 1.6對synchronized進行各類優化後,synchronized不會顯得那麼重。java
synchronized能夠保證方法或者代碼塊在運行時,同一時刻只有一個方法進入臨界區,同時還能夠保證共享變量的內存可見性。數組
Java中的每個對象均可以做爲鎖,這是synchronized實現同步的基礎:安全
JVM規範定義:JVM基於進入與退出Monitor對象與來實現方法同步和代碼塊同步:性能優化
- 代碼塊同步:使用monitorenter和monitorexit指令實現。
- 方法同步:使用另一種方式,可是一樣是使用這兩個指令實現。只是具體表現形式有所不一樣
public class SynchronizedTest {
public synchronized void test1() {
}
public void test2() {
synchronized (this) {
}
}
}
複製代碼
使用javap -verbose SynchronizedTest.class工具查看生成的class文件信息分析synchronized實現:bash
省略部分代碼,以下所示:多線程
{
public com.zero.test.SynchronizedTest();
.....
public synchronized void test1();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
Code:
stack=0, locals=1, args_size=1
0: return
LineNumberTable:
line 5: 0
public void test2();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter
4: aload_1
5: monitorexit
6: goto 14
9: astore_2
10: aload_1
11: monitorexit
12: aload_2
13: athrow
14: return
......
}
複製代碼
從上面能夠看出同步代碼塊使用monitorenter和monitorexit指令實現的,同步方法使用方法修飾符上的ACCSYNCHRONIZED實現。不管哪種方式,其本質都是一個對象的監視器(monitor)進行獲取。併發
在咱們繼續分析深刻以前,要先了解兩個概念:Java對象頭、Monitor。app
synchronized用的鎖是存在Java對象頭裏的,Hotspot虛擬機的對象頭主要包括兩部分數據:Mark Word(標記字段)、Klass Pointer(類型指針)。其中Klass Point是是對象指向它的類元數據的指針,虛擬機經過這個指針來肯定這個對象是哪一個類的實例,Mark Word用於存儲對象自身的運行時數據,它是實現輕量級鎖和偏向鎖的關鍵。工具
Java對象頭裏的Mark Word用於存儲對象自身的運行時數據,如哈希碼(HashCode)、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程 ID、偏向時間戳等等。Java對象頭通常佔有兩個機器碼(在32位虛擬機中,1個機器碼等於4字節,也就是32bit),可是若是對象是數組類型,則須要三個機器碼,由於JVM虛擬機能夠經過Java對象的元數據信息肯定Java對象的大小,可是沒法從數組的元數據來確認數組的大小,因此用一塊來記錄數組長度。,32位 JVM 的Mark Word的默認存儲結構以下表格: 性能
咱們能夠把它理解爲一個同步工具,也能夠描述爲一種同步機制,它一般被描述爲一個對象。
與一切皆對象同樣,全部的Java對象是天生的Monitor,每個Java對象都有成爲Monitor的潛質,由於在Java的設計中 ,每個Java對象自打孃胎裏出來就帶了一把看不見的鎖,它叫作內部鎖或者Monitor鎖。
咱們知道synchronized是重量級鎖,效率不怎麼滴,同時這個觀念也一直存在咱們腦海裏,不過在JDK 1.6中對synchronize的實現進行了各類優化,使得它顯得不是那麼重了,那有哪些優化手段?
JDK1.6對鎖的實現引入了大量的優化,如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減小鎖操做的開銷。
鎖主要存在四中狀態,依次是:無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態。他們會隨着競爭的激烈而逐漸升級。注意鎖能夠升級不可降級,這種策略是爲了提升得到鎖和釋放鎖的效率。
線程的阻塞和喚醒須要CPU從用戶態轉爲核心態,頻繁的阻塞和喚醒對CPU來講是一件負擔很重的工做,勢必會給系統的併發性能帶來很大的壓力。同時咱們發如今許多應用上面,對象鎖的鎖狀態只會持續很短一段時間,爲了這一段很短的時間頻繁地阻塞和喚醒線程是很是不值得的。
何謂自旋鎖?
所謂自旋鎖,就是讓該線程等待一段時間,不會被當即掛起,看持有鎖的線程是否會很快釋放鎖。
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內部的加鎖操做消除。
咱們知道在使用同步鎖的時候,須要讓同步塊的做用範圍儘量小,僅在共享數據的實際做用域中才進行同步。這樣作的目的是爲了使須要同步的操做數量儘量縮小,若是存在鎖競爭,那麼等待鎖的線程也能儘快拿到鎖。 在大多數的狀況下,上述觀點是正確的。可是若是一系列的連續加鎖解鎖操做,可能會致使沒必要要的性能損耗,因此引入鎖粗化的概念。
那什麼是鎖粗化?
就是將多個連續的加鎖、解鎖操做鏈接在一塊兒,擴展成一個範圍更大的鎖。
如上面實例:vector每次add的時候都須要加鎖操做,JVM檢測到對同一個對象(vector)連續加鎖、解鎖操做,會合並一個更大範圍的加鎖、解鎖操做,即加鎖解鎖操做會移到for循環以外。
引入偏向鎖主要目的是:爲了在無多線程競爭的狀況下儘可能減小沒必要要的輕量級鎖執行路徑。輕量級鎖的加鎖解鎖操做是須要依賴屢次CAS原子指令的。那麼偏向鎖是如何來減小沒必要要的CAS操做呢?咱們能夠查看Mark work的結構就明白了。其實只要簡單的測試下對象頭的Mark Word裏是否存儲着指向當前線程的偏向鎖。若是測試成功,表示線程已經得到了鎖。若是測試失敗:則須要再測試下偏向鎖標識是否設置成1(表示當前是偏向鎖),若是沒有設置,那麼只能使用CAS競爭鎖了,若是設置了,則嘗試使用CAS將對象頭的偏向鎖指向當前線程。
流程以下:
釋放鎖偏向鎖的釋放採用了一種只有競爭纔會釋放鎖的機制,線程是不會主動去釋放偏向鎖,須要等待其餘線程來競爭。偏向鎖的撤銷須要等待全局安全點(這個時間點是沒有正在執行的代碼)。
其步驟以下:
引入輕量級鎖的主要目的是在只有少許線程競爭的前提下,減小傳統的重量級鎖使用操做系統互斥量產生的性能消耗。
當關閉偏向鎖功能或者多個線程競爭偏向鎖致使偏向鎖升級爲輕量級鎖,則會嘗試獲取輕量級鎖,其步驟以下:
取出在獲取輕量級鎖保存在Displaced Mark Word中的數據; 用CAS操做將取出的數據替換當前對象的Mark Word中,若是成功,則說明釋放鎖成功,不然執行(3); 若是CAS操做替換失敗,說明有其餘線程嘗試獲取該鎖,則須要在釋放鎖的同時須要喚醒被掛起的線程。
重量級鎖經過對象內部的監視器(monitor)實現,其中monitor的本質是依賴於底層操做系統的Mutex Lock實現,操做系統實現線程之間的切換須要從用戶態到內核態的切換,切換成本很是高。
下面對偏向鎖、輕量級鎖和重量級鎖進行比較:
表3 各類鎖的優缺點及適用場景