1. 面試官視角為什么 synchronized 是必考題如果你是一名Java開(kāi)發(fā)者無(wú)論你是準(zhǔn)備面試還是日常開(kāi)發(fā)synchronized這個(gè)詞幾乎每天都會(huì)在你眼前晃悠。但你真的懂它嗎我見(jiàn)過(guò)太多工作了3-5年的候選人被問(wèn)到“synchronized的鎖升級(jí)過(guò)程是怎樣的”或者“偏向鎖被撤銷的時(shí)機(jī)有哪些”時(shí)要么支支吾吾要么只能背出“無(wú)鎖、偏向鎖、輕量級(jí)鎖、重量級(jí)鎖”這幾個(gè)名詞再往深里問(wèn)就露餡了。這恰恰是面試官最愛(ài)問(wèn)synchronized的原因——它像一面鏡子能清晰照出一個(gè)Java程序員對(duì)并發(fā)編程理解的深度是區(qū)分“會(huì)用API”和“理解底層”的關(guān)鍵分水嶺。從面試官的角度看考察synchronized絕不僅僅是讓你背八股文。它是一道綜合性的“體檢題”能同時(shí)檢驗(yàn)?zāi)愕亩鄠€(gè)維度第一基礎(chǔ)語(yǔ)法和語(yǔ)義你是否清楚它可以用在哪些地方方法、代碼塊不同用法有什么區(qū)別第二JVM內(nèi)存模型JMM知識(shí)你是否理解synchronized如何保證可見(jiàn)性、有序性和原子性它與volatile、final等關(guān)鍵字的內(nèi)存語(yǔ)義有何異同第三JVM底層實(shí)現(xiàn)原理也就是常說(shuō)的鎖升級(jí)鎖膨脹過(guò)程這直接關(guān)系到你對(duì)HotSpot虛擬機(jī)源碼級(jí)別的理解。第四實(shí)戰(zhàn)經(jīng)驗(yàn)與問(wèn)題排查能力你是否在實(shí)際項(xiàng)目中因使用不當(dāng)導(dǎo)致過(guò)性能問(wèn)題或死鎖如何排查和優(yōu)化能回答好這四個(gè)層面才算是真正“硬核”地掌握了synchronized。所以這篇解析不會(huì)停留在“synchronized是悲觀鎖、可重入鎖”這種表層。我們會(huì)像剝洋蔥一樣從Java語(yǔ)言規(guī)范到JVM實(shí)現(xiàn)從字節(jié)碼指令到操作系統(tǒng)調(diào)用層層深入把每一個(gè)細(xì)節(jié)背后的“為什么”都講透。無(wú)論你是即將面對(duì)一線大廠技術(shù)面的求職者還是希望夯實(shí)并發(fā)根基的資深工程師這篇文章都將提供你所需的全部彈藥。2. 從Java語(yǔ)言到字節(jié)碼synchronized的語(yǔ)法糖與本質(zhì)很多初學(xué)者對(duì)synchronized的第一印象是“簡(jiǎn)單”加在方法或代碼塊前就行了。但它的“簡(jiǎn)單”背后是編譯器為我們自動(dòng)添加的大量字節(jié)碼指令。理解這一步是理解其所有高級(jí)特性的基礎(chǔ)。2.1 三種使用方式及其字節(jié)碼差異synchronized的用法有三種實(shí)例方法、靜態(tài)方法、同步代碼塊。它們?cè)谧止?jié)碼層面的實(shí)現(xiàn)有顯著不同。1. 同步實(shí)例方法當(dāng)你在一個(gè)非靜態(tài)方法前加上synchronized關(guān)鍵字時(shí)例如public synchronized void increment() { count; }編譯器會(huì)為這個(gè)方法添加一個(gè)ACC_SYNCHRONIZED訪問(wèn)標(biāo)志。這個(gè)標(biāo)志本身不直接對(duì)應(yīng)任何字節(jié)碼指令但它是一個(gè)明確的信號(hào)。當(dāng)JVM執(zhí)行到這個(gè)方法時(shí)如果檢測(cè)到ACC_SYNCHRONIZED標(biāo)志它會(huì)在調(diào)用該方法時(shí)自動(dòng)嘗試獲取該實(shí)例對(duì)象即this的監(jiān)視器鎖Monitor Lock。如果獲取成功則執(zhí)行方法體方法執(zhí)行完畢后無(wú)論是正常返回還是異常拋出JVM會(huì)自動(dòng)釋放該監(jiān)視器鎖。如果獲取失敗當(dāng)前線程會(huì)被阻塞直到鎖被釋放。2. 同步靜態(tài)方法靜態(tài)方法的同步鎖住的是類的Class對(duì)象。public static synchronized void staticIncrement() { staticCount; }其字節(jié)碼標(biāo)志同樣是ACC_SYNCHRONIZED但鎖的對(duì)象不同。JVM會(huì)去獲取當(dāng)前方法所屬類的Class對(duì)象例如MyClass.class的監(jiān)視器鎖。這意味著即使有多個(gè)不同的實(shí)例它們調(diào)用這個(gè)靜態(tài)同步方法時(shí)也會(huì)相互競(jìng)爭(zhēng)同一把鎖類鎖而實(shí)例同步方法鎖的是各自的對(duì)象。3. 同步代碼塊這是最靈活也最能體現(xiàn)底層原理的方式。public void add(Object obj) { synchronized(obj) { // 臨界區(qū)代碼 } }編譯后查看其字節(jié)碼你會(huì)看到明確的monitorenter和monitorexit指令aload_1 // 將引用obj壓入操作數(shù)棧 dup // 復(fù)制棧頂值obj引用 astore_2 // 將復(fù)制的引用存儲(chǔ)到局部變量表用于后續(xù)monitorexit monitorenter // 嘗試獲取obj的監(jiān)視器鎖 ... // 臨界區(qū)代碼 aload_2 // 將存儲(chǔ)的obj引用壓棧 monitorexit // 釋放obj的監(jiān)視器鎖 goto 結(jié)束位置 ... // 異常處理部分 aload_2 monitorexit // 確保在異常路徑上也釋放鎖 athrow 結(jié)束位置 ...這里有幾個(gè)關(guān)鍵點(diǎn)首先鎖對(duì)象是顯式指定的obj可以是任何Java對(duì)象。其次monitorenter和monitorexit是成對(duì)出現(xiàn)的并且編譯器會(huì)自動(dòng)生成一個(gè)異常處理器確保即使在臨界區(qū)代碼拋出異常鎖也能被正確釋放避免死鎖。這是synchronized關(guān)鍵字提供的隱式安全性之一。注意synchronized鎖的是對(duì)象而不是代碼或方法。所謂“同步方法”本質(zhì)上是將整個(gè)方法體作為同步代碼塊鎖對(duì)象是this或Class對(duì)象。這個(gè)觀念一定要扭轉(zhuǎn)過(guò)來(lái)。2.2 可重入性Reentrancy的字節(jié)碼體現(xiàn)synchronized是可重入鎖。這意味著同一個(gè)線程可以多次獲取同一把鎖而不會(huì)導(dǎo)致死鎖。這在遞歸調(diào)用或一個(gè)同步方法調(diào)用另一個(gè)同步方法時(shí)非常有用。public synchronized void methodA() { methodB(); // 可重入的關(guān)鍵 } public synchronized void methodB() { // do something }線程在進(jìn)入methodA時(shí)已經(jīng)持有了this鎖當(dāng)它進(jìn)入methodB時(shí)會(huì)再次嘗試獲取this鎖。如果鎖不可重入線程將在methodB入口處永久等待自己釋放鎖即死鎖。JVM如何實(shí)現(xiàn)可重入在對(duì)象頭中的Mark Word里有一個(gè)字段記錄了持有該鎖的線程ID以及一個(gè)鎖計(jì)數(shù)器。當(dāng)線程第一次獲取鎖時(shí)JVM記錄線程ID并將計(jì)數(shù)器置為1。同一線程再次獲取時(shí)計(jì)數(shù)器遞增。釋放鎖時(shí)計(jì)數(shù)器遞減。只有當(dāng)計(jì)數(shù)器歸零時(shí)才表示鎖被真正釋放其他線程才有機(jī)會(huì)獲取。這個(gè)邏輯完全由JVM在運(yùn)行時(shí)處理對(duì)字節(jié)碼指令monitorenter/exit是透明的。3. 對(duì)象頭與Mark Word鎖信息的存儲(chǔ)基石要理解鎖升級(jí)必須深入Java對(duì)象的內(nèi)存布局尤其是對(duì)象頭Object Header。在HotSpot虛擬機(jī)中一個(gè)對(duì)象在堆內(nèi)存中的存儲(chǔ)分為三部分對(duì)象頭Header、實(shí)例數(shù)據(jù)Instance Data和對(duì)齊填充Padding。而鎖的狀態(tài)信息就存儲(chǔ)在對(duì)象頭的Mark Word區(qū)域。在64位JVM下默認(rèn)開(kāi)啟指針壓縮Mark Word的長(zhǎng)度是64位8字節(jié)。它是一個(gè)“多功能”的字段其存儲(chǔ)的內(nèi)容會(huì)根據(jù)對(duì)象的狀態(tài)動(dòng)態(tài)變化。下圖展示了Mark Word在不同狀態(tài)下的格式鎖狀態(tài)存儲(chǔ)內(nèi)容64位標(biāo)志位無(wú)鎖 (Unlocked)對(duì)象的hashCode31位、分代年齡4位、偏向模式1位0、鎖標(biāo)志位2位0101偏向鎖 (Biased)持有偏向鎖的線程ID54位、Epoch2位、分代年齡4位、偏向模式1位1、鎖標(biāo)志位2位0101輕量級(jí)鎖 (Lightweight Lock)指向棧中鎖記錄Lock Record的指針62位00重量級(jí)鎖 (Heavyweight Lock)指向操作系統(tǒng)互斥量mutex和條件變量condition variable的指針即指向Monitor對(duì)象的指針62位10GC標(biāo)記與垃圾回收相關(guān)的信息11核心要點(diǎn)解析鎖標(biāo)志位lock bits最后2位是鎖狀態(tài)的“身份證”。01代表無(wú)鎖或偏向鎖具體是哪種由前面的偏向模式位1位決定。00代表輕量級(jí)鎖10代表重量級(jí)鎖11與GC相關(guān)。哈希碼hashCode的存儲(chǔ)對(duì)象的hashCode()方法返回的哈希碼是懶加載的只有在第一次調(diào)用Object::hashCode()或System::identityHashCode()時(shí)才會(huì)計(jì)算并存儲(chǔ)。在無(wú)鎖狀態(tài)下它可以存儲(chǔ)在Mark Word中。但是一旦對(duì)象進(jìn)入偏向鎖狀態(tài)Mark Word被線程ID占用就沒(méi)有空間存哈希碼了。如果這時(shí)調(diào)用hashCode()JVM會(huì)立即撤銷偏向鎖膨脹為重量級(jí)鎖因?yàn)橹亓考?jí)鎖的Monitor對(duì)象里有獨(dú)立空間存儲(chǔ)hashCode。輕量級(jí)鎖同樣沒(méi)有空間存儲(chǔ)哈希碼。為什么是“升級(jí)”而不是“降級(jí)”鎖升級(jí)的路徑基本是單向的無(wú)鎖 - 偏向鎖 - 輕量級(jí)鎖 - 重量級(jí)鎖。降級(jí)雖然在某些GC場(chǎng)景如STW下會(huì)發(fā)生但非常罕見(jiàn)。這是因?yàn)樯?jí)過(guò)程是競(jìng)爭(zhēng)加劇的體現(xiàn)是為了在保證線程安全的前提下從性能最優(yōu)無(wú)競(jìng)爭(zhēng)逐步退讓到功能最全高競(jìng)爭(zhēng)。降級(jí)帶來(lái)的收益很小且實(shí)現(xiàn)復(fù)雜所以JVM默認(rèn)不進(jìn)行鎖降級(jí)。理解Mark Word的布局是分析所有鎖狀態(tài)變化的基礎(chǔ)。接下來(lái)我們就沿著鎖升級(jí)的路徑一步步拆解。4. 鎖升級(jí)全流程深度拆解從偏向鎖到重量級(jí)鎖鎖升級(jí)Lock Inflation是synchronized性能優(yōu)化的核心其目標(biāo)是減少在無(wú)競(jìng)爭(zhēng)或低競(jìng)爭(zhēng)情況下的鎖開(kāi)銷。整個(gè)過(guò)程是JVM自適應(yīng)優(yōu)化的典范。4.1 偏向鎖Biased Locking消除無(wú)競(jìng)爭(zhēng)同步的開(kāi)銷設(shè)計(jì)目標(biāo)在“鎖只會(huì)被同一個(gè)線程多次訪問(wèn)”的理想情況下消除同步操作本身的開(kāi)銷。例如在大部分Web應(yīng)用中許多對(duì)象如線程私有的SimpleDateFormat或某些緩存對(duì)象從生到死都只被一個(gè)線程訪問(wèn)。工作原理加鎖當(dāng)?shù)谝粋€(gè)線程訪問(wèn)同步塊時(shí)JVM會(huì)檢查對(duì)象Mark Word中的鎖標(biāo)志位和偏向模式位。如果處于可偏向狀態(tài)匿名偏向狀態(tài)或無(wú)鎖狀態(tài)則通過(guò)CAS操作將當(dāng)前線程ID寫入Mark Word。如果成功該線程就持有了偏向鎖。注意此時(shí)并沒(méi)有真正的“加鎖”操作只是打了個(gè)標(biāo)記。執(zhí)行在持有偏向鎖的線程后續(xù)進(jìn)入同步塊時(shí)JVM只需檢查Mark Word中的線程ID是否是自己。如果是直接通過(guò)驗(yàn)證無(wú)需任何同步操作如CAS、操作系統(tǒng)調(diào)用性能接近無(wú)鎖。撤銷Revoke這是偏向鎖最復(fù)雜的部分。當(dāng)有另一個(gè)線程嘗試競(jìng)爭(zhēng)這個(gè)偏向鎖時(shí)持有偏向鎖的線程需要被撤銷偏向鎖。撤銷是一個(gè)安全點(diǎn)Safepoint操作需要暫停持有鎖的線程STW。如果原持有線程已經(jīng)不活動(dòng)如已終止則直接將對(duì)象置為匿名偏向線程ID為空或無(wú)鎖狀態(tài)允許新線程通過(guò)CAS重新偏向。如果原持有線程仍然存活則遍歷該線程的棧找到所有與該鎖對(duì)象相關(guān)的鎖記錄Lock Record將鎖記錄和對(duì)象頭的Mark Word進(jìn)行比對(duì)決定是升級(jí)為輕量級(jí)鎖還是重量級(jí)鎖。這個(gè)過(guò)程相對(duì)耗時(shí)。為什么JDK 15后默認(rèn)關(guān)閉偏向鎖正因?yàn)槠蜴i的撤銷成本高昂在存在明顯鎖競(jìng)爭(zhēng)的現(xiàn)代應(yīng)用如高并發(fā)微服務(wù)中偏向鎖帶來(lái)的收益往往小于其初始化、撤銷的開(kāi)銷。從JDK 15開(kāi)始偏向鎖被默認(rèn)禁用-XX:-UseBiasedLocking。但在理解其原理上它仍是經(jīng)典的設(shè)計(jì)。實(shí)操心得如果你的應(yīng)用是偏向鎖友好的例如大量線程局部對(duì)象可以通過(guò)JVM參數(shù)-XX:UseBiasedLocking -XX:BiasedLockingStartupDelay0在啟動(dòng)時(shí)立即開(kāi)啟偏向鎖。但務(wù)必通過(guò)jstack或JFR監(jiān)控鎖競(jìng)爭(zhēng)情況評(píng)估其實(shí)際收益。4.2 輕量級(jí)鎖Lightweight Lock應(yīng)對(duì)輕度競(jìng)爭(zhēng)當(dāng)偏向鎖被撤銷或者一開(kāi)始就存在多個(gè)線程輕度競(jìng)爭(zhēng)時(shí)鎖會(huì)升級(jí)為輕量級(jí)鎖。它的核心思想是通過(guò)CAS自旋來(lái)避免直接進(jìn)入操作系統(tǒng)內(nèi)核態(tài)的阻塞適用于鎖持有時(shí)間非常短且線程交替執(zhí)行的場(chǎng)景。加鎖流程Slow Path在當(dāng)前線程的棧幀中創(chuàng)建一個(gè)名為鎖記錄Lock Record或Displaced Mark Word的空間。將對(duì)象當(dāng)前的Mark Word復(fù)制到鎖記錄中稱為Displaced Mark Word。然后使用CAS操作嘗試將對(duì)象頭中的Mark Word替換為指向該鎖記錄的指針。如果成功當(dāng)前線程獲得鎖并將鎖標(biāo)志位改為00。如果CAS失敗說(shuō)明已經(jīng)有其他線程搶先獲得了輕量級(jí)鎖這時(shí)會(huì)啟動(dòng)自旋等待。自旋的目的是期望持有鎖的線程能很快釋放鎖。解鎖流程使用CAS操作將Displaced Mark Word即之前備份的原始Mark Word寫回對(duì)象頭。如果CAS成功則解鎖完成。如果CAS失敗說(shuō)明在持有鎖期間鎖已經(jīng)膨脹為重量級(jí)鎖了有其他線程競(jìng)爭(zhēng)導(dǎo)致。此時(shí)解鎖操作需要走重量級(jí)鎖的釋放流程喚醒等待隊(duì)列中的線程。自旋的代價(jià)與自適應(yīng)自旋Adaptive Spinning 自旋空轉(zhuǎn)會(huì)消耗CPU。如果鎖被持有的時(shí)間很長(zhǎng)或者競(jìng)爭(zhēng)激烈自旋就會(huì)變成巨大的性能浪費(fèi)。因此HotSpot引入了自適應(yīng)自旋。JVM會(huì)根據(jù)之前同一個(gè)鎖的自旋成功情況動(dòng)態(tài)調(diào)整自旋次數(shù)。如果最近自旋經(jīng)常成功JVM就認(rèn)為這個(gè)鎖很適合自旋會(huì)允許更長(zhǎng)的自旋時(shí)間反之如果很少成功JVM可能會(huì)直接放棄自旋減少CPU空轉(zhuǎn)。4.3 重量級(jí)鎖Heavyweight Lock最終保障當(dāng)輕量級(jí)鎖自旋失敗超過(guò)閾值或者一個(gè)線程在持有輕量級(jí)鎖時(shí)又有新的線程來(lái)競(jìng)爭(zhēng)鎖就會(huì)膨脹為重量級(jí)鎖。這是synchronized的最終形態(tài)其實(shí)現(xiàn)依賴于操作系統(tǒng)提供的互斥量Mutex。Monitor對(duì)象管程 重量級(jí)鎖的核心是一個(gè)稱為ObjectMonitor的對(duì)象C實(shí)現(xiàn)它存在于堆中或者JVM的元空間。對(duì)象頭中的Mark Word此時(shí)鎖標(biāo)志位為10存儲(chǔ)著指向這個(gè)ObjectMonitor對(duì)象的指針。ObjectMonitor內(nèi)部維護(hù)著幾個(gè)關(guān)鍵隊(duì)列_owner指向持有鎖的線程。_EntryList處于阻塞BLOCKED狀態(tài)的線程隊(duì)列。當(dāng)一個(gè)線程嘗試獲取鎖失敗后會(huì)被放入這個(gè)隊(duì)列等待操作系統(tǒng)調(diào)度將其掛起。_WaitSet處于等待WAITING狀態(tài)的線程隊(duì)列。當(dāng)持有鎖的線程調(diào)用Object.wait()方法后會(huì)釋放鎖并進(jìn)入這個(gè)隊(duì)列。從用戶態(tài)到內(nèi)核態(tài)的切換 這是重量級(jí)鎖性能開(kāi)銷的主要來(lái)源。當(dāng)線程無(wú)法獲取鎖時(shí)它會(huì)被操作系統(tǒng)掛起從運(yùn)行態(tài)變?yōu)樽枞麘B(tài)并放入等待隊(duì)列。這個(gè)掛起操作需要進(jìn)行上下文切換從用戶態(tài)切換到內(nèi)核態(tài)由操作系統(tǒng)內(nèi)核進(jìn)行線程調(diào)度。后續(xù)當(dāng)鎖被釋放需要喚醒等待線程時(shí)又需要進(jìn)行一次上下文切換。頻繁的上下文切換會(huì)嚴(yán)重消耗CPU資源導(dǎo)致系統(tǒng)吞吐量下降。重量級(jí)鎖的公平性問(wèn)題synchronized內(nèi)置的Monitor機(jī)制是非公平鎖。當(dāng)鎖被釋放時(shí)正在自旋嘗試獲取輕量級(jí)鎖的線程以及剛到達(dá)準(zhǔn)備獲取鎖的線程會(huì)和_EntryList中被喚醒的線程一起競(jìng)爭(zhēng)誰(shuí)先搶到就是誰(shuí)的并不保證先阻塞的線程先獲得鎖。這種策略在高并發(fā)下通常能獲得更高的吞吐量。5. 內(nèi)存語(yǔ)義synchronized如何保證可見(jiàn)性與有序性synchronized不僅能保證原子性互斥執(zhí)行還能保證可見(jiàn)性和有序性。這源于Java內(nèi)存模型JMM為synchronized規(guī)定嚴(yán)格的內(nèi)存語(yǔ)義。1. 可見(jiàn)性Visibility保證JMM規(guī)定線程在解鎖monitorexit一個(gè)鎖之前必須把自己工作內(nèi)存中對(duì)共享變量的修改刷新到主內(nèi)存。線程在加鎖monitorenter一個(gè)鎖時(shí)會(huì)清空本地工作內(nèi)存中該共享變量的值從而必須從主內(nèi)存中重新讀取最新值。這就建立了一個(gè)“同步”機(jī)制前一個(gè)線程的修改結(jié)果對(duì)后續(xù)獲得同一個(gè)鎖的線程一定是可見(jiàn)的。這解決了CPU緩存不一致帶來(lái)的內(nèi)存可見(jiàn)性問(wèn)題。2. 有序性O(shè)rdering保證synchronized通過(guò)“互斥”間接保證了有序性。由于臨界區(qū)內(nèi)的代碼在任意時(shí)刻只能被一個(gè)線程執(zhí)行因此線程觀察到的臨界區(qū)內(nèi)代碼的執(zhí)行順序就是程序順序Program Order。這防止了臨界區(qū)內(nèi)的代碼發(fā)生重排序盡管編譯器仍可能在臨界區(qū)內(nèi)進(jìn)行不改變單線程語(yǔ)義的重排。更重要的是synchronized遵循管程Monitor的Happens-Before規(guī)則同一個(gè)鎖的解鎖操作 Happens-Before 于后續(xù)對(duì)這個(gè)鎖的加鎖操作。 這條規(guī)則與volatile的寫入-讀取規(guī)則類似是構(gòu)建線程間操作順序的基礎(chǔ)。與volatile的對(duì)比volatile只保證單個(gè)變量的讀寫原子性、可見(jiàn)性以及防止指令重排序內(nèi)存屏障。synchronized保證整個(gè)臨界區(qū)代碼的原子性、可見(jiàn)性和有序性功能更強(qiáng)大但開(kāi)銷也更大。在僅需要保證一個(gè)共享變量的可見(jiàn)性且操作本身是原子如賦值時(shí)volatile是更輕量級(jí)的選擇。如果需要復(fù)合操作如i則必須使用synchronized。6. 實(shí)戰(zhàn)避坑與性能調(diào)優(yōu)指南理解了原理最終要落到實(shí)戰(zhàn)。下面是我在多年開(kāi)發(fā)和調(diào)優(yōu)中總結(jié)的關(guān)于synchronized的常見(jiàn)“坑”和優(yōu)化建議。6.1 鎖粒度選擇粗粒度 vs 細(xì)粒度錯(cuò)誤示例粗粒度過(guò)大public class OrderService { private final Object globalLock new Object(); public void createOrder() { synchronized(globalLock) { /* 耗時(shí)IO操作 */ } } public void updateOrder() { synchronized(globalLock) { /* 計(jì)算操作 */ } } public void queryOrder() { synchronized(globalLock) { /* 只讀操作 */ } } }所有方法共用一把全局鎖queryOrder這樣的只讀操作也會(huì)阻塞createOrder并發(fā)性能極差。優(yōu)化建議細(xì)化鎖粒度public class OrderService { private final MapLong, Object orderLocks new ConcurrentHashMap(); public void updateOrder(Long orderId) { Object lock orderLocks.computeIfAbsent(orderId, k - new Object()); synchronized(lock) { // 只鎖住特定訂單的操作 } } }使用與業(yè)務(wù)數(shù)據(jù)如訂單ID關(guān)聯(lián)的鎖對(duì)象將鎖的競(jìng)爭(zhēng)范圍從整個(gè)服務(wù)縮小到單個(gè)業(yè)務(wù)實(shí)體大幅提升并發(fā)度。注意這里使用ConcurrentHashMap來(lái)管理鎖對(duì)象避免為每個(gè)訂單永久創(chuàng)建鎖對(duì)象導(dǎo)致內(nèi)存泄漏。6.2 死鎖Deadlock的識(shí)別與預(yù)防死鎖的四個(gè)必要條件互斥、持有并等待、不可剝奪、循環(huán)等待。synchronized直接涉及前三個(gè)。經(jīng)典死鎖代碼// 線程1 synchronized (lockA) { Thread.sleep(100); synchronized (lockB) { ... } } // 線程2 synchronized (lockB) { Thread.sleep(100); synchronized (lockA) { ... } }排查與預(yù)防使用工具診斷jstack是首選。運(yùn)行jstack -l pid在輸出中查找deadlock關(guān)鍵詞JVM能自動(dòng)檢測(cè)并報(bào)告死鎖鏈。統(tǒng)一鎖順序強(qiáng)制所有線程以相同的全局順序獲取鎖。例如規(guī)定必須先獲取lockA再獲取lockB。使用嘗試鎖tryLocksynchronized不支持但你可以使用ReentrantLock的tryLock(long, TimeUnit)方法獲取失敗時(shí)進(jìn)行回退或重試打破“持有并等待”。設(shè)置超時(shí)同樣synchronized原生不支持ReentrantLock支持帶超時(shí)的tryLock。6.3 鎖競(jìng)爭(zhēng)熱點(diǎn)分析與優(yōu)化在高并發(fā)場(chǎng)景下即使細(xì)化了鎖粒度某些“熱點(diǎn)”資源如全局計(jì)數(shù)器、庫(kù)存中心仍可能成為瓶頸。診斷工具JFR (Java Flight Recorder)低開(kāi)銷的性能剖析工具可以清晰看到哪些鎖上發(fā)生了最嚴(yán)重的競(jìng)爭(zhēng)lock-instance事件。Async Profiler可以生成火焰圖直觀顯示線程在鎖等待park狀態(tài)上花費(fèi)的CPU時(shí)間比例。優(yōu)化策略鎖分離Lock StripingConcurrentHashMap是典范。它將數(shù)據(jù)分成多個(gè)段Segment/JDK8后是桶每個(gè)段獨(dú)立加鎖。寫全局計(jì)數(shù)器時(shí)可以考慮使用類似的思想例如按線程ID或請(qǐng)求來(lái)源進(jìn)行哈希分片每個(gè)片一個(gè)計(jì)數(shù)器最后匯總。樂(lè)觀鎖與CAS對(duì)于爭(zhēng)用激烈的“讀多寫少”場(chǎng)景考慮使用AtomicLong、LongAdderJDK8等基于CAS的原子類。LongAdder內(nèi)部使用了分段累加的思想在高并發(fā)寫入時(shí)性能遠(yuǎn)優(yōu)于synchronized和AtomicLong。無(wú)鎖數(shù)據(jù)結(jié)構(gòu)深入研究Disruptor、Amino等無(wú)鎖隊(duì)列框架它們?cè)跇O高性能要求的場(chǎng)景下可以完全避免鎖。6.4 對(duì)性能的誤解與澄清誤解一synchronized一定比ReentrantLock慢。在低競(jìng)爭(zhēng)場(chǎng)景下經(jīng)過(guò)鎖升級(jí)優(yōu)化后的synchronized性能與ReentrantLock相差無(wú)幾甚至可能更優(yōu)因?yàn)镴VM能對(duì)其進(jìn)行深度優(yōu)化。ReentrantLock的優(yōu)勢(shì)在于靈活性可中斷、可超時(shí)、可嘗試獲取、支持公平鎖、可以綁定多個(gè)條件變量Condition。選擇哪個(gè)取決于業(yè)務(wù)需求而非單純的性能臆測(cè)。誤解二應(yīng)該盡量避免使用synchronized。恰恰相反對(duì)于大多數(shù)并發(fā)控制場(chǎng)景synchronized應(yīng)是首選。它的優(yōu)點(diǎn)非常明顯語(yǔ)法簡(jiǎn)單、由JVM自動(dòng)釋放鎖、與wait()/notify()機(jī)制天然集成、經(jīng)過(guò)長(zhǎng)期優(yōu)化極其穩(wěn)定。只有在synchronized的功能無(wú)法滿足需求時(shí)如需要上述ReentrantLock的靈活特性才考慮使用顯式鎖。誤解三鎖住的對(duì)象越小越好。鎖對(duì)象的選擇至關(guān)重要。必須鎖住所有競(jìng)爭(zhēng)線程都能看到、且唯一對(duì)應(yīng)的那個(gè)對(duì)象。錯(cuò)誤示例如下// 錯(cuò)誤每個(gè)線程鎖的是自己新創(chuàng)建的Object根本起不到同步作用 public void wrongMethod() { Object lock new Object(); synchronized(lock) { // ... } } // 正確使用共享的、final的對(duì)象作為鎖 private final Object lock new Object(); public void correctMethod() { synchronized(lock) { // ... } }7. 從synchronized看JVM的鎖優(yōu)化趨勢(shì)通過(guò)對(duì)synchronized的深度剖析我們也能管中窺豹看到JVM在并發(fā)優(yōu)化上的思路演變。1. 從“重量”到“輕量”再到“避免”鎖升級(jí)路徑本身就是這一思路的體現(xiàn)先嘗試無(wú)開(kāi)銷的偏向鎖不行再嘗試用戶態(tài)自旋的輕量級(jí)鎖最后才退回到開(kāi)銷大的內(nèi)核態(tài)重量級(jí)鎖。而JDK 15默認(rèn)關(guān)閉偏向鎖則反映出在普遍多核、高競(jìng)爭(zhēng)的環(huán)境下過(guò)于復(fù)雜的優(yōu)化策略本身可能成為負(fù)擔(dān)有時(shí)“少即是多”。2. 硬件友好的優(yōu)化自適應(yīng)自旋、鎖消除Lock Elimination、鎖粗化Lock Coarsening等優(yōu)化都是JVM在運(yùn)行時(shí)根據(jù)代碼模式和硬件特性如CPU緩存一致性協(xié)議進(jìn)行的智能調(diào)整。例如鎖消除是逃逸分析的成果如果JVM證明一個(gè)鎖對(duì)象不可能被其他線程訪問(wèn)就會(huì)直接去掉同步操作。3. 與新的并發(fā)編程模型融合隨著Project Loom的推進(jìn)虛擬線程Virtual Threads成為熱點(diǎn)。在虛擬線程模型中一個(gè)線程因?yàn)镮/O阻塞而被掛起是極其廉價(jià)的。這可能會(huì)改變我們對(duì)“鎖競(jìng)爭(zhēng)”成本的認(rèn)知。傳統(tǒng)的synchronized在虛擬線程上工作良好但那些會(huì)導(dǎo)致平臺(tái)線程 carrier thread 被阻塞的重量級(jí)鎖競(jìng)爭(zhēng)其影響可能被放大或轉(zhuǎn)化。未來(lái)synchronized的優(yōu)化可能會(huì)與虛擬線程的調(diào)度器更深度地結(jié)合。我個(gè)人在性能調(diào)優(yōu)時(shí)有一個(gè)習(xí)慣不會(huì)一開(kāi)始就質(zhì)疑synchronized的性能。我會(huì)先寫出正確、清晰的同步代碼然后借助JFR、jstack等工具進(jìn)行壓測(cè)和 profiling。只有當(dāng)數(shù)據(jù)明確顯示某個(gè)synchronized塊是真正的性能瓶頸競(jìng)爭(zhēng)激烈、持有時(shí)間長(zhǎng)時(shí)我才會(huì)考慮更復(fù)雜的優(yōu)化方案比如改用ReentrantLock、使用并發(fā)容器、甚至重構(gòu)業(yè)務(wù)邏輯來(lái)降低競(jìng)爭(zhēng)。在絕大多數(shù)情況下synchronized的簡(jiǎn)潔性和可靠性帶來(lái)的價(jià)值遠(yuǎn)超過(guò)那一點(diǎn)點(diǎn)可能存在的、未經(jīng)證實(shí)的性能差異。把基礎(chǔ)原理吃透在合適的場(chǎng)景做出合適的選擇這才是應(yīng)對(duì)“硬核”面試和復(fù)雜系統(tǒng)的真正底氣。