12|多線程之鎖優(yōu)化（上）：深入了解Synchronized同步鎖的優(yōu) 進入課 JDK1.5之前，Java是依靠Synchronized關(guān)鍵字實現(xiàn)鎖功能來做到這點的。Synchronized是JVM實現(xiàn)的一種內(nèi)置鎖，鎖的獲取和釋放是由JVM隱式實現(xiàn)。JDK1.5LockLock同步鎖是基于Java實現(xiàn)的，而Synchronized是基于底層操作系統(tǒng)的Mutex因此，在鎖競爭激烈的情況下，Synchronized特別是在單個線程重復(fù)申請鎖的情況下，JD1.5版本的ychronized鎖性能要比Lock的性能差很多。例如，在Dubbo基 y實現(xiàn)的通信中，消費端向服務(wù)端通信，由于接收返回消息是異步，所以需要一個線程輪詢返回信息。而在接收消息時，就需要用到鎖來確保eqestesin的原子性。如果 這里使用ychronized同步鎖，那么每當(dāng)同一個線程請求鎖資源時，都會發(fā)生一次用戶態(tài)和內(nèi)核態(tài)的切換。到了JDK1.6版本，Java對Synchronized同步鎖做了充分的優(yōu)化，甚至在某些場景下，它的性能已經(jīng)了Lock同步鎖。這一講就來看看Synchronized同步鎖究竟是了解Synchronized同步鎖優(yōu)化之前， Synchronized以下就是通過Synchronized實現(xiàn)的兩種同步方法加鎖的方式：//publicsynchronizedvoidmethod1()// 5//publicvoidmethod2()Objecto=newsynchronized(o)// 1javac-encodingUTF-8SyncTest.java//先運行編譯classjavap-vSyncTest.class//再通過javap通過輸出的字節(jié)碼，你會發(fā)現(xiàn)：Synchronized在修飾同步代碼塊時，是由monitorenter和monitorexit指令來實現(xiàn)同步的。進入monitorenter指令后，線程將持有Monitor對象，monitorenter指令后，線程將釋放該Monitor對象。publicvoiddescriptor:flags:stack=2,locals=4, 0: 3:4:invokespecial7:8:9:10:11:monitorenter//monitorenter12:13:monitorexit//monitorexit14: 17:18:19:20:21:22:Exception totarget line18:line19:line21:line22:StackMapTable:number_of_entries=frame_type=255/*full_frameoffset_delta=locals=[classcom/demo/io/SyncTest,classjava/lang/Object,classstack=[classjava/lang/Throwableframe_type=250/*chopoffset_delta=再來看以下同步方法的字節(jié)碼，你會發(fā)現(xiàn)：當(dāng)Synchronized修飾同步方法時，并沒有發(fā)現(xiàn)monitorenter和monitorexit指令，而是出現(xiàn)了一個ACC_SYNCHRONIZED標志。這是因為JVM使用了ACC_SYNCHRONIZED標志來區(qū)分一個方法是否是同步方法。當(dāng)方法調(diào)用時，調(diào)用指令將會檢查該方法是否被設(shè)置ACC_SYNCHRONIZED標志。如果設(shè)置了該標志，執(zhí)行線程將先持有Monitor對象，然后再執(zhí)行方法。在該方法運行期間，其它線程將無法獲取到該Mointor對象，當(dāng)方法執(zhí)行完成后，再釋放該Monitor對publicsynchronizedvoiddescriptor:flags:ACC_PUBLIC,ACC_SYNCHRONIZED//ACC_SYNCHRONIZEDstack=0,locals=1,0:line8:9 再來看看Synchronized修飾方法是怎么實現(xiàn)鎖原理的JVM中的同步是基于進入和管程（Monitor）對象實現(xiàn)的。每個對象實例都會有一個Monitor，MonitorMonitorObjectMonitorObjectMonitor是由C++的ObjectMonitor.hpp文件實現(xiàn)，如下所示：ObjectMonitor()_header=_count=0;//4_waiters=5_recursions=6_object=7_owner=8_WaitSet=NULL;//處于wait狀態(tài)的線程，會被加入到9_WaitSetLock=0_Responsible=NULL_succ=NULL_cxq=NULLNext=NULL_EntryList=NULL;//處于等待鎖block_SpinFreq=0_Splock=0OwnerIsThread=0}當(dāng)多個線程同時一段同步代碼時，多個線程會先被存放在EntryList集合中，處于block狀態(tài)的線程，都會被加入到該列表。接下來當(dāng)線程獲取到對象的Monitor時，MonitorMutexLockMutex有該Mutex，其它線程將無法獲取到該Mutex。waitMutexWaitSet中，等待下一次被喚醒。如果當(dāng)前線程順利執(zhí)行完方法，也將釋放Mutex。鎖在這種實現(xiàn)方式中，因Monitor是依賴于底層的操作系統(tǒng)實現(xiàn)，存在用戶態(tài)與內(nèi)核態(tài)之為了提升性能，JDK1.6下文切換，而正是新增的Java對象頭實現(xiàn)了鎖升級功能。JavaSynchronized將和Java對象頭有關(guān)。JavaJDK1.6JVM充。其中Java對象頭由MarkWord、指向類的指針以及數(shù)組長度三部分組成。MarkWordMarkWord64JVM64bit，可以一起看下64位JVM的結(jié)構(gòu)是怎么樣的。如下圖所示：鎖升級功能主要依賴于MarkWord中的鎖標志位和釋放偏向鎖標志位，ynchrnized同步鎖就是從偏向鎖開始的，隨著競爭越來越激烈，偏向鎖升級到輕量級鎖，最終升級到重量級鎖。下面就沿著這條優(yōu)化路徑去看下具體的內(nèi)容。偏向鎖主要用來優(yōu)化同一線程多次申請同一個鎖的競爭。在某些情況下，大部分時間是同一個線程競爭鎖資源，例如，在創(chuàng)建一個線程并執(zhí)行循環(huán)的場景下，或單線程操作一個線程安全集合時，同一線程每次都需要獲取和釋放鎖，每次操作都會發(fā)生用戶態(tài)與內(nèi)核態(tài)的切換。MarkWord中去判斷一下是否有偏向鎖指向它的ID，無需再進入Monitor去競爭對象了。01，“是否偏向鎖”標志位設(shè)置為1，并且記錄搶到鎖的線程ID，表示進入偏向鎖狀態(tài)。一旦出現(xiàn)其它線程競爭鎖資源時，偏向鎖就會被撤銷。偏向鎖的撤銷需要等待全局安全點，暫停持有該鎖的線程，同時檢查該線程是否還在執(zhí)行該方法，如果是，則升級鎖，反之則被其它線程搶占。stoptheword后，開啟偏向鎖無疑會帶來更大的性能開銷，這時 可以通過添加JVM1-XX:-UseBiasedLocking//關(guān)閉偏向鎖（默認打開或1-XX:+UseHeavyMonitors//MarkWord中的線程ID不是自己的線程ID，就會進行CAS操作獲取鎖，如果獲取成功，直換MarkWordIDID，該鎖會保持偏向鎖狀態(tài)；如果獲取鎖失敗，代表當(dāng)CASJVM提供了一種自旋鎖，可以通過自旋方式不斷嘗試獲取鎖，從而避免線程被掛起阻塞。這是基于大多數(shù)情況下，線程持有鎖的時間都不會太長，畢竟線程被掛起阻塞可能會得不償失。從JDK1.7開始，自旋鎖默認啟用，自旋次數(shù)由JVM設(shè)置決定，這里 次數(shù)過多，因為CAS重試操作意味著長時間地占用CPU。自旋鎖重試如果搶鎖依然失敗，同步鎖就會升級至重量級鎖，鎖標志位改為10。在這個狀態(tài)下，未搶到鎖的線程都會進入Monitor，會被阻塞在_WaitSet隊列中。或鎖占用的時間過長，自旋鎖將會導(dǎo)致大量的線程一直處于CAS重試狀態(tài)，占用CPU資 可以通過設(shè)置JVM參數(shù)來關(guān)閉自旋鎖，優(yōu)化系統(tǒng)性能，-XX:-UseSpinning//參數(shù)關(guān)閉自旋鎖優(yōu)化(默認打開-XX:PreBlockSpin//參數(shù)修改默認的自旋次數(shù)。JDK1.7后，去掉此參數(shù)，由jvm除了鎖升級優(yōu)化，Java還使用了編譯器對鎖進行優(yōu)化。JIT編譯器在動態(tài)編譯同步塊的時確認是的話，那么JIT編譯器在編譯這個同步塊的時候不會生成synchronized所表示的鎖的申請與釋放的機器碼，即消除了鎖的使用。在Java7的版本就不需要手動配置了，該鎖粗化同理，就是在JIT編譯器動態(tài)編譯時，如果發(fā)現(xiàn)幾個相鄰的同步塊使用的是同一個鎖實例，那么JIT編譯器將會把這幾個同步塊合并為一個大的同步塊，從而避免一個線程“反除了鎖優(yōu)化和編譯器優(yōu)化之外，還可以通過代碼層來實現(xiàn)鎖優(yōu)化，減小鎖粒度就是當(dāng) 的鎖對象是一個數(shù)組或隊列時，集中競爭一個對象的話會非常激烈，鎖也會升級為重量級鎖。 可以考慮將一個數(shù)組和隊列對象拆成多個小對象，來降低鎖競爭，提升并行度。最經(jīng)典的減小鎖粒度的案例就是JDK1.8之前實現(xiàn)的ConcurrentHashMap版本。知道，HashTable是基于一個數(shù)組+鏈表實現(xiàn)的，所以在并發(fā)讀寫操作集合時，存在激烈的鎖資源競爭，也因此性能會存在瓶頸。而ConcurrentHashMap就很很巧妙地使用了分段鎖Segment來降低鎖資源競爭，如下圖所示：JVM在JDK1.6中引入了分級鎖機制來優(yōu)化ychronized，當(dāng)一個線程獲取鎖時，首先對象鎖將成為一個偏向鎖，這樣做是為了優(yōu)化同一線程重復(fù)獲取導(dǎo)致的用戶態(tài)與內(nèi)核態(tài)的切換問題；其次如果有多個線程競爭鎖資源，鎖將會升級為輕量級鎖，它適用于在短時間內(nèi)持有鎖，且分鎖有交替切換的場景；偏向鎖還使用了自旋鎖來避免線程用戶態(tài)與內(nèi)核態(tài)的頻繁切換，大大地提高了系統(tǒng)性能；但如果鎖競爭太激烈了，那么同步鎖將會升級為重量級鎖。減少鎖競爭，是優(yōu)化Synchronized同步鎖的關(guān)鍵。 應(yīng)該盡量使Synchronized同步鎖處于輕量級鎖或偏向鎖，這樣才能提高Synchronized同步鎖的性能；通過減小鎖粒度 Synchronized同步鎖在自旋時獲取鎖資源的成功率，避免Synchronized同步鎖升級為重 重點了解了Synchronized同步鎖優(yōu)化，這里由于字數(shù)限制，也為了你能更好地 中12講的內(nèi)容 會重點講解Lock同步鎖的請問以下Synchronized//publi