前言

　　高效并發(fā)是從JDK1.5到JDK1.6的一個重要改進，HotSpot虛擬機開發(fā)團隊在這個版本上花費了大量的精力去實現(xiàn)各種鎖優(yōu)化技術(shù)，如適應(yīng)性自旋、鎖消除、鎖粗化、輕量級鎖和偏向鎖等，這些技術(shù)都是為了在線程之間高效的共享數(shù)據(jù)，以及解決競爭問題，從而提高程序的執(zhí)行效率。

自旋鎖與自適應(yīng)自旋

　　如果物理機器有一個以上的處理器，能讓兩個或者以上的線程同時并行執(zhí)行，我們就讓后面請求鎖資源的那個線程“稍等一下”，但是不放棄處理器的執(zhí)行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們只需要讓線程執(zhí)行一個忙循環(huán)（自旋），這項技術(shù)就是所謂的自旋鎖。

　　自旋鎖在JDK 1.4.2中就已經(jīng)引入，只不過默認是關(guān)閉的，可以使用-XX:+UseSpinning參數(shù)來開啟，在JDK1.6中就已經(jīng)默認開啟了。自旋等待不能代替阻塞，且先不說對處理器數(shù)量的要求，自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器執(zhí)行時間的，因此，如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之，如果鎖被占用的時間很長，那么自旋的線程只會白白的浪費處理器資源，而不會做任何有用的工作，反而會帶來性能上的浪費。因此，自旋等待的時間必須要有一定的限度，如果自旋超過了限定的次數(shù)仍然沒有成功的獲取到鎖資源，就應(yīng)當(dāng)使用傳統(tǒng)的方式去掛起線程了。自旋次數(shù)的默認值是10次，用戶可以使用參數(shù)-XX：PreBlockSpin 來更改。

　　在JDK1.6中引入了自適應(yīng)的自旋鎖。自適應(yīng)意味著自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間以及鎖的擁有者的狀態(tài)來決定。如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而允許自旋等待持續(xù)相對更長的時間，比如100個循環(huán)。另外，如果對于某個鎖，自旋很少成功獲得過，那在以后要獲取這個鎖時將可能省略掉自旋過程，以避免浪費處理器資源。有了自適應(yīng)自旋，隨著程序運行和性能監(jiān)控信息的不斷完善，虛擬機對程序鎖的狀況預(yù)測就會越來越準確，虛擬機會變得越來越聰明。

鎖消除

　　鎖消除是指虛擬機即時編譯器在運行時，對一些代碼上要求同步，但是被檢測到不可能存在共享數(shù)據(jù)競爭的鎖進行消除。鎖消除的主要判定依據(jù)來源于逃逸分析的數(shù)據(jù)支持，如果判斷一段代碼中，堆上的所有數(shù)據(jù)都不會逃逸出去從而被其他線程訪問到，那就可以把它們當(dāng)做棧上數(shù)據(jù)對待，認為它們是線程私有的，同步加鎖自然就無須進行。

　　也許你會有疑問，變量是否逃逸，對于虛擬機來說需要使用數(shù)據(jù)流來分析確定，但是程序員自己應(yīng)該很清楚的，怎么會在明知道不存在數(shù)據(jù)競爭的情況下要求同步呢？答案是有許多同步措施并不是程序員自己加入的，同步的代碼在Java程序中的普遍程度也許超過了大部分人的想象。來看下面的例子：

public String concatString(String s1,String s2,String s3){return s1+s2+s3;}

?　　上述代碼無論是源碼字面上還是程序語義上都沒有同步。

　　由于String是一個不可變的類，對字符串的連接操作總是通過通過生成新的String對象來進行的，因此Javac編譯器會對String連接做自動優(yōu)化。在JDK1.5之前，會轉(zhuǎn)化為StringBuffer對象的連續(xù)append()操作，在JDK1.5及以后的版本中，會轉(zhuǎn)化為StringBuilder 對象的連續(xù)append()操作，即上述代碼可能會變成以下代碼：

public String concatString(String s1,String s2,String s3){StringBuffer stringBuffer = new StringBuffer();stringBuffer.append(s1);stringBuffer.append(s2);stringBuffer.append(s3);return stringBuffer.toString();}

?　　到這里，大家還認為這段代碼沒有涉及同步嗎？每個StringBuffer.append()方法中都有一個同步塊，鎖的是stringBuffer對象。虛擬機觀察變量stringBuffer，很快就會發(fā)現(xiàn)它的動態(tài)作用域被限制在concatString()方法內(nèi)部。也就是說，該變量的所有引用永遠不會“逃逸”到concatString()方法外，其他線程無法訪問到它，因此，雖然這里有鎖，但是可以被安全的消除掉，在即時編譯之后，這段代碼就會忽略掉所有的同步而直接執(zhí)行了。

鎖粗化

　　原則上，我們編寫代碼的時候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享數(shù)據(jù)的實際作用域中才進行同步，這樣是為了使得需要同步的操作數(shù)量盡可能變小，如果存在鎖競爭，那等待鎖的線程也能盡快拿到鎖。

　　大部分情況下，縮小鎖的作用域是正確的，但是如果一系列的連續(xù)操作都是對同一個對象反復(fù)加鎖和解鎖，甚至加鎖操作是出現(xiàn)在循環(huán)體中的，那即使沒有線程競爭，頻繁的進行互斥同步操作也會導(dǎo)致不必要的性能損耗。如果虛擬機探測到有這樣一串零碎的操作都是對同一個對象加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部。如下所示：

public String concatString(String s1,String s2,String s3){StringBuffer stringBuffer = new StringBuffer();for (int i = 0;i < 10;i++){synchronized (stringBuffer){stringBuffer.append(i);}}return stringBuffer.toString();}

?優(yōu)化后：

public String concatString(String s1,String s2,String s3){StringBuffer stringBuffer = new StringBuffer();synchronized (stringBuffer){for (int i = 0;i < 10;i++){stringBuffer.append(i);}}return stringBuffer.toString();}

?輕量級鎖

　　輕量級鎖是JDK1.6之中加入的新型鎖機制，它名字中的“輕量級”是相對于使用操作系統(tǒng)互斥量來實現(xiàn)的傳統(tǒng)鎖而言的，因此傳統(tǒng)鎖機制就稱為“重量級”鎖。首先需要強調(diào)一點的是，輕量級鎖并不是用來代替重量級鎖的，它的本意是在沒有多線程競爭的前提下，減少傳統(tǒng)的重量級鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。

　　要理解輕量級鎖，以及后面將要說到的偏向鎖的原理和運作過程，必須從HotSpot虛擬機的對象（對象頭部分）的內(nèi)存布局開始介紹。HotSpot虛擬機的對象頭（Object Header）分為兩部分信息，一部分信息用于存儲對象自身的運行時數(shù)據(jù)，如哈希嗎（HashCode）、GC分代年齡（Generational GC Age）等，這部分數(shù)據(jù)的長度在32位和64位的虛擬機中分別為32bit和64bit，官方稱為“Mark Word”，它是實現(xiàn)輕量級鎖和偏向鎖的關(guān)鍵。另外一部分用于存儲指向方法區(qū)對象類型數(shù)據(jù)的指針，如果是數(shù)組對象的話，還會有一個額外的部分用于存儲數(shù)組長度。

　　對象頭信息是與對象自身定義的數(shù)據(jù)無關(guān)的額外存儲成本，考慮到虛擬機的空間效率，Mark Word被設(shè)計成一個非固定的數(shù)據(jù)結(jié)構(gòu)以便在極小的空間內(nèi)存儲盡量多的信息，它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間。例如：在32位的HotSpot虛擬機中對象未被鎖定的狀態(tài)下，Mark Word 的32bit空間中的25bit用于存儲對象哈希碼，4bit用于存儲對象分代年齡，2bit用于存儲鎖標志位，1bit固定為0，在其他狀態(tài)（輕量級鎖定、重量級鎖定、GC標記、可偏向）下對象的存儲內(nèi)容如下：

?

　　介紹了對象的內(nèi)存布局后，我們回到輕量級鎖的執(zhí)行過程上。在代碼進入同步塊的時候，如果此同步對象沒有被鎖定（鎖標志位為“01”狀態(tài)），虛擬機首先將在當(dāng)前線程的棧幀中建立一個名為鎖記錄的空間，用于存儲鎖對象目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced前綴，即 Displaced Mark Word），這時候線程堆棧與對象頭的狀態(tài)如下圖所示：

　　然后，虛擬機將使用CAS操作嘗試將對象的Mark Word 更新為指向鎖記錄的指針。如果這個更新動作成功了，那么這個線程就擁有了該對象的鎖，并且對象Mark Word的鎖標志位（Mark Word的最后2bit）將轉(zhuǎn)變?yōu)椤?0”，即表示此對象處于輕量級鎖定狀態(tài)，這時候線程堆棧與對象頭的狀態(tài)如下圖所示：

　　如果這個更新操作失敗了，虛擬機首先會檢查對象的Mark Word是否指向當(dāng)前線程的棧幀，如果指向則說明當(dāng)前線程已經(jīng)擁有了這個對象的鎖，那就可以直接進入同步塊繼續(xù)執(zhí)行，否則說明這個鎖對象已經(jīng)被其他線程搶占了。如果有兩條以上的線程爭用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖標志的狀態(tài)值變?yōu)椤?0”，Mark Word 中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態(tài)。

　　上面描述的是輕量級鎖的加鎖過程，它的解鎖過程也是通過CAS操作來進行的，如果對象的Mark Word仍然指向著線程的鎖記錄，那就用CAS操作把對象當(dāng)前的Mark Word和線程中復(fù)制的Displaced Mark Word替換回來，如果替換成功，整個同步過程就完成了。如果替換失敗，說明有其他線程嘗試過獲取該鎖，那就要在釋放鎖的同時，喚醒被掛起的線程。

　　輕量級鎖能提升程序同步性能的依據(jù)是：對于絕大部分的鎖，在整個同步周期內(nèi)都是不存在競爭的，這是一個經(jīng)驗數(shù)據(jù)。如果沒有競爭，輕量級鎖使用CAS操作避免了使用互斥量的開銷，但如果存在鎖競爭，除了互斥量的開銷外，還額外發(fā)生了CAS操作，因此在有競爭的情況下，輕量級鎖會比傳統(tǒng)的重量級鎖更慢。

偏向鎖

　　偏向鎖也是JDK1.6中引入的一項鎖優(yōu)化，它的目的是消除數(shù)據(jù)在無競爭情況下的同步原語，進一步提高程序的運行性能。如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連CAS操作都不做了。

　　偏向鎖的偏，就是偏心的偏、偏袒的偏。它的意思是這個鎖會偏向于第一個獲得它的線程，如果在接下來的執(zhí)行過程中，該鎖沒有被其他的線程獲取，則持有這個偏向鎖的線程將永遠不需要再進行同步。

　　假設(shè)當(dāng)前虛擬機啟用了偏向鎖（啟用參數(shù)-XX：+UseBiasedLocking，這是JDK1.6的默認值），那么，當(dāng)鎖對象第一次被線程獲取的時候，虛擬機將會把對象頭中的標志位設(shè)為“01”，即偏向模式。同時使用CAS操作把獲取到這個鎖的線程ID記錄在對象的Mark Word 中，如果CAS成功，持有偏向鎖的線程以后每次進入這個鎖相關(guān)的同步塊時，虛擬機都可以不再進行任何同步操作（例如 Locking、UnLocking及對Mark Word的Update等）。

　　當(dāng)有另外一個線程去嘗試獲取這個鎖時，偏向模式就宣告結(jié)束。根據(jù)鎖對象目前是否處于被鎖定的狀態(tài)，撤銷偏向后恢復(fù)到未鎖定（標志位為“01”）或輕量級鎖定（標志位為“00”）的狀態(tài)，后續(xù)的同步操作就如前面介紹的輕量級鎖那樣執(zhí)行。偏向鎖、輕量級鎖的狀態(tài)轉(zhuǎn)化及對象Mark Word的關(guān)系如圖：

?　　偏向鎖可以提高帶有同步但無競爭的程序性能。它同樣是一個帶有效益權(quán)衡性質(zhì)的優(yōu)化，也就是說，它并不一定總是對程序運行有利，如果程序中大多數(shù)的鎖總是被多個不同的線程訪問，那偏向模式就是多余的。在具體問題具體分析的前提下，有時候使用參數(shù)-XX：-UseBiasedLocking來禁止偏向鎖優(yōu)化反而可以提升性能。

?參考：《深入理解Java虛擬機》 周志明 編著：

轉(zhuǎn)載于:https://www.cnblogs.com/Joe-Go/p/10033154.html

總結(jié)

以上是生活随笔為你收集整理的锁优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。