如果你是 Java 面試官在同一個(gè)候選人面前連續(xù)拋三個(gè)問(wèn)題——“悲觀(guān)鎖和樂(lè)觀(guān)鎖怎么實(shí)現(xiàn)”“兩者區(qū)別是什么”“庫(kù)存扣減你選哪個(gè)”——第一輪通常能聽(tīng)到標(biāo)準(zhǔn)答案synchronized 是悲觀(guān)鎖CAS 是樂(lè)觀(guān)鎖數(shù)據(jù)庫(kù)里可以用版本號(hào)實(shí)現(xiàn)樂(lè)觀(guān)鎖。這個(gè)回答不算錯(cuò)但只答到了 API 層。再追問(wèn)一句“你選的方案在沖突率高和沖突率低兩種場(chǎng)景下代價(jià)分別是多少”很多人會(huì)停住。原因在于悲觀(guān)鎖和樂(lè)觀(guān)鎖本質(zhì)上不是兩個(gè)類(lèi)也不是兩個(gè)關(guān)鍵字而是兩種并發(fā)控制策略。它們的核心分歧不是“用不用鎖”而是“你愿意在沖突發(fā)生之前付出多少代價(jià)還是在沖突發(fā)生之后再去補(bǔ)救”。哪怕這兩年 Java 生態(tài)里 Spring AI、大模型應(yīng)用的討論很熱鬧并發(fā)編程依然是面試?yán)镒钅芎Y人的一塊。把這個(gè)底層邏輯想清楚面試題、線(xiàn)上問(wèn)題排查和技術(shù)選型其實(shí)是一條線(xiàn)。1. 先把你對(duì)鎖的理解拔高一層這不是 API是策略1.1 悲觀(guān)鎖的默認(rèn)假設(shè)沖突一定會(huì)發(fā)生悲觀(guān)鎖的思維模型是我操作的數(shù)據(jù)很可能同時(shí)被別人修改所以我必須先把我關(guān)心的資源保護(hù)起來(lái)確保在我讀完、算完、寫(xiě)完的整個(gè)過(guò)程中別人碰不到它。這句話(huà)里有三個(gè)關(guān)鍵詞讀、算、寫(xiě)。悲觀(guān)鎖保護(hù)的是一段完整操作過(guò)程而不只是一個(gè)“更新語(yǔ)句”。鎖定期間其他人只能等待。這種等待在單機(jī) Java 里是線(xiàn)程被阻塞在數(shù)據(jù)庫(kù)里是事務(wù)等待行鎖或表鎖。阻塞本身不是問(wèn)題問(wèn)題是阻塞時(shí)間取決于臨界區(qū)代碼要跑多久。比如這段代碼public synchronized void deductStock(Long skuId, int num) { // 注意這里的同步塊鎖的是當(dāng)前對(duì)象不是數(shù)據(jù)庫(kù)行 Stock stock stockMapper.selectById(skuId); if (stock.getCount() num) { throw new BizException(庫(kù)存不足); } stock.setCount(stock.getCount() - num); stockMapper.updateById(stock); }看起來(lái)邏輯完整實(shí)際有兩個(gè)隱蔽問(wèn)題。第一synchronized 鎖的是當(dāng)前 Java 對(duì)象在多實(shí)例部署時(shí)完全無(wú)效即使單實(shí)例它也鎖住了所有走這個(gè)方法的事務(wù)而不是只鎖某一款商品的庫(kù)存。第二持鎖期間做了數(shù)據(jù)庫(kù)查詢(xún)和更新鎖的生命周期被網(wǎng)絡(luò) IO 拉長(zhǎng)。并發(fā)一高整個(gè)接口的 TPS 會(huì)被拖垮。不是說(shuō) synchronized 不能用在這里而是你要先分清鎖保護(hù)的邊界是“對(duì)象”還是“數(shù)據(jù)行”鎖的生命周期覆蓋的是“內(nèi)存計(jì)算”還是“跨網(wǎng)絡(luò) IO”。這是在悲觀(guān)鎖場(chǎng)景里最常見(jiàn)的錯(cuò)誤。1.2 樂(lè)觀(guān)鎖的默認(rèn)假設(shè)沖突是少數(shù)情況樂(lè)觀(guān)鎖不做提前保護(hù)。它先把任務(wù)做完然后在“寫(xiě)回”的那一步檢查在我操作期間有沒(méi)有別人改過(guò)這個(gè)數(shù)據(jù)如果有就放棄或者重試。對(duì)應(yīng)的 Java 實(shí)現(xiàn)就是 CAS比較當(dāng)前值與預(yù)期值一樣就更新不一樣就說(shuō)明有人搶先了。數(shù)據(jù)庫(kù)層面就是版本號(hào)或狀態(tài)條件更新更新時(shí)帶上 version 當(dāng)前版本如果影響行數(shù)是 0說(shuō)明版本已經(jīng)變了。這兩種策略其實(shí)是兩種人生哲學(xué)一個(gè)覺(jué)得“路上一定會(huì)堵車(chē)所以我提前兩個(gè)小時(shí)出門(mén)”一個(gè)覺(jué)得“路上大概率不堵我先出門(mén)真堵了再改路線(xiàn)”。不能說(shuō)哪個(gè)更好要看你在什么城市、什么時(shí)間出門(mén)。1.3 為什么很多人的理解停留在“實(shí)現(xiàn)”層面主要原因是 Java 并發(fā)編程的學(xué)習(xí)順序。大多數(shù)人都是先學(xué) synchronized再學(xué) ReentrantLock然后學(xué) AtomicInteger最后學(xué)數(shù)據(jù)庫(kù)悲觀(guān)鎖、樂(lè)觀(guān)鎖。學(xué)的是 API而 API 背后是一類(lèi)策略。面試官想聽(tīng)到的恰恰是策略層的東西也就是你怎么把業(yè)務(wù)映射到某種策略上。所以這篇文章先不講“哪個(gè)鎖更好用”而是先把兩種策略的代價(jià)模型講清楚。后面的所有實(shí)現(xiàn)和場(chǎng)景題都是從這個(gè)模型推出來(lái)的。2. Java 里的悲觀(guān)鎖不止 synchronized關(guān)鍵在鎖的邊界2.1 synchronized 的常見(jiàn)寫(xiě)法與鎖升級(jí)synchronized 是 JVM 原生支持的悲觀(guān)鎖實(shí)現(xiàn)使用簡(jiǎn)單不需要手動(dòng)釋放。很多資料都會(huì)講它有一個(gè)鎖升級(jí)過(guò)程偏向鎖、輕量級(jí)鎖、重量級(jí)鎖JVM 會(huì)根據(jù)競(jìng)爭(zhēng)程度自動(dòng)升級(jí)。這部分細(xì)節(jié)在不同 JDK 版本上有調(diào)整背題時(shí)可以了解落地時(shí)不要依賴(lài)某個(gè)版本的鎖行為。由此產(chǎn)生一個(gè)誤解很多人以為 synchronized 天生很慢。實(shí)際上在低競(jìng)爭(zhēng)場(chǎng)景下JVM 會(huì)做大量?jī)?yōu)化未必會(huì)膨脹到重量級(jí)鎖。反過(guò)來(lái)在高競(jìng)爭(zhēng)場(chǎng)景下重量級(jí)鎖會(huì)讓線(xiàn)程阻塞喚醒性能會(huì)明顯下降。所以評(píng)估 synchronized 性能不能簡(jiǎn)單說(shuō)“快”或“慢”要看競(jìng)爭(zhēng)烈度。這里有一個(gè)更實(shí)際的經(jīng)驗(yàn)很多人用 synchronized 時(shí)習(xí)慣直接加在方法上。如果這個(gè)方法里只有幾行內(nèi)存計(jì)算問(wèn)題不大如果方法里有數(shù)據(jù)庫(kù)查詢(xún)、遠(yuǎn)程調(diào)用鎖的整體代價(jià)就要重新評(píng)估。鎖粒度不是越小越好但“一個(gè)方法整體加鎖”通常是過(guò)度設(shè)計(jì)。2.2 ReentrantLock可超時(shí)、可中斷、可公平ReentrantLock 是 java.util.concurrent 包提供的悲觀(guān)鎖比 synchronized 更靈活lock()與unlock()成對(duì)出現(xiàn)必須手動(dòng)釋放。tryLock(timeout, unit)可以等待有限時(shí)間?？梢皂憫?yīng)中斷。構(gòu)造時(shí)可以選公平鎖但公平鎖通常不是性能最優(yōu)解。Lock lock new ReentrantLock(); if (lock.tryLock(3, TimeUnit.SECONDS)) { try { // 臨界區(qū)代碼 } finally { lock.unlock(); } } else { // 獲取失敗后的降級(jí)邏輯 }這段代碼的價(jià)值不是“換一個(gè)更高級(jí)的鎖”而是它給了你一個(gè)失敗出口。悲觀(guān)鎖最怕的就是獲取不到鎖就一直等下去。tryLock 讓調(diào)用方可以在有限時(shí)間內(nèi)決定是重試、降級(jí)還是直接報(bào)錯(cuò)。真實(shí)系統(tǒng)里“拿不到鎖怎么辦”往往比“怎么拿到鎖”更重要。2.3 悲觀(guān)鎖真正燒錢(qián)的地方持鎖時(shí)間數(shù)據(jù)庫(kù)悲觀(guān)鎖的經(jīng)典寫(xiě)法是SELECT * FROM stock WHERE sku_id ? FOR UPDATE;FOR UPDATE 會(huì)對(duì)命中的行加寫(xiě)鎖鎖會(huì)一直持有到事務(wù)提交或回滾。這里要特別注意這個(gè)鎖是數(shù)據(jù)庫(kù)層的行鎖不是 Java 層的對(duì)象鎖。多實(shí)例部署時(shí)它能正常工作前提是大家都操作同一張表、同一行數(shù)據(jù)而且走的是同一個(gè)數(shù)據(jù)庫(kù)。還要留意如果查詢(xún)沒(méi)有走索引數(shù)據(jù)庫(kù)有可能從行鎖退化成更粗粒度的鎖影響范圍會(huì)突然變大。最需要警惕的是事務(wù)里往往不只是“查一行、改一行”。一個(gè)事務(wù)如果包含多個(gè)查詢(xún)、外部接口調(diào)用、甚至網(wǎng)絡(luò)請(qǐng)求鎖的持有時(shí)間會(huì)被拉得很長(zhǎng)。鎖等待鏈一長(zhǎng)數(shù)據(jù)庫(kù)連接池就會(huì)被占滿(mǎn)最后表現(xiàn)為整個(gè)服務(wù)不可用。注意用悲觀(guān)鎖時(shí)鎖內(nèi)只放必須的操作鎖外的內(nèi)容越少越好。持鎖時(shí)間而不是鎖本身才是悲觀(guān)鎖真正的成本來(lái)源。3. Java 里的樂(lè)觀(guān)鎖CAS、版本號(hào)與 ABA3.1 CAS 是怎么工作的CAS 全稱(chēng)是 Compare And Swap是一組 CPU 指令級(jí)的原子操作。它做的事情非常簡(jiǎn)單比較內(nèi)存里的當(dāng)前值是否等于預(yù)期值等于就更新為新值不等于就返回失敗。Java 里最常用的是java.util.concurrent.atomic包下的類(lèi)AtomicInteger stockCount new AtomicInteger(100); while (true) { int current stockCount.get(); if (current 0) { throw new BizException(庫(kù)存不足); } if (stockCount.compareAndSet(current, current - 1)) { break; } }注意這個(gè) while 循環(huán)。CAS 失敗后必須重試否則扣減動(dòng)作就丟失了。這個(gè)循環(huán)在低沖突率下幾乎一次通過(guò)在高沖突率下會(huì)變成空轉(zhuǎn)CPU 占用上升。這就是樂(lè)觀(guān)鎖的典型代價(jià)模型平時(shí)幾乎無(wú)鎖開(kāi)銷(xiāo)一旦沖突發(fā)生調(diào)用方要自己承擔(dān)重試成本。它不是沒(méi)有成本而是把成本從“沖突前”挪到了“沖突后”。3.2 從 AtomicInteger 到數(shù)據(jù)庫(kù)版本號(hào)單機(jī)內(nèi)存里可以用 AtomicInteger但多實(shí)例部署時(shí)Java 堆內(nèi)的原子變量無(wú)法跨進(jìn)程生效。這時(shí)數(shù)據(jù)庫(kù)的版本號(hào)機(jī)制就很有用UPDATE stock SET count count - 1, version version 1 WHERE sku_id ? AND version 5;如果影響行數(shù)為 1說(shuō)明更新成功如果影響行數(shù)為 0說(shuō)明 version 已經(jīng)不是 5說(shuō)明別人搶先改過(guò)了。為什么用 version 而不用 time 或 count因?yàn)榘姹咎?hào)只做一件事判斷這個(gè)數(shù)據(jù)是否發(fā)生過(guò)變化。它不需要可讀不需要精確到毫秒只要保證“每次修改都會(huì) 1”。時(shí)間戳可能出現(xiàn)同一毫秒內(nèi)兩次修改count 作為新舊值比較時(shí)也可能被業(yè)務(wù)數(shù)字干擾都不如單調(diào)遞增的 version 語(yǔ)義干凈。在 Spring 生態(tài)里MyBatis-Plus 通過(guò) Version 注解和樂(lè)觀(guān)鎖插件做這件事JPA 也有 Version。這些框架只是幫你生成帶版本條件的 UPDATE 語(yǔ)句核心原理沒(méi)有變。不管框架多方便你都要清楚沒(méi)有自帶的重試機(jī)制數(shù)據(jù)庫(kù)也不會(huì)幫你重試。3.3 ABA 問(wèn)題為什么要用版本號(hào)而不是時(shí)間戳CAS 有一個(gè)著名的 ABA 問(wèn)題線(xiàn)程 A 讀到值是 1線(xiàn)程 B 把它改成 2又改回 1線(xiàn)程 A 再 CAS 時(shí)發(fā)現(xiàn)還是 1于是判定“沒(méi)有人改過(guò)”。實(shí)際上數(shù)據(jù)已經(jīng)被改過(guò)兩次。解決思路不是用“當(dāng)前值”做比較而是用“帶變化次數(shù)的值”做比較。AtomicStampedReference 就是把值和版本號(hào)打包在一起。數(shù)據(jù)庫(kù)里的 version 字段同理它的核心價(jià)值是提供一個(gè)“值相同但已發(fā)生過(guò)變化”的識(shí)別器。所以在面試?yán)镎劦綐?lè)觀(guān)鎖時(shí)如果能主動(dòng)提到 ABA 問(wèn)題會(huì)明顯比只說(shuō)“版本號(hào)防止超賣(mài)”更有區(qū)分度。它不是面試官想要的標(biāo)準(zhǔn)答案而是區(qū)分記憶型選手和理解型選手的分界線(xiàn)。4. 悲觀(guān)鎖 vs 樂(lè)觀(guān)鎖差異不是快慢而是失敗代價(jià)模型4.1 一張表看清八個(gè)維度對(duì)比維度悲觀(guān)鎖樂(lè)觀(guān)鎖核心假設(shè)沖突很可能發(fā)生沖突是少數(shù)加鎖時(shí)機(jī)操作前先加鎖寫(xiě)入時(shí)檢查沖突沖突處理等待對(duì)方釋放重試或放棄典型 Java 實(shí)現(xiàn)synchronized、ReentrantLockAtomicInteger、AtomicStampedReference數(shù)據(jù)庫(kù)實(shí)現(xiàn)SELECT ... FOR UPDATEversion 條件更新沖突前代價(jià)加鎖、阻塞、喚醒幾乎為零沖突后代價(jià)排隊(duì)等待可能死鎖重試?yán)速M(fèi)一次操作更適用的場(chǎng)景寫(xiě)多讀少、高沖突讀多寫(xiě)少、低沖突這張表里最有價(jià)值的不是前幾行而是最后兩行沖突前代價(jià)和沖突后代價(jià)。4.2 沖突前代價(jià) vs 沖突后代價(jià)可以把這兩種策略想象成兩種過(guò)閘機(jī)的方式。悲觀(guān)鎖是“一個(gè)人進(jìn)去閘機(jī)就鎖上后面所有人都排隊(duì)等他出來(lái)再放行”。樂(lè)觀(guān)鎖是“所有人都直接進(jìn)每個(gè)人進(jìn)的時(shí)候刷一下卡如果閘機(jī)提示剛才已經(jīng)有人進(jìn)過(guò)就退回去再排一次”。排隊(duì)等待是沖突前的代價(jià)退回去重來(lái)是沖突后的代價(jià)。當(dāng)沖突概率很低時(shí)悲觀(guān)鎖會(huì)為“幾乎不會(huì)發(fā)生的沖突”持續(xù)支付加鎖、阻塞、喚醒的代價(jià)樂(lè)觀(guān)鎖在“幾乎不會(huì)發(fā)生的沖突”上則幾乎不花錢(qián)。當(dāng)沖突概率變高時(shí)樂(lè)觀(guān)鎖的重試次數(shù)會(huì)急劇上升大量請(qǐng)求會(huì)把數(shù)據(jù)庫(kù) IO 和 CPU 燒在“反復(fù)嘗試”上悲觀(guān)鎖雖然也差但鎖機(jī)制本身有排隊(duì)語(yǔ)義等待是可控的不會(huì)像自旋一樣空轉(zhuǎn)。所以真正重要的不是“哪個(gè)快”而是“哪個(gè)代價(jià)模型更符合你的業(yè)務(wù)”。這也是面試官想聽(tīng)到的東西。4.3 一句面試點(diǎn)評(píng)最加分的話(huà)面試?yán)镎f(shuō)“樂(lè)觀(guān)鎖性能好、悲觀(guān)鎖性能差”是一個(gè)危險(xiǎn)的結(jié)論。更好的說(shuō)法是“我理解悲觀(guān)鎖和樂(lè)觀(guān)鎖的本質(zhì)是兩種沖突處理策略。悲觀(guān)鎖在沖突前就支付加鎖成本適合高沖突、臨界區(qū)復(fù)雜、不能容忍重試的業(yè)務(wù)樂(lè)觀(guān)鎖把成本放到?jīng)_突后適合低沖突、臨界區(qū)短、寫(xiě)入路徑可控的業(yè)務(wù)。在庫(kù)存扣減這種高競(jìng)爭(zhēng)場(chǎng)景我會(huì)優(yōu)先評(píng)估數(shù)據(jù)庫(kù)行鎖加短事務(wù)如果熱點(diǎn)特別集中再考慮排隊(duì)或分桶。”這句話(huà)之所以加分是因?yàn)樗磉_(dá)的是選型邏輯而不只是背誦結(jié)論。5. 場(chǎng)景題實(shí)戰(zhàn)庫(kù)存扣減、訂單狀態(tài)和 Spring 事務(wù)5.1 庫(kù)存扣減為什么樂(lè)觀(guān)鎖方案要帶重試庫(kù)存扣減是面試最高頻的場(chǎng)景題。它真正難的地方不是鎖本身而是扣減動(dòng)作必須原子完成不能超賣(mài)同時(shí)不能把整個(gè)表的鎖都拖住。悲觀(guān)鎖方案是BEGIN; SELECT * FROM stock WHERE sku_id ? FOR UPDATE; -- 業(yè)務(wù)校驗(yàn)比如 stock.count 1 UPDATE stock SET count count - 1 WHERE sku_id ?; COMMIT;樂(lè)觀(guān)鎖方案是UPDATE stock SET count count - 1, version version 1 WHERE sku_id ? AND version ?; -- 影響行數(shù)為 0 則重試樂(lè)觀(guān)鎖方案看似簡(jiǎn)單但有一個(gè)隱藏要求調(diào)用方必須有重試機(jī)制。數(shù)據(jù)庫(kù)不會(huì)幫你重試。如果更新影響行數(shù)為 0不能直接把失敗拋給用戶(hù)要在業(yè)務(wù)層重新查一次、再試一次并且限制最大重試次數(shù)。重試次數(shù)設(shè)置得太高沖突高的時(shí)候每個(gè)請(qǐng)求會(huì)打很多次數(shù)據(jù)庫(kù)設(shè)置得太低用戶(hù)會(huì)頻繁看到失敗。實(shí)際工程里需要結(jié)合壓測(cè)找出一個(gè)平衡值。通常我會(huì)建議先給一個(gè)保守上限比如 3 到 5 次再根據(jù)日志里的“更新影響行數(shù)為 0”的次數(shù)做調(diào)整。5.2 Spring 里的事務(wù)邊界決定了鎖的生命周期在 Spring 的 Transactional 方法里鎖的生命周期和事務(wù)邊界綁定。悲觀(guān)鎖尤其明顯FOR UPDATE 取得的行鎖要等事務(wù)提交才釋放。這里有一個(gè)典型坑在事務(wù)里先調(diào)用遠(yuǎn)程接口再做扣減。這會(huì)讓行鎖一直掛著等遠(yuǎn)程接口返回。遠(yuǎn)程接口一旦變慢數(shù)據(jù)庫(kù)連接和行鎖都會(huì)被長(zhǎng)時(shí)間占用很快把連接池耗盡。正確做法是遠(yuǎn)程調(diào)用放在事務(wù)外或者先做本地預(yù)校驗(yàn)真正扣減時(shí)再進(jìn)短事務(wù)把事務(wù)和鎖的持續(xù)時(shí)間壓到最短。特別注意事務(wù)邊界決定鎖生命周期鎖生命周期決定并發(fā)上限。在 Spring 場(chǎng)景里關(guān)注事務(wù)邊界往往比糾結(jié)“用悲觀(guān)鎖還是樂(lè)觀(guān)鎖”更關(guān)鍵。5.3 分布式環(huán)境下鎖都是有邊界的悲觀(guān)鎖的 Java 實(shí)現(xiàn)比如 synchronized 和 ReentrantLock只在單 JVM 內(nèi)有效多實(shí)例部署時(shí)必須換成數(shù)據(jù)庫(kù)行鎖、Redis 分布式鎖或 Zookeeper 鎖。樂(lè)觀(guān)鎖因?yàn)椴灰蕾?lài) JVM 堆內(nèi)存多實(shí)例下反而更容易遷移只要共享存儲(chǔ)上的版本字段語(yǔ)義保持一致。但分布式鎖還有一個(gè)確定性問(wèn)題鎖超時(shí)。如果持有鎖的線(xiàn)程在鎖過(guò)期之后才完成操作其他線(xiàn)程就會(huì)進(jìn)入臨界區(qū)重復(fù)執(zhí)行。這屬于“鎖的邊界小于操作時(shí)間”。所以真正工程化的鎖方案要回答三個(gè)問(wèn)題鎖的獲取是否原子、鎖的釋放是否可靠、鎖的超時(shí)是否覆蓋操作的最壞時(shí)間。這三個(gè)問(wèn)題只要有一個(gè)答不上來(lái)方案就還不能上線(xiàn)。6. 從背八股到答好場(chǎng)景題一套可復(fù)用的選型框架6.1 四步選型法我在實(shí)際項(xiàng)目里總結(jié)過(guò)一套選型流程核心是四步第一步估算沖突概率。同一個(gè)數(shù)據(jù)被并發(fā)修改的頻率有多高秒殺場(chǎng)景的同一個(gè) SKU 就是高沖突普通評(píng)論點(diǎn)贊就是低沖突。第二步評(píng)估臨界區(qū)成本。操作是一句 UPDATE 就能完成還是包含查詢(xún)、校驗(yàn)、計(jì)算、遠(yuǎn)程調(diào)用臨界區(qū)越貴悲觀(guān)鎖的持有代價(jià)越大。第三步設(shè)計(jì)失敗路徑。樂(lè)觀(guān)鎖失敗后能不能重試重試一次要付出多少數(shù)據(jù)庫(kù)開(kāi)銷(xiāo)悲觀(guān)鎖拿不到鎖時(shí)是排隊(duì)等待、有限等待還是快速失敗第四步做壓測(cè)回歸。別只測(cè)正常路徑。要模擬沖突高峰、鎖等待超時(shí)、連接池耗盡、重試風(fēng)暴這些異常路徑。只有異常路徑能扛住方案才算落地。這套流程不復(fù)雜但它能把一個(gè)“八股題”變成一個(gè)“工程決策題”。面試和線(xiàn)上問(wèn)題排查都用得上。6.2 問(wèn)題排查鏈路如果在線(xiàn)上遇到鎖相關(guān)的問(wèn)題建議按下面的順序排查先看現(xiàn)象是線(xiàn)程阻塞、接口超時(shí)、TPS 下降還是數(shù)據(jù)被覆蓋、更新丟失、超賣(mài)再確認(rèn)臨界區(qū)鎖保護(hù)的代碼范圍對(duì)不對(duì)鎖內(nèi)是否包含網(wǎng)絡(luò)請(qǐng)求、長(zhǎng) SQL 或者不必要的計(jì)算再確認(rèn)鎖的生命周期事務(wù)是否正常提交異常時(shí)鎖是否被正確釋放連接是否歸還到連接池再確認(rèn)并發(fā)模型請(qǐng)求量多大沖突概率多高是否存在熱點(diǎn) key 或熱點(diǎn)行多實(shí)例是不是各鎖各的最后看實(shí)現(xiàn)邊界用的是 JVM 鎖還是數(shù)據(jù)庫(kù)鎖有沒(méi)有鎖超時(shí)有沒(méi)有重試機(jī)制ABA 有沒(méi)有被處理這個(gè)鏈路的核心思想是先搞清楚是哪一層出了問(wèn)題再?zèng)Q定改哪一層而不是一上來(lái)就換鎖。很多人一遇到性能問(wèn)題就怪鎖選錯(cuò)了實(shí)際上問(wèn)題常常出在事務(wù)邊界、鎖粒度或者連接池配置上。6.3 面試回答的黃金結(jié)構(gòu)最后回到最開(kāi)始的問(wèn)題如果面試官問(wèn)你悲觀(guān)鎖和樂(lè)觀(guān)鎖怎么答才完整我會(huì)建議按這個(gè)順序組織答案一句話(huà)定義悲觀(guān)鎖認(rèn)為沖突很可能發(fā)生所以操作前先加鎖樂(lè)觀(guān)鎖認(rèn)為沖突是少數(shù)所以操作完再校驗(yàn)。說(shuō)實(shí)現(xiàn)Java 里 synchronized、ReentrantLock、數(shù)據(jù)庫(kù) FOR UPDATE 是悲觀(guān)鎖AtomicInteger、CAS、版本號(hào)更新是樂(lè)觀(guān)鎖。說(shuō)關(guān)鍵區(qū)別沖突前代價(jià)和沖突后代價(jià)不同悲觀(guān)鎖適合高沖突、臨界區(qū)復(fù)雜樂(lè)觀(guān)鎖適合低沖突、臨界區(qū)短。說(shuō)一個(gè)場(chǎng)景題庫(kù)存扣減怎么選、重試怎么做、事務(wù)邊界怎么控。說(shuō)邊界單機(jī)鎖、數(shù)據(jù)庫(kù)鎖、分布式鎖的適用范圍完全不同沒(méi)有最優(yōu)的鎖只有最匹配的代價(jià)模型。這套結(jié)構(gòu)的好處是面試官無(wú)論往哪個(gè)方向追問(wèn)你都有下一層可以展開(kāi)。它不是一個(gè)標(biāo)準(zhǔn)答案而是一個(gè)能證明你“真的理解并發(fā)”的思考路徑。悲觀(guān)鎖和樂(lè)觀(guān)鎖從來(lái)不是一道背誦題。它真正考察的是你在面對(duì)并發(fā)沖突時(shí)能不能先判斷代價(jià)再?zèng)Q定策略。把這套代價(jià)模型放進(jìn)腦子里下一次再聽(tīng)到“鎖”這個(gè)字你會(huì)多一層理解。