第一篇文章帶你深入理解JVM虛擬機讀書筆記目錄1.Java語言中的線程安全1.1不可變1.2絕對線程安全1.3相對線程安全1.4線程兼容1.5線程對立2.線程安全的實現(xiàn)方法2.1互斥同步3.鎖優(yōu)化3.1自旋鎖與自適應自旋3.2鎖消除3.3鎖粗化3.4輕量級鎖3.5偏向鎖總結

1.Java語言中的線程安全

按照線程安全的“安全程度”由強至弱來排序，可以將Java語言中各種操作共享的數(shù)據(jù)分為以下五類：不可變、絕對線程安全、相對線程安全、線程兼容和線程對立。

1.1不可變

不可變的對象一定是線程安全的，無論是對象的方法實現(xiàn)還是方法的調(diào)用者，都不需要再進行任何線程安全保障措施。

Java語言中，如果多線程共享的數(shù)據(jù)是一個基本數(shù)據(jù)類型，那么只要定義時使用final關鍵字修飾他就可以保證它是不可變的，如果共享數(shù)據(jù)是一個對象類型，由于Java語言目前暫時還沒有提供值類型的支持，那就需要對象自行保證其行為不會對其狀態(tài)產(chǎn)生任何影響才行。

例如：java.lang.String類的對象實例，它是一個典型的不可變對象，用戶調(diào)用它的substring()、replace()和concat()這些方法都不會影響它原來的值，只會返回一個新構造的字符串對象。

保證對象行為不影響自己狀態(tài)的途徑有很多種，最簡單的一種就是把對象里面帶有狀態(tài)的變量都聲明為final，這樣在構造函數(shù)結束之后，它就是不可變的，例如下面代碼中java.lang.Integer的構造函數(shù)，它通過將內(nèi)部狀態(tài)變量value定義為final來保障狀態(tài)不變：

*ThevalueofthecodeInteger/code.

*@serial

privatefinalintvalue;

*ConstructsanewlyallocatedcodeInteger/codeobjectthat

*representsthespecifiedcodeint/codevalue.

*@paramvaluethevaluetoberepresentedbythe

*codeInteger/codeobject.

publicInteger(intvalue){

this.value=value;

在Java類庫API中符合不可變要求的類型，除了上面提到的String之外，常用的還有枚舉類型及java.lang.Number的部分子類，如Long和Double等數(shù)值包裝類型、BigInteger和BigDecimal等大數(shù)據(jù)類型。但同為Number子類型的原子類AtomicInteger和AtomicLong則是可變的。

1.2絕對線程安全

JavaAPI中標注自己是線程安全的類，大多數(shù)都不是絕對的線程安全。java.util.Vector是個線程安全的容器，add()、get()、size()等方法都是被synchronized修飾的，保證了具備原子性、可見性和有序性。不過，就算是所有方法都被synchronized修飾，那也不意味著調(diào)用它的時候就不需要同步手段了。

如下代碼，對Vector線程安全性的測試：

privatestaticVectorIntegervector=newVectorInteger

publicstaticvoidmain(String[]args){

while(true){

for(inti=0;ii++){

vector.add(i);

ThreadremoveThread=newThread(newRunnable(){

@Override

publicvoidrun(){

for(inti=0;ivector.size();i++){

vector.remove(i);

ThreadprintThread=newThread(newRunnable(){

@Override

publicvoidrun(){

for(inti=0;ivector.size();i++){

System.out.println((vector.get(i)));

removeThread.start();

printThread.start();

//不要同時產(chǎn)生過多的線程，否則會導致操作系統(tǒng)假死

while(Thread.activeCount()20);

運行結果如下：

Exceptioninthread"Thread-132"java.lang.ArrayIndexOutOfBoundsException:

Arrayindexoutofrange:17

atjava.util.Vector.remove(Vector.java:777)

atorg.fenixsoft.mulithread.VectorTest$1.run(VectorTest.java:21)

atjava.lang.Thread.run(Thread.java:662)

盡管這里使用到的Vector的get()、remove()和size()方法都是同步的，但是在多線程的環(huán)境中，如果不在方法調(diào)用端做額外的同步措施，使用這段代碼仍然是不安全的。因為如果另一個線程恰好在錯誤的時間里刪除了一個元素，導致序號i已經(jīng)不再可用，再用i訪問數(shù)組就會拋出一個ArrayIndexOutOfBoundsException異常。如果要保證這段代碼能正確執(zhí)行下去，我們不得不把removeThread和printThread的定義改成如下所示：

ThreadremoveThread=newThread(newRunnable(){

@Override

publicvoidrun(){

synchronized(vector){

for(inti=0;ivector.size();i++){

vector.remove(i);

ThreadprintThread=newThread(newRunnable(){

@Override

publicvoidrun(){

synchronized(vector){

for(inti=0;ivector.size();i++){

System.out.println((vector.get(i)));

假如Vector一定要做到絕對的線程安全，那就必須在它內(nèi)部維護一組一致性的快照訪問才行，每次對其中元素進行改動都要產(chǎn)生新的快照，這樣要付出的時間和空間成本都是非常大的。

1.3相對線程安全

相對線程安全就是我們通常意義上所講的線程安全，它需要保證對這個對象單次的操作是線程安全的，我們在調(diào)用的時候不需要進行額外的保障措施，但是對于一些特定順序的連續(xù)調(diào)用，就可能需要在調(diào)用端使用額外的同步手段來保證調(diào)用的正確性。

在Java語言中，大部分聲稱線程安全的類都屬于這種類型，例如Vector、HashTable、Collections的synchronizedCollection()方法包裝的集合等。

1.4線程兼容

線程兼容是指對象本身并不是線程安全的，但是可以通過在調(diào)用端正確地使用同步手段來保證對象在并發(fā)環(huán)境中可以安全地使用。我們平常說一個類不是線程安全的，通常就是指這種情況。Java類庫API中大部分的類都是線程兼容的，如與前面的Vector和HashTable相對應的集合類ArrayList和HashMap等。

1.5線程對立

線程對立是指不管調(diào)用端是否采取了同步措施，都無法在多線程環(huán)境中并發(fā)使用代碼。由于Java語言天生就支持多線程的特性，線程對立這種排斥多線程的代碼是很少出現(xiàn)的，而且通常都是有害的，應當盡量避免。

2.線程安全的實現(xiàn)方法

2.1互斥同步

互斥同步（MutualExclusionSynchronization）是一種最常見也是最主要的并發(fā)正確性保障手段。同步是指在多個線程并發(fā)訪問共享數(shù)據(jù)時，保證共享數(shù)據(jù)在同一個時刻只被一個線程使用。而互斥是實現(xiàn)同步的一種手段，臨界區(qū)（CriticalSection）、互斥量（Mutex）和信號量（Semaphore）都是常見的互斥實現(xiàn)方式。因此在“互斥同步”這四個字里面，互斥是因，同步是果；互斥是方法，同步是目的。

在Java里面，最基本的互斥同步手段就是synchronized關鍵字，這是一種塊結構（BlockStructured）的同步語法。synchronized關鍵字經(jīng)過Javac編譯之后，會在同步塊的前后分別形成monitorenter和monitorexit這兩個字節(jié)碼指令。這兩個字節(jié)碼指令都需要一個reference類型的參數(shù)來指明要鎖定和解鎖的對象。

如果Java源碼中的synchronized明確指定了對象參數(shù)，那就以這個對象的引用作為reference；如果沒有明確指定，那將根據(jù)synchronized修飾的方法類型（如實例方法或類方法），來決定是取代碼所在的對象實例還是取類型對應的Class對象來作為線程要持有的鎖。

在執(zhí)行monitorenter指令時，首先要去嘗試獲取對象的鎖。如果這個對象沒被鎖定，或者當前線程已經(jīng)持有了那個對象的鎖，就把鎖的計數(shù)器的值增加一，而在執(zhí)行monitorexit指令時會將鎖計數(shù)器的值減一。一旦計數(shù)器的值為零，鎖隨即就被釋放了。如果獲取對象鎖失敗，那當前線程就應當被阻塞等待，直到請求鎖定的對象被持有它的線程釋放為止。

由上面的描述，可得出synchronized鎖的一些特性：

被synchronized修飾的同步塊對同一條線程來說是可重入的。這意味著同一線程反復進入同步塊也不會出現(xiàn)自己把自己鎖死的情況。被synchronized修飾的同步塊在持有鎖的線程執(zhí)行完畢并釋放鎖之前，會無條件地阻塞后面其他線程的進入。這意味著無法像處理某些數(shù)據(jù)庫中的鎖那樣，強制已獲取鎖的線程釋放鎖；也無法強制正在等待鎖的線程中斷等待或超時退出。

從執(zhí)行成本的角度看，synchronized持有鎖是Java語言中一個重量級（Heavy-Weight）的操作。主流Java虛擬機實現(xiàn)中，Java的線程是映射到操作系統(tǒng)的原生內(nèi)核線程之上的，如果要阻塞或喚醒一條線程，則需要操作系統(tǒng)來幫忙完成，這就不可避免地陷入用戶態(tài)到核心態(tài)的轉換中，進行這種狀態(tài)轉換需要耗費很多的處理器時間。

實際上，虛擬機本身會對synchronized持鎖操作進行一些優(yōu)化，譬如在通知操作系統(tǒng)阻塞線程之前加入一段自旋等待過程，以避免頻繁地切入核心態(tài)之中（這個問題下面小節(jié)再討論）。

3.鎖優(yōu)化

3.1自旋鎖與自適應自旋

自旋鎖：即，當一個線程去競爭共享資源時，該資源已被其他線程占用，這時該線程不會立刻進入掛起阻塞狀態(tài)，而是通過不斷自旋，等待共享資源使用權被持鎖線程釋放。當然，不可能讓一個線程一直自旋等待下去，自旋等待的時間是必須有一定的限度的，如果自旋超過了限定的次數(shù)仍然沒有成功獲得鎖，就應當使用傳統(tǒng)的方式去掛起線程。自旋次數(shù)的默認值是10次，用戶也可以使用參數(shù)-XX：PreBlockSpin來自行更改。

在JDK6中對自旋鎖的優(yōu)化，引入了自適應的自旋。自適應意味著自旋的時間不再是固定的了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態(tài)來決定的。如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而允許自旋等待持續(xù)相對更長的時間，比如持續(xù)100次忙循環(huán)。另一方面，如果對于某個鎖，自旋很少成功獲得過鎖，那在以后要獲取這個鎖時將有可能直接省略掉自旋過程，以避免浪費處理器資源。

3.2鎖消除

鎖消除：是指虛擬機即時編譯器在運行時，對一些代碼要求同步，但是對被檢測到不可能存在共享資源競爭的鎖進行消除。

鎖消除的主要判定依據(jù)來源于逃逸分析的數(shù)據(jù)支持，如果判斷到一段代碼中，在堆上的所有數(shù)據(jù)都不會逃逸出去被其他線程訪問到，那就可以把它們當作棧上數(shù)據(jù)對待，認為它們是線程私有的，同步加鎖自然就無須再進行。

示例如下：（示例2-1）

publicStringconcatString(Strings1,Strings2,Strings3){

returns1+s2+s3;

由于String是一個不可變的類，對字符串的連接操作總是通過生成新的String對象來進行的，因此Javac編譯器會對String連接做自動優(yōu)化。

在JDK5之前，字符串加法會轉化為StringBuffer對象的連續(xù)append()操作，在JDK5及以后的版本中，會轉化為StringBuilder對象的連續(xù)append()操作。

優(yōu)化為如下所示：（示例2-2）

publicStringconcatString(Strings1,Strings2,Strings3){

StringBuffersb=newStringBuffer();

sb.append(s1);

sb.append(s2);

sb.append(s3);

returnsb.toString();

現(xiàn)在大家還認為這段代碼沒有涉及同步嗎？每個StringBuffer.append()方法中都有一個同步塊，鎖就是sb對象。虛擬機觀察變量sb，經(jīng)過逃逸分析后會發(fā)現(xiàn)它的動態(tài)作用域被限制在concatString()方法內(nèi)部。也就是sb的所有引用都永遠不會逃逸到concatString()方法之外，其他線程無法訪問到它，所以這里雖然有鎖，但是可以被安全地消除掉。在解釋執(zhí)行時這里仍然會加鎖，但在經(jīng)過服務端編譯器的即時編譯之后，這段代碼就會忽略所有的同步措施而直接執(zhí)行。

客觀地說，既然談到鎖消除與逃逸分析，那虛擬機就不可能是JDK5之前的版本，所以實際上會轉化為非線程安全的StringBuilder來完成字符串拼接，并不會加鎖。但是這也不影響筆者用這個例子證明Java對象中同步的普遍性。

3.3鎖粗化

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

大多數(shù)情況下，上面的原則都是正確的，但是如果一系列的連續(xù)操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作是出現(xiàn)在循環(huán)體之中的，那即使沒有線程競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗。

（示例2-2）所示連續(xù)的append()方法就屬于這類情況。如果虛擬機探測到有這樣一串零碎的操作都對同一個對象加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部，以（示例2-2）為例，就是擴展到第一個append()操作之前直至最后一個append()操作之后，這樣只需要加鎖一次就可以了。

總之，如果虛擬機探測到有這樣一串零碎的操作都對同一個對象加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部。

3.4輕量級鎖

輕量級鎖是JDK6時加入的新型鎖機制，它名字中的“輕量級”是相對于使用操作系統(tǒng)互斥量來實現(xiàn)的傳統(tǒng)鎖而言的，因此傳統(tǒng)的鎖機制就被稱為“重量級”鎖。輕量級鎖并不是用來代替重量級鎖的，它設計的初衷是在沒有多線程競爭的前提下，減少傳統(tǒng)的重量級鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。

由于對象頭信息是與對象自身定義的數(shù)據(jù)無關的額外存儲成本，考慮到Java虛擬機的空間使用效率，MarkWord被設計成一個非固定的動態(tài)數(shù)據(jù)結構，以便在極小的空間內(nèi)存儲盡量多的信息。它會根據(jù)對象的狀態(tài)復用自己的存儲空間。

例如在32位的HotSpot虛擬機中，對象未被鎖定的狀態(tài)下，MarkWord的32個比特空間里的25個比特將用于存儲對象哈希碼，4個比特用于存儲對象分代年齡，2個比特用于存儲鎖標志位，還有1個比特固定為0（這表示未進入偏向模式）。

對象除了未被鎖定的正常狀態(tài)外，還有輕量級鎖定、重量級鎖定、GC標記、可偏向等幾種不同狀態(tài)，這些狀態(tài)下對象頭的存儲內(nèi)容如下表所示：

在代碼即將進入同步塊的時候，如果此同步對象沒有被鎖定（鎖標志位為“01”狀態(tài)），虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（LockRecord）的空間，用于存儲鎖對象目前的MarkWord的拷貝，這時候線程堆棧與對象頭的狀態(tài)如下圖所示：

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

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

上面描述的是輕量級鎖的加鎖過程，它的解鎖過程也同樣是通過CAS操作來進行的，如果對象的MarkWord仍然指向線程的鎖記錄，那就用CAS操作把對象當前的MarkWord和線程中復制的DisplacedMarkWord替換回來。假如能夠成功替換，那整個同步過程就順利完成了；如果替換失敗，則說明有其他線程嘗試過獲取該鎖，就要在釋放鎖的同時，喚醒被掛