開發(fā)中我們經(jīng)常會(huì)用到 Spring Boot 的事務(wù)注解，為含有多種操作的方法添加事務(wù)，做到如果某一個(gè)環(huán)節(jié)出錯(cuò)，全部回滾的效果。但是在開發(fā)中可能會(huì)因?yàn)椴涣私馐聞?wù)機(jī)制，而導(dǎo)致我們的方法使用了 @Transactional 注解但是沒有生效的情況，下面就把這幾種不能生效的情況整理一下。

一、非public方法（動(dòng)態(tài)代理限制）

Spring 的事務(wù)管理本質(zhì)上是通過 AOP 動(dòng)態(tài)代理 實(shí)現(xiàn)的（JDK 動(dòng)態(tài)代理或 CGLIB 代理）。

代理對象在調(diào)用目標(biāo)方法時(shí)，會(huì)添加事務(wù)管理的邏輯（開啟事務(wù)、提交/回滾事務(wù)）。

然而，動(dòng)態(tài)代理只能代理 public 方法。

如果你將 @Transactional 注解放在 protected、private 或默認(rèn)（包級私有）方法上，Spring 在創(chuàng)建代理時(shí)無法為這些方法添加事務(wù)增強(qiáng)邏輯。

當(dāng)你通過代理對象調(diào)用這些非 public 方法時(shí)，事務(wù)相關(guān)的代碼（如 beginTransaction(), commit(), rollback()）不會(huì)被織入，因此事務(wù)管理完全失效。

所以，要確保所有需要事務(wù)管理的方法都是 public 的。這是 Spring AOP 代理機(jī)制的一個(gè)硬性限制。

二、自調(diào)用問題（類內(nèi)部方法調(diào)用，不走代理）

這是 AOP 代理機(jī)制帶來的另一個(gè)典型問題。假設(shè)一個(gè) Service 類中有兩個(gè)方法：

• methodA()：沒有 @Transactional 注解。
• methodB()：有 @Transactional 注解。

如果你在 methodA() 內(nèi)部直接調(diào)用 this.methodB()，那么你調(diào)用的是 Service 類本身的 methodA()（this 指向目標(biāo)對象本身）。methodA() 內(nèi)部調(diào)用 this.methodB()，是目標(biāo)對象內(nèi)部的方法調(diào)用。

這個(gè)調(diào)用完全不經(jīng)過為該 Service 類生成的代理對象。

因?yàn)檎{(diào)用 methodB() 沒有經(jīng)過代理對象，所以代理對象上附加的事務(wù)攔截邏輯根本不會(huì)被執(zhí)行。methodB() 雖然標(biāo)注了 @Transactional，但在此次調(diào)用中完全失效。

解決方案有以下幾種：推薦重構(gòu)代碼。

方案一：注入自身代理對象

開啟 exposeProxy：在配置類（如 @SpringBootApplication 主類）上添加 @EnableAspectJAutoProxy(exposeProxy = true)。

在需要自調(diào)用事務(wù)方法的地方獲取代理對象：

((YourServiceClass) AopContext.currentProxy()).methodB();

AopContext.currentProxy() 獲取到當(dāng)前方法執(zhí)行上下文中的代理對象（即被 Spring AOP 增強(qiáng)過的對象），通過這個(gè)代理對象調(diào)用 methodB()，就會(huì)走代理邏輯，事務(wù)攔截器生效。

這種方式不常用，會(huì)有缺點(diǎn)，引入了 Spring AOP 特定 API (AopContext)，增加了代碼耦合度。

方案二：重構(gòu)代碼（推薦）

將需要事務(wù)管理的業(yè)務(wù)邏輯 methodB() 抽取到另一個(gè)獨(dú)立的 Bean（如另一個(gè) Service）中。然后在原來的 methodA() 中注入并使用這個(gè)新的 Bean 來調(diào)用 methodB()。這樣調(diào)用自然通過代理對象進(jìn)行。

這是更符合設(shè)計(jì)原則（單一職責(zé)、依賴注入）的做法，避免了自調(diào)用問題，也降低了耦合。

方案三：使用 ApplicationContext 獲取 Bean

在類中注入 ApplicationContext，然后通過 ctx.getBean(YourServiceClass.class).methodB() 來調(diào)用。這樣獲取到的是代理 Bean，調(diào)用會(huì)走代理。

代碼略顯繁瑣，并且也需要依賴 Spring 容器。

三、異常類型不匹配（默認(rèn)只回滾RuntimeException）

@Transactional 注解的 rollbackFor 屬性默認(rèn)值是 RuntimeException 和 Error。

• 當(dāng)方法拋出 RuntimeException 或其子類（如 NullPointerException, IllegalArgumentException）時(shí)，Spring 會(huì)回滾事務(wù)。
• 當(dāng)方法拋出檢查型異常（如 IOException, SQLException）時(shí)，Spring 默認(rèn)會(huì)提交事務(wù)！

如果你在一個(gè)事務(wù)方法中拋出了自定義的業(yè)務(wù)異常（繼承自 Exception 而非 RuntimeException），或者拋出了其他檢查型異常，并且沒有顯式配置 rollbackFor，那么即使業(yè)務(wù)邏輯出錯(cuò)拋出了異常，Spring 也會(huì)正常提交事務(wù)，導(dǎo)致數(shù)據(jù)不一致。

這時(shí)，我們要顯式指定 rollbackFor：在 @Transactional 注解中明確聲明哪些異常需要觸發(fā)回滾。

// 回滾所有 Exception 和自定義異常
@Transactional(rollbackFor = {Exception.class, YourCustomBusinessException.class}) 
public void transactionalMethod() throws Exception { ... }

或者修改默認(rèn)行為（謹(jǐn)慎）：雖然不推薦，但可以通過修改 Spring 的全局事務(wù)管理器配置來改變默認(rèn)的回滾異常類型（例如改為回滾所有 Throwable）。

但這樣做風(fēng)險(xiǎn)較大，可能回滾不應(yīng)該回滾的異常（如 OutOfMemoryError）。

最佳實(shí)踐還是根據(jù)具體業(yè)務(wù)在注解上顯式配置 rollbackFor 和 noRollbackFor。

四、多線程切換（事務(wù)連接綁定ThreadLocal）

Spring 的事務(wù)管理核心是將數(shù)據(jù)庫連接（Connection）綁定到當(dāng)前執(zhí)行線程（Thread）的 ThreadLocal 變量上。

一個(gè)事務(wù)從開始（beginTransaction）到提交/回滾（commit/rollback）期間，所有數(shù)據(jù)庫操作都使用這個(gè)綁定在當(dāng)前線程 ThreadLocal 上的同一個(gè) Connection，以此保證 ACID 特性。

如果你在一個(gè)事務(wù)方法內(nèi)部啟動(dòng)了一個(gè)新線程（new Thread()） 或者使用線程池（如 @Async）執(zhí)行數(shù)據(jù)庫操作，會(huì)出現(xiàn)以下情況：

• 新線程擁有自己獨(dú)立的 ThreadLocal 存儲(chǔ)。
• 新線程無法訪問到原始事務(wù)線程綁定的 Connection 對象。
• 新線程中的數(shù)據(jù)庫操作會(huì)從連接池獲取一個(gè)新的、獨(dú)立的 Connection。
• 這個(gè)新 Connection 不參與原始事務(wù)，其操作會(huì)在自身 autoCommit 模式下立即執(zhí)行（通常是自動(dòng)提交），與原始事務(wù)完全隔離。

新線程中的數(shù)據(jù)庫操作成功與否不影響原始事務(wù)的提交或回滾，反之亦然。破壞了事務(wù)的原子性（Atomicity）。原始事務(wù)回滾不會(huì)回滾新線程中的操作；新線程操作失敗也不會(huì)導(dǎo)致原始事務(wù)回滾。

解決方案：處理多線程下的數(shù)據(jù)一致性非常復(fù)雜，沒有銀彈：

• 避免在事務(wù)方法內(nèi)開啟異步線程執(zhí)行 DB 操作：**這是最根本的預(yù)防措施。將需要在同一事務(wù)中完成的操作放在同一個(gè)線程內(nèi)執(zhí)行。
• 編程式事務(wù)管理： 在新線程內(nèi)部，使用 TransactionTemplate 手動(dòng)管理事務(wù)邊界。但這只是讓新線程內(nèi)部操作具有事務(wù)性，無法與原始線程的事務(wù)合并成一個(gè)原子事務(wù)。
• 分布式事務(wù)：如果業(yè)務(wù)強(qiáng)要求跨線程的 ACID，可能需要引入分布式事務(wù)管理器（如 Seata, Atomikos）來處理這種跨 資源（不同線程可視為不同資源管理者）的場景，但代價(jià)高昂且復(fù)雜。
• 設(shè)計(jì)補(bǔ)償機(jī)制： 在業(yè)務(wù)層設(shè)計(jì)最終一致性方案（如 Saga 模式），通過記錄操作日志、發(fā)送消息、定時(shí)任務(wù)補(bǔ)償?shù)确绞?，在異步操作失敗后嘗試回滾或修正原始事務(wù)已提交的操作。這是更常見的處理異步事務(wù)一致性的實(shí)踐。

五、錯(cuò)誤傳播行為（如：PROPAGATION_NOT_SUPPORTED掛起事務(wù)）

@Transactional 的 propagation 屬性定義了當(dāng)前方法的事務(wù)如何與已存在的事務(wù)進(jìn)行交互。使用不當(dāng)會(huì)導(dǎo)致事務(wù)行為不符合預(yù)期。

PROPAGATION_NOT_SUPPORTED ： 不支持事務(wù)。如果當(dāng)前存在事務(wù)，則掛起（Suspend） 這個(gè)事務(wù)；然后以非事務(wù)方式執(zhí)行當(dāng)前方法。方法執(zhí)行完畢后，之前掛起的事務(wù)恢復(fù)（Resume）。

假設(shè)方法 outer() 開啟了一個(gè)事務(wù)（Propagation.REQUIRED），在其內(nèi)部調(diào)用 inner() 方法，而 inner() 被標(biāo)注為 @Transactional(propagation = Propagation.NOT_SUPPORTED)，當(dāng)執(zhí)行到 inner() 時(shí)：

• 系統(tǒng)檢測到當(dāng)前存在 outer() 開啟的事務(wù)。
• 根據(jù) NOT_SUPPORTED 語義，掛起 outer() 的事務(wù)。
• inner() 方法在無事務(wù)狀態(tài)下執(zhí)行（相當(dāng)于 autoCommit=true）。
• inner() 方法執(zhí)行完畢（無論成功失敗，其操作已立即提交）。
• 恢復(fù) outer() 的事務(wù)，繼續(xù)執(zhí)行 outer() 剩余代碼。

結(jié)果是 inner() 方法中的數(shù)據(jù)庫操作不受 outer() 事務(wù)控制。即使 outer() 最終因異常回滾，inner() 中已提交的操作不會(huì)被回滾！這通常不是開發(fā)者想要的效果，極易造成數(shù)據(jù)不一致。

其他易錯(cuò)傳播行為：

• PROPAGATION_NEVER： 要求不能存在事務(wù)。如果調(diào)用者在一個(gè)事務(wù)中調(diào)用了標(biāo)記為 NEVER 的方法，會(huì)直接拋出 IllegalTransactionStateException 異常。
• PROPAGATION_SUPPORTS： 如果當(dāng)前存在事務(wù)，就加入該事務(wù)；如果沒有，就以非事務(wù)方式執(zhí)行。關(guān)鍵點(diǎn)在于非事務(wù)方式。如果方法中有多個(gè)操作且需要原子性，而外部又恰好沒有事務(wù)，這些操作就會(huì)各自獨(dú)立提交。
• PROPAGATION_REQUIRES_NEW： 總是開啟一個(gè)全新的、獨(dú)立的事務(wù)。會(huì)掛起外部事務(wù)（如果存在）。新事務(wù)的提交/回滾與外部事務(wù)互不影響。注意： 這雖然創(chuàng)建了新事務(wù)，但不同于自調(diào)用失效，它是有效的（通過代理調(diào)用）。它的陷阱在于開發(fā)者可能誤以為新事務(wù)是外部事務(wù)的一部分，其實(shí)它們是獨(dú)立的。

解決方案：

• 深入理解傳播行為： 務(wù)必清楚每種傳播行為（REQUIRED, REQUIRES_NEW, SUPPORTS, MANDATORY, NOT_SUPPORTED, NEVER, NESTED）的精確語義。
• 謹(jǐn)慎選擇傳播行為： 默認(rèn)使用 Propagation.REQUIRED 通常能滿足大多數(shù)場景（加入現(xiàn)有事務(wù)，沒有則新建）。只有在有明確且充分理由時(shí)才使用其他傳播行為。
• 代碼審查與測試： 對使用了非默認(rèn)傳播行為的代碼進(jìn)行重點(diǎn)審查，并通過單元測試、集成測試模擬各種調(diào)用鏈路，驗(yàn)證事務(wù)邊界和回滾行為是否符合預(yù)期。特別注意跨方法、跨服務(wù)調(diào)用時(shí)的事務(wù)傳播。

六、總結(jié)

Spring Boot 事務(wù)失效的核心原因通常圍繞：

• AOP 代理機(jī)制的限制（非 public、自調(diào)用）
• 異常處理機(jī)制（默認(rèn)回滾異常類型）
• 資源綁定機(jī)制（ThreadLocal 導(dǎo)致多線程失效）
• 配置錯(cuò)誤（傳播行為誤用）

解決這些問題需要深入理解 Spring 事務(wù)管理的底層原理（代理、ThreadLocal、異常回滾規(guī)則、傳播語義），并在編碼和配置時(shí)保持謹(jǐn)慎，遵循最佳實(shí)踐（如方法 public、避免自調(diào)用、顯式指定 rollbackFor、理解傳播行為、避免事務(wù)內(nèi)跨線程操作 DB）。

到此這篇關(guān)于SpringBoot事務(wù)注解@Transactional失效場景與解決方案的文章就介紹到這了,更多相關(guān)SpringBoot @Transactional失效解決內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論