首先來說下synchronize和Lock的區別:
兩者都是鎖,用來控制併發衝突,區別在於Lock是個接口,提供的功能更加豐富,除了這個外,他們還有如下區別:
synchronize自動釋放鎖,而Lock必須手動釋放,並且代碼中出現異常會導致unlock代碼不執行,所以Lock一般在Finally中釋放,而synchronize釋放鎖是由JVM自動執行的。
Lock有共享鎖的概念,所以可以設置讀寫鎖提高效率,synchronize不能。(兩者都可重入)
Lock可以讓線程在獲取鎖的過程中響應中斷,而synchronize不會,線程會一直等待下去。lock.lockInterruptibly()方法會優先響應中斷,而不是像lock一樣優先去獲取鎖。
Lock鎖的是代碼塊,synchronize還能鎖方法和類。
Lock可以知道線程有沒有拿到鎖,而synchronize不能
Lock鎖對應有源碼的,可以查看下代碼,那麼synchronize在JVM層面是怎麼實現的呢,我們看下字節碼文件:
先用javac Test.class 編譯出class文件
再用javap –c Test.class查看字節碼文件
我們寫個DEMO看下,JVM底層是怎麼實現synchronized的:、
<code>public class Test4 {
private static Object LOCK = new Object();
public static int main(String[] args) {
synchronized (LOCK){
System.out.println("Hello World");
}
return 1;
}
}/<code>
在看下上面代碼對應的字節碼
![synchronize底層實現原理以及相關的優化](http://p2.ttnews.xyz/loading.gif)
也就是說,鎖是通過monitorenter和monitorexit來實現的,這兩個字節碼代表的是啥意思:
可以在下面參考的網頁中瞭解monitorenter和monitorexit的作用,我就不盜用他們的話了,大致意思是,每個對象都有一個monitor監視器,調用monitorenter就是嘗試獲取這個對象,成功獲取到了就將值+1,離開就將值減1。如果是線程重入,在將值+1,說明monitor對象是支持可重入的。
我之前分析過一篇ReenternLock,概念都是類似的,只是鎖是自身維護了一個volatile int類型的變量,通過對它加一減一表示佔有鎖啊重入之類的概念。
注意,如果synchronize在方法上,那就沒有上面兩個指令,取而代之的是有一個ACC_SYNCHRONIZED修飾,表示方法加鎖了。它會在常量池中增加這個一個標識符,獲取它的monitor,所以本質上是一樣的。
HotSpot中鎖的具體實現以及對它的優化:
重量級鎖:
最基礎的實現方式,JVM會阻塞未獲取到鎖的線程,在鎖被釋放的時候喚醒這些線程。阻塞和喚醒操作是依賴操作系統來完成的,所以需要從用戶態切換到內核態,開銷很大。並且monitor調用的是操作系統底層的互斥量(mutex),本身也有用戶態和內核態的切換,所以JVM引入了自旋的概念,減少上面說的線程切換的成本。
自旋鎖:
如果鎖被其他線程佔用的時間很短,那麼其他獲取鎖的線程只要稍微等一下就好了,沒必要進行用戶態和內核態之間的切換,等的狀態就叫自旋。例如如下代碼:
<code>public class SpinLock {
private AtomicReference<thread> cas = new AtomicReference<thread>();
public void lock() {
Thread current = Thread.currentThread();
// 利用CAS,獲取值不對則無限循環
while (!cas.compareAndSet(null, current)) {
// DO nothing
}
}
public void unlock() {
Thread current = Thread.currentThread();
cas.compareAndSet(current, null);
}
}
/<thread>/<thread>/<code>
自旋會跑一些無用的CPU指令,所以會浪費處理器時間,如果鎖被其他線程佔用的時間段的話確實是合適的…如果長的話就不如使用直接阻塞了,那麼JVM怎麼知道鎖被佔用的時間到底是長還是短呢?
因為JVM不知道鎖被佔用的時間長短,所以使用的是自適應自旋。就是線程空循環的次數時會動態調整的。
可以看出,自旋會導致不公平鎖,不一定等待時間最長的線程會最先獲取鎖。
輕量級鎖:
JDK1.6之後加入,它的目的並不是為了替換前面的重量級鎖,而是在實際沒有鎖競爭的情況下,將申請互斥量這步也省掉。鎖實現的核心在與對象頭(MarkWord)的結構,對象自身會有信息表示所有被鎖住並且鎖是什麼類型,如下所示:
![synchronize底層實現原理以及相關的優化](http://p2.ttnews.xyz/loading.gif)
如果代碼進入同步塊時,檢測到對象未鎖定,即標誌位為01。那麼當前線程就會在自身棧幀中建議一個區域保存對象的MarkWord信息,再使用CAS的方式讓這個區域指向對象的MarkWork區域,這樣就算加上鎖了。(這樣就沒有獲取系統mutex變量,只是改了個值,但是如果有競爭的話,就要升級成重量級鎖,這樣反倒變慢了)
加鎖前VS 加鎖後:
偏向鎖:
比輕量級鎖更絕,將同步操作全部省略…設置步驟是和前面的輕量級鎖一樣的,不同的是標誌位設置的是01,即偏向模式。
不同的是同一個線程第二次進來之後,虛擬機不會再進行任何的同步操作,比如Mark Word的update。
如果有其他線程來,偏向模式就結束了,標誌位會恢復到未鎖定或者偏向鎖。所以如果鎖總是會被多個線程訪問的話,還是禁止掉偏向鎖優化比較好。
鎖優化流程如下:(出自周志明老師的那本講解JVM的書)
可以看出,鎖是一個逐步升級的過程,不會一開始上來就重量級鎖。鎖一般只會升級不會降級,避免降級之後衝突導致效率不行並且又得升級。但是降級其實是允許的(STW的時候),可以看下參考中文章裡面提到的英文網站。
其他的優化還有鎖消除以及鎖粗化:
如果一段代碼其實在作用域可以不加鎖的,Javac編譯器會自動優化。
鎖粗化是指代碼在一段代碼中多次加鎖,會被JVM優化成對整個代碼段加鎖。
(但是這兩點是JVM對代碼的優化,而不是對synchronized優化了,這裡只是順帶提一下)
JAVA進階架構程序員福利:我這裡還總結整理了比較全面的JAVA相關的面試資料,都已經整理成了
PDF版,這些都可以分享給大家,關注私信我:【806】,免費領取!
閱讀更多 欣然1013 的文章