高并發(fā)場(chǎng)景下Spring事務(wù)與JPA樂(lè)觀鎖重試機(jī)制導(dǎo)致的死鎖
環(huán)境：SpringBoot3.4.0
1. 簡(jiǎn)介
在高并發(fā)場(chǎng)景中，庫(kù)存扣減是最典型的業(yè)務(wù)挑戰(zhàn)之一。當(dāng)多個(gè)線程同時(shí)爭(zhēng)奪同一商品的庫(kù)存資源時(shí)，稍有不慎就會(huì)引發(fā)超賣(mài)（庫(kù)存扣減為負(fù)值）或死鎖（線程相互阻塞無(wú)法推進(jìn)）等嚴(yán)重問(wèn)題。為解決超賣(mài)，開(kāi)發(fā)者常采用JPA樂(lè)觀鎖（基于版本號(hào)機(jī)制）配合重試策略，然而這一方案在實(shí)際應(yīng)用中暗藏陷阱——若事務(wù)管理與重試邏輯設(shè)計(jì)不當(dāng)，反而會(huì)觸發(fā)更隱蔽的死鎖問(wèn)題。
以一段典型的Spring Data JPA代碼為例：當(dāng)多個(gè)線程同時(shí)扣減庫(kù)存時(shí)，樂(lè)觀鎖沖突會(huì)觸發(fā)ObjectOptimisticLockingFailureException，而開(kāi)發(fā)者試圖通過(guò)遞歸重試恢復(fù)操作。然而，這種設(shè)計(jì)可能因以下原因?qū)е孪到y(tǒng)崩潰：
- 事務(wù)傳播機(jī)制缺陷
重試未開(kāi)啟獨(dú)立事務(wù)，導(dǎo)致行鎖長(zhǎng)期未釋放，線程相互阻塞。 - JPA一級(jí)緩存干擾
未清理的緩存使重試讀取到臟數(shù)據(jù)，與數(shù)據(jù)庫(kù)真實(shí)狀態(tài)不一致。 - 無(wú)限遞歸風(fēng)險(xiǎn)
持續(xù)沖突引發(fā)棧溢出或資源耗盡。
本文將以代碼實(shí)踐為切入點(diǎn)，逐步分析在高并發(fā)場(chǎng)景下樂(lè)觀鎖引發(fā)的各種問(wèn)題。
2. 實(shí)戰(zhàn)案例
2.1 準(zhǔn)備環(huán)境
準(zhǔn)備JPA對(duì)應(yīng)的實(shí)體類
@Entity
@Table(name = "c_product")
@DynamicUpdate
public class Product {
@Id
private Long id;
private String name;
private Integer stock;
@Version
private Integer version;
// getters, setters
}c_product表準(zhǔn)備如下數(shù)據(jù)
INSERT INTO `mall`.`c_product` (`id`, `name`, `stock`, `version`)
VALUES (1, 'Spring Boot3實(shí)戰(zhàn)案例100例', 2, 1);
圖片
準(zhǔn)備Repository接口
public interface ProductRepository extends
JpaRepository<Product, Long> {
}扣減庫(kù)存Service初始方法
@Transactional
public void deductStock(Long productId, int quantity) {
this.productRepository.findById(productId).ifPresentOrElse(p -> {
if (p.getStock() >= quantity) {
p.setStock(p.getStock() - quantity);
productRepository.save(p);
} else {
throw new RuntimeException("庫(kù)存不足");
}
}, () -> {
throw new RuntimeException("商品不存在");
});
}在這初始扣減庫(kù)存中我們還并沒(méi)有加入重試的邏輯。
單元測(cè)試用例
@Test
public void testDeductStock() throws Exception {
final int MAX = 10 ;
CountDownLatch cdl = new CountDownLatch(MAX) ;
CyclicBarrier cb = new CyclicBarrier(MAX) ;
for (int i = 0; i < MAX; i++) {
new Thread(() -> {
try {
cb.await() ;
this.productService.deductStock(1L, 1) ;
} catch(Exception e) {
} finally {
cdl.countDown() ;
}
}, "T" + i).start() ;
}
cdl.await() ;
System.err.println("執(zhí)行完成...") ;
}測(cè)試用例中模擬了10個(gè)線程進(jìn)行并發(fā)庫(kù)存扣減操作。
2.2 初始代碼測(cè)試
首先，我們測(cè)試初始代碼結(jié)果如下：
圖片
執(zhí)行更新動(dòng)作時(shí)自動(dòng)加入了version版本字段；數(shù)據(jù)庫(kù)中的數(shù)據(jù)如下：
圖片
也就是只有一個(gè)線程扣減庫(kù)存成功，其它10個(gè)線程都發(fā)生了樂(lè)觀鎖異常。可是控制臺(tái)并沒(méi)有輸出異常啊，這是因?yàn)槲覀冊(cè)趩卧獪y(cè)試中將異常吞了，修改測(cè)試用例代碼在catch中輸出異常，如下：
圖片
控制臺(tái)輸出。
圖片
9個(gè)線程都發(fā)生了并發(fā)修改樂(lè)觀鎖異常。
思考：我們?cè)跍y(cè)試用例中進(jìn)行了異常捕獲，那么我們能否在ProductService#deductStock方法中進(jìn)行捕獲呢？以當(dāng)前的代碼來(lái)看是不行的，也就是你想通過(guò)如下方式捕獲是不行的：
圖片
或者是你將deductStock方法都進(jìn)行try...catch也是不能捕獲的。因?yàn)闃?lè)觀鎖是在事務(wù)提交的時(shí)候進(jìn)行檢查的。
接下來(lái)，我們要加入樂(lè)觀鎖異常后重試機(jī)制。
2.3 樂(lè)觀鎖重試版本1
我們將代碼修改如下：
圖片
首先，我將原來(lái)的save方法修改為saveAndFlush；其次，catch捕獲了樂(lè)觀鎖異常并在其中自調(diào)用進(jìn)行重試。
將方法修改為saveAndFlush會(huì)立即將update語(yǔ)句發(fā)送給db進(jìn)行執(zhí)行，這樣就能捕獲到樂(lè)觀鎖異常了。
如上代碼是否能改進(jìn)行正確的庫(kù)存扣減呢？執(zhí)行測(cè)試用例輸出如下：
圖片
庫(kù)存不足，那么是不是數(shù)據(jù)庫(kù)中已經(jīng)都扣減完了？
圖片
查看數(shù)據(jù)庫(kù)，庫(kù)存還有，但控制臺(tái)確輸出的庫(kù)存不足，這又是為什么呢？我們?cè)诖a中加入如下輸出：
圖片
再次運(yùn)行，輸出結(jié)果。
圖片
這里我們以T5線程來(lái)說(shuō):
- T5線程首次查詢stock=2，versinotallow=1；
- 當(dāng)update時(shí)由于其它線程已經(jīng)修改了數(shù)據(jù)，版本發(fā)生了變化，所以T5線程拋出了樂(lè)觀鎖異常；
- 接著，再次調(diào)用deductStock方法，但是并沒(méi)有執(zhí)行select語(yǔ)句，這是由于JPA一級(jí)緩存導(dǎo)致（同一個(gè)線程EntityManager使用的同一個(gè)），但是輸出的stock=1，versinotallow=1，這是因?yàn)閡pdate雖然沒(méi)有成功，但是我們的代碼中在上一步中確對(duì)stock進(jìn)行了減1操作。
- 繼續(xù)執(zhí)行update語(yǔ)句，由于已經(jīng)有線程執(zhí)行成功將version變成了2，所以這次還是拋出了樂(lè)觀鎖異常（此時(shí)，緩存中的stock進(jìn)行了2次減1操作，已經(jīng)變成了0）。
- 最后，第三次調(diào)用的時(shí)候一級(jí)緩存中的stock已經(jīng)變?yōu)?了，所以最終拋出了庫(kù)存不足；這時(shí)候的庫(kù)存不足是內(nèi)存中沒(méi)有了，可數(shù)據(jù)庫(kù)真實(shí)的數(shù)據(jù)還是有的。
以上是當(dāng)前版本1中出現(xiàn)的問(wèn)題。接下來(lái)，我們將繼續(xù)修改代碼。
2.4 樂(lè)觀鎖重試版本2
通過(guò)上面的說(shuō)明，我們知道了在同一個(gè)線程中查詢相同的數(shù)據(jù)第二次將會(huì)從緩存中直接返回，那是不是我們將緩存清理了就可以再次從數(shù)據(jù)庫(kù)中查詢最新的數(shù)據(jù)呢？修改代碼如下：
首先，我們注入了EntityManager對(duì)象；接著，在catch中進(jìn)行了clear清理一級(jí)緩存。
測(cè)試結(jié)果如下：
圖片
所有的線程無(wú)限循環(huán)（死循環(huán)了），并且通過(guò)輸出日志也確實(shí)每次都執(zhí)行了SQL語(yǔ)句，那為什么輸出的stock=1，versinotallow=1呢？先來(lái)查看數(shù)據(jù)真實(shí)數(shù)據(jù)：
程序中查詢的與數(shù)據(jù)庫(kù)為什么不符？
原因很簡(jiǎn)單，因?yàn)槲覀儺?dāng)前事務(wù)的隔離級(jí)別是可重復(fù)讀（REPEATABLE_READ），那么每次查詢的數(shù)據(jù)都將是快照讀（事務(wù)第一次查詢到的數(shù)據(jù)）。
接下來(lái)，我們將繼續(xù)修改代碼進(jìn)行第三個(gè)版本的嘗試。
2.5 樂(lè)觀鎖重試版本3
既然知道了原因，那么我們是不是修改事務(wù)的隔離級(jí)別就可以了呢？代碼修改如下：
圖片
在事務(wù)注解上將事務(wù)的隔離級(jí)別設(shè)置為讀已提交（默認(rèn)是你當(dāng)前數(shù)據(jù)庫(kù)中默認(rèn)的隔離級(jí)別）。如上修改后再次運(yùn)行測(cè)試用例：
圖片
這次程序正常結(jié)束并且每次都從數(shù)據(jù)庫(kù)中查詢了最新的數(shù)據(jù)，但是又多了一個(gè)異常，意思是："事務(wù)已被標(biāo)記為僅回滾，因此已靜默回滾"。為什么？
這里我們以T3線程為例進(jìn)行分析：
- 首次執(zhí)行由于已經(jīng)被其它線程更新，所以拋出樂(lè)觀鎖異常。
- 進(jìn)入重試，重新查詢數(shù)據(jù)得到最新的stock=1，versinotallow=2，庫(kù)存大于0，進(jìn)行扣減并執(zhí)行update操作。
- T3線程進(jìn)行方法結(jié)束開(kāi)始提交事務(wù)，這個(gè)異常就是在提交事務(wù)時(shí)拋出的。當(dāng)?shù)谝淮伟l(fā)生樂(lè)觀鎖異常的時(shí)候JPA內(nèi)部就已經(jīng)將當(dāng)前的事務(wù)狀態(tài)設(shè)置為回滾，所以最終提交的時(shí)候當(dāng)然執(zhí)行回滾操作。
這時(shí)候又該如何解決呢？接下來(lái)，我們繼續(xù)修改代碼。
2.6 樂(lè)觀鎖重試版本4
既然知道了原因，那么我們是不是在每次重試的時(shí)候只要開(kāi)啟一個(gè)新的事務(wù)就可以了呢？修改代碼如下：
圖片
在上面的代碼中，我們修改了下面3點(diǎn)：
- 將事務(wù)的傳播屬性設(shè)置REQUIRES_NEW，每次都開(kāi)始一個(gè)新的；并且刪除了事務(wù)的隔離級(jí)別，每次都是新的也就沒(méi)有必要了。
- 刪除了clear清理緩存的操作。
- 自己注入自己調(diào)用deductStock方法，這是為了防止事務(wù)失效。
測(cè)試結(jié)果如下：
圖片
死鎖了，等待默認(rèn)的超時(shí)時(shí)間后結(jié)束，為什么？
這是因?yàn)楫?dāng)我們?nèi)魏我粋€(gè)線程發(fā)生樂(lè)觀鎖異常進(jìn)入重試階段時(shí)，雖然重試時(shí)開(kāi)啟的是一個(gè)新的事務(wù)，但是之前的事務(wù)update操作還沒(méi)有結(jié)束（已經(jīng)將id為1的記錄鎖定了，行鎖），當(dāng)你再次開(kāi)啟一個(gè)新事務(wù)執(zhí)行update操作時(shí)那必須等待前一個(gè)事務(wù)結(jié)束，前一個(gè)事務(wù)肯定結(jié)束不了，因?yàn)槲覀兪莾?nèi)部自己調(diào)用自己（遞歸調(diào)用），所以這里就產(chǎn)生了死鎖現(xiàn)象。
這該如何解決呢？接下來(lái)，我們將介紹幾種解決辦法。
2.7 樂(lè)觀鎖重試版本5
我們將代碼修改如下：
public void deductStock(Long productId, int quantity) {
this.productRepository.findById(productId).ifPresentOrElse(p -> {
if (p.getStock() >= quantity) {
p.setStock(p.getStock() - quantity);
try {
this.productRepository.saveAndFlush(p) ;
} catch (ObjectOptimisticLockingFailureException e) {
System.err.println(Thread.currentThread().getName() + " - 樂(lè)觀鎖異常, " + e.getMessage()) ;
deductStock(productId, quantity) ;
}
} else {
throw new RuntimeException("庫(kù)存不足");
}
}, () -> {
throw new RuntimeException("商品不存在");
}) ;
}注意觀察上面的代碼，我們做了如下的修改：
- 方法上的事務(wù)注解刪除了。
- 樂(lè)觀鎖異常處理中，我們直接調(diào)用了當(dāng)前的方法。（因?yàn)楫?dāng)前的方法一級(jí)不是事務(wù)方法，不需要自己注入自己進(jìn)行調(diào)用）
執(zhí)行結(jié)果如下：
圖片
數(shù)據(jù)庫(kù)庫(kù)存及版本變化：
圖片
數(shù)據(jù)也正確了。
上面的代碼中不管你用save還是saveAndFlush都是可以的。因?yàn)槊恳淮蔚闹卦囌{(diào)用都是開(kāi)啟的一個(gè)新事務(wù)。
