失效深度解析：@Transactional代理原理與實(shí)戰(zhàn)排查)
1. 別再只看表面Transactional 失效背后的真實(shí)原因做了幾年 Java 開發(fā)用 Transactional 注解管理事務(wù)可能是最稀松平常的事。但我見過太多項(xiàng)目里因事務(wù)失效引發(fā)線上數(shù)據(jù)不一致的“事故現(xiàn)場(chǎng)”——庫存扣了、訂單沒生成賬戶扣款成功、余額表沒變化。排查到最后問題往往不在數(shù)據(jù)庫也不在 SQL而是 Transactional 壓根沒生效。我剛帶團(tuán)隊(duì)時(shí)也踩過類似的坑。某個(gè)定時(shí)任務(wù)批量處理對(duì)賬文件方法上加了 Transactional 注解測(cè)試環(huán)境數(shù)據(jù)量小一點(diǎn)問題沒有。上線后某個(gè)批次處理到一半拋了運(yùn)行時(shí)異常結(jié)果發(fā)現(xiàn)前一半已經(jīng)入庫的數(shù)據(jù)沒有回滾徹底把庫存數(shù)據(jù)搞花了。排查后才發(fā)現(xiàn)是同類內(nèi)部方法調(diào)用代理根本沒有攔截。這個(gè)注解到底怎么工作的失效場(chǎng)景有哪些傳播機(jī)制、隔離級(jí)別、連接管理又該怎么選這篇文章不打算停留在“注解真方便”的層面直接把 Spring 事務(wù)從代理原理到實(shí)戰(zhàn)配置拆一遍把那些常規(guī)文檔不會(huì)寫的細(xì)節(jié)講透。先特別強(qiáng)調(diào)一句Spring 的聲明式事務(wù)基于 AOP 動(dòng)態(tài)代理實(shí)現(xiàn)所有“失效”問題幾乎都能從代理機(jī)制上找到根源。Transactional 是 Spring 框架提供的一套聲明式事務(wù)解決方案核心價(jià)值在于將事務(wù)開啟、提交、回滾這些繁瑣操作交給容器去管理開發(fā)者只需在方法或類上標(biāo)注一個(gè)注解。但它的“自動(dòng)”是有前提的背后隱藏著代理對(duì)象、事務(wù)同步管理器、連接綁定等一堆細(xì)節(jié)。搞懂這些細(xì)節(jié)才算真正會(huì)用這個(gè)注解而不是被它坑。2. 手寫一個(gè)代理示例弄清方法調(diào)用為什么“穿透”代理2.1 Spring 事務(wù)的本質(zhì)AOP 動(dòng)態(tài)代理外加一個(gè)事務(wù)攔截器要理解 Transactional 失效原因先得從底層機(jī)制說起。我們平時(shí)寫的業(yè)務(wù) Bean經(jīng)過 Spring 容器初始化后并不是直接返回那個(gè)原始對(duì)象而是返回一個(gè)經(jīng)過 AOP 增強(qiáng)的代理對(duì)象。Spring 默認(rèn)使用 JDK 動(dòng)態(tài)代理也可以配置使用 CGLIB具體要看目標(biāo)類是否實(shí)現(xiàn)了接口。代理對(duì)象跟原始對(duì)象有相同的接口或繼承關(guān)系但內(nèi)部包裹了事務(wù)攔截器邏輯。每次調(diào)用被 Transactional 標(biāo)注的方法時(shí)實(shí)際調(diào)用鏈條是“調(diào)用方 - 代理對(duì)象 - 事務(wù)攔截器 - 原始對(duì)象方法”。事務(wù)攔截器會(huì)做這些事從配置中解析事務(wù)屬性傳播行為、隔離級(jí)別、超時(shí)時(shí)間、只讀標(biāo)志從 Spring 容器中獲取 PlatformTransactionManager 事務(wù)管理器通過事務(wù)管理器開啟事務(wù)、獲取數(shù)據(jù)庫連接把連接綁定到當(dāng)前線程的 ThreadLocal 中執(zhí)行原始對(duì)象的目標(biāo)方法根據(jù)方法執(zhí)行是否拋異常決定提交或回滾清理事務(wù)上下文把連接歸還連接池這個(gè)“代理”的存在意味著目標(biāo)方法被執(zhí)行前和后Spring 都插入了額外邏輯。核心問題在于代理攔截的前提是調(diào)用要經(jīng)過代理對(duì)象。如果調(diào)用沒有經(jīng)過代理而是直接調(diào)用了原始對(duì)象的方法事務(wù)攔截器根本沒有機(jī)會(huì)介入注解自然失效。2.2 自己動(dòng)手模擬代理鏈路的執(zhí)行順序?yàn)榱苏f清這個(gè)問題我用簡化代碼模擬一下代理攔截的過程。雖然 Spring 的 TransactionInterceptor 肯定復(fù)雜得多但整體鏈路就是這么回事。public class TransactionInterceptor { // 模擬代理攔截邏輯 public Object invoke(MethodInvocation invocation) throws Throwable { // 1. 事務(wù)開啟前獲取事務(wù)管理器開啟事務(wù)綁定連接 TransactionStatus status transactionManager.getTransaction(transactionAttribute); try { // 2. 執(zhí)行目標(biāo)方法 Object result invocation.proceed(); // 3. 方法正常返回提交事務(wù) transactionManager.commit(status); return result; } catch (Exception e) { // 4. 方法拋異常按規(guī)則回滾事務(wù) transactionManager.rollback(status); throw e; } finally { // 5. 清理事務(wù)同步狀態(tài) TransactionSynchronizationManager.clear(); } } }從這段鏈路就能看出幾個(gè)關(guān)鍵點(diǎn)。目標(biāo)方法正常結(jié)束才能提交拋了異常才回滾方法執(zhí)行期間事務(wù)相關(guān)信息通過 ThreadLocal 與當(dāng)前線程綁定。所以事務(wù)要不要回滾完全取決于你能不能“感知”到異常。感知不到異常Spring 就只能傻乎乎地提交。再進(jìn)一步說如果調(diào)用方拿到的是原始對(duì)象而不是代理對(duì)象那這段攔截邏輯根本不會(huì)執(zhí)行事務(wù)相當(dāng)于不存在。這種情況最常見的觸發(fā)點(diǎn)就是同類內(nèi)部方法調(diào)用。Component public class OrderService { public void createOrder() { // 這里直接調(diào)用內(nèi)部方法this 是原始對(duì)象不是代理對(duì)象 this.insertOrder(); this.insertOrderItem(); } Transactional public void insertOrder() { // 事務(wù)方法 } Transactional public void insertOrderItem() { // 事務(wù)方法 } }createOrder 方法內(nèi)部this.insertOrder() 和 this.insertOrderItem() 調(diào)用的是 OrderService 原始對(duì)象的方法代理對(duì)象根本沒有介入事務(wù)自然無效。如果 insertOrder 執(zhí)行成功、insertOrderItem 執(zhí)行失敗前者不會(huì)回滾最終造成數(shù)據(jù)不一致。這個(gè)例子描述的問題實(shí)在太常見網(wǎng)上面試題也是高頻考點(diǎn)。但真正落實(shí)到項(xiàng)目里很多人寫的代碼就是這個(gè)形態(tài)然后深夜查數(shù)據(jù)為啥不對(duì)。2.3 為什么 InvocationTargetException 會(huì)干擾你的問題判斷排查事務(wù)問題時(shí)很多人被 InvocationTargetException 繞暈。這個(gè)異常是反射調(diào)用目標(biāo)方法時(shí)的包裝異常目標(biāo)方法本身拋出的異常被包在它的 target 屬性里。代理對(duì)象調(diào)用目標(biāo)方法也是通過反射完成的所以事務(wù)方法內(nèi)部拋出的異常經(jīng)過反射層會(huì)被包裝。Spring 處理回滾時(shí)會(huì)層層解包來解析具體異常類型判斷是否匹配回滾規(guī)則。如果你自己用反射調(diào)用了事務(wù)方法你的 catch 邏輯沒解包直接對(duì)比 InvocationTargetException 的類型肯定對(duì)不上預(yù)期異常事務(wù)回滾判斷也可能出錯(cuò)。實(shí)際排查事務(wù)問題時(shí)第一步應(yīng)該去看目標(biāo)方法是否被代理而不是盯著異常棧一層層猜。最簡單的方式是打印調(diào)用對(duì)象類型。// 容器中注入的類型是代理類 System.out.println(orderService.getClass().getName()); // 輸出中會(huì)出現(xiàn) CGLIB 或 JDK 代理相關(guān)字樣 // 類似 OrderService$$EnhancerBySpringCGLIB如果在容器里這個(gè)類的名字帶了 EnhancerByCGLIB說明走代理鏈路沒問題如果就是普通類名那一定在配置層面出了岔子比如沒有開啟注解驅(qū)動(dòng)事務(wù)。3. 失效場(chǎng)景全排查同類的坑、異常吞掉、非 public 方法3.1 同類自調(diào)用、私有方法、非事務(wù)方法互相調(diào)用事務(wù)方法被同類內(nèi)部其他方法調(diào)用時(shí)事務(wù)失效這是壓倒性的第一大坑。我整理一下這類問題的幾種具體形式以及各自的解決思路。場(chǎng)景一同類內(nèi)部 this 調(diào)用。如上面代碼所示this.method() 調(diào)用繞過代理。解決辦法有幾個(gè)將事務(wù)方法拆分到獨(dú)立的 Service Bean通過注入代理對(duì)象調(diào)用注入自身代理Component public class OrderService { Autowired private OrderService self; public void createOrder() { // 調(diào)用代理自身的 insertOrder事務(wù)能生效 self.insertOrder(); } Transactional public void insertOrder() { ... } }使用 AopContext.currentProxy() 獲取當(dāng)前代理對(duì)象public void createOrder() { OrderService proxy (OrderService) AopContext.currentProxy(); proxy.insertOrder(); }使用 AopContext.currentProxy() 需要在配置里設(shè)置 exposeProxy true否則運(yùn)行時(shí)會(huì)直接拋 IllegalStateException。場(chǎng)景二方法不是 public。Spring 的注解驅(qū)動(dòng)事務(wù)默認(rèn)只對(duì) public 方法生效private、protected、默認(rèn)包可見方法上的 Transactional 都會(huì)失效。原因很簡單Spring 的代理邏輯只對(duì) public 方法進(jìn)行攔截其他可見性方法要么被子類覆蓋邏輯干擾要么根本不被代理鏈調(diào)用。項(xiàng)目里把這個(gè)坑踩穿的人不少特別是內(nèi)部私有方法想“順便”加個(gè)事務(wù)結(jié)果事務(wù)全程沒參與。場(chǎng)景三在非事務(wù)方法里直接調(diào)用另一個(gè)類的事務(wù)方法但那個(gè)非事務(wù)方法也屬于同一個(gè) Bean而且標(biāo)注事務(wù)的方法自己又調(diào)了內(nèi)部方法。這個(gè)組合拳容易和“傳播行為”疊加產(chǎn)生復(fù)雜效果需要先從結(jié)構(gòu)上理清楚調(diào)用鏈。一般建議事務(wù)邊界放在入口方法上而不是撒在多個(gè)內(nèi)部方法上。你可以在一個(gè)方法上統(tǒng)一管理事務(wù)內(nèi)部方法就不要再標(biāo)注事務(wù)以免傳播行為互相干擾。3.2 異常被 catch 吞掉事務(wù)提交了你以為回滾了這是事務(wù)失效的第二大場(chǎng)景。代碼長這樣Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); // 這里拋了業(yè)務(wù)異常 throw new RuntimeException(余額不足); } catch (Exception e) { // 異常被吞掉方法正常返回 log.info(轉(zhuǎn)賬失敗: {}, e.getMessage()); } }方法體內(nèi)部把異常 catch 了沒有重新拋出方法正常返回。Spring 事務(wù)攔截器看到方法正常返回認(rèn)為一切成功就把事務(wù)提交了。結(jié)果是余額已經(jīng)扣減但調(diào)用方根本不知道出了問題。這在真實(shí)項(xiàng)目中非常隱蔽因?yàn)槿罩纠锟雌饋碛袌?bào)錯(cuò)你以為事務(wù)回滾了實(shí)際數(shù)據(jù)庫已經(jīng)改動(dòng)。排查手段也很反直覺要看日志打印順序如果事務(wù)提交日志沒打印那可能是異常沒有被攔截器感知。正確做法有兩種。要么在 catch 塊中手工標(biāo)記回滾Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); throw new RuntimeException(余額不足); } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); log.info(轉(zhuǎn)賬失敗: {}, e.getMessage()); // 這里可以繼續(xù)做其他操作事務(wù)最終還是會(huì)回滾 } }要么就不要 catch讓異常傳到事務(wù)攔截器層面由 Spring 統(tǒng)一處理回滾。大多數(shù)情況下第二種更簡潔。如果需要 catch 做一些日志記錄可以 catch 之后再原樣拋出或者使用自定義異常封裝后拋出。吞異常是最不可取的。3.3 非異常導(dǎo)致回滾失效的其他隱蔽案例還有一個(gè)常見問題是 SQL 執(zhí)行成功但沒匹配到任何行。比如更新語句 set 的條件生效了但對(duì)列表為空導(dǎo)致影響行數(shù)為 0方法本身沒有任何異常。此時(shí)事務(wù)雖然參與但沒產(chǎn)生實(shí)際變化這不算事務(wù)失效只算業(yè)務(wù)邏輯問題。要判斷事務(wù)是否真的提交了應(yīng)該看數(shù)據(jù)庫鎖和日志而不是代碼。另一種隱蔽問題是多線程。Spring 事務(wù)是通過 ThreadLocal 把數(shù)據(jù)庫連接綁定到當(dāng)前線程的。如果你在事務(wù)方法內(nèi)啟動(dòng)了新線程去執(zhí)行數(shù)據(jù)庫操作那個(gè)新線程拿不到事務(wù)上下文綁定的連接也就無法參與當(dāng)前事務(wù)。如果子線程里操作的是另一個(gè)數(shù)據(jù)源更是各走各的。這種場(chǎng)景在異步任務(wù)、消息處理中很常見正確的做法是把事務(wù)邊界移到子線程要執(zhí)行的方法上或者使用編程式事務(wù)確保子線程有自己的事務(wù)上下文。還有一點(diǎn)值得記錄動(dòng)態(tài)代理生效范圍和方法可見性綁定。如果方法標(biāo)注了 Transactional 但不是 publicSpring 不會(huì)直接報(bào)錯(cuò)而是靜默忽略這很討厭。建議團(tuán)隊(duì) Code Review 時(shí)多加注意或者引入架構(gòu)守護(hù)工具掃描非 public 方法上的 Transactional。4. 傳播行為不是隨便選的REQUIRED 與 REQUIRES_NEW 實(shí)戰(zhàn)差異4.1 七種傳播行為的概念與關(guān)鍵選擇場(chǎng)景Spring 定義了七種事務(wù)傳播行為默認(rèn)是 REQUIRED。我用一張表把最常用的幾種整理出來重點(diǎn)關(guān)注它們的事務(wù)關(guān)系和行為效果。傳播行為當(dāng)前存在事務(wù)時(shí)當(dāng)前無事務(wù)時(shí)典型場(chǎng)景REQUIRED加入當(dāng)前事務(wù)新建事務(wù)同一事務(wù)內(nèi)多個(gè)操作默認(rèn)選它REQUIRES_NEW掛起當(dāng)前事務(wù)新建事務(wù)新建事務(wù)日志記錄、審計(jì)、消息發(fā)送必須獨(dú)立提交NESTED嵌套事務(wù)保存點(diǎn)回滾新建事務(wù)某一段邏輯失敗不影響主事務(wù)整體回滾SUPPORTS加入當(dāng)前事務(wù)非事務(wù)方式執(zhí)行查詢操作有事務(wù)就參與沒有也行NOT_SUPPORTED掛起當(dāng)前事務(wù)非事務(wù)執(zhí)行非事務(wù)方式執(zhí)行某些特殊操作不希望占用事務(wù)連接MANDATORY加入當(dāng)前事務(wù)拋異常強(qiáng)制要求必須在一個(gè)事務(wù)中執(zhí)行NEVER拋異常非事務(wù)方式執(zhí)行嚴(yán)格禁止事務(wù)實(shí)際團(tuán)隊(duì)里用得最多的就是前三個(gè)。如果不理解 REQUIRES_NEW 和 REQUIRED 的區(qū)別可能會(huì)出現(xiàn)這樣的場(chǎng)景用戶下訂單時(shí)往訂單流水表插一條記錄結(jié)果訂單主流程回滾了流水也跟著回滾審計(jì)日志全沒了。4.2 REQUIRES_NEW 是“停掉一個(gè)事務(wù)開另一個(gè)事務(wù)”不是嵌套R(shí)EQUIRES_NEW 的行為是外層事務(wù)被掛起內(nèi)層方法開啟一個(gè)全新事務(wù)內(nèi)外兩個(gè)事務(wù)彼此隔離。內(nèi)層事務(wù)提交后即使外層事務(wù)最終回滾內(nèi)層事務(wù)已經(jīng)提交的數(shù)據(jù)不會(huì)被回滾。這個(gè)特征特別適合某些“無論如何都要記錄”的場(chǎng)景比如消息發(fā)送、審計(jì)日志、操作記錄。但注意一點(diǎn)REQUIRES_NEW 是需要額外數(shù)據(jù)庫連接資源的。事務(wù)掛起期間外層連接被持有但處于閑置狀態(tài)內(nèi)層再獲取一個(gè)新連接高并發(fā)下連接池容易出現(xiàn)空閑等待。連接池如果很小這種方法容易成為瓶頸。如果確實(shí)想實(shí)現(xiàn)“部分成功、部分失敗不影響主流程”可以選擇 NESTED 結(jié)合保存點(diǎn)機(jī)制。NESTED 不會(huì)掛起外層事務(wù)而是使用數(shù)據(jù)庫 savepoint 特性在內(nèi)層方法出錯(cuò)時(shí)回滾到保存點(diǎn)。主事務(wù)依然持有連接連接資源消耗比 REQUIRES_NEW 小但 MySQL 等數(shù)據(jù)庫支持嵌套事務(wù)的能力要看具體驅(qū)動(dòng)配置。我在項(xiàng)目中通常優(yōu)先使用 REQUIRES_NEW 處理日志類獨(dú)立提交需求用 NESTED 處理復(fù)雜的批量業(yè)務(wù)分段回滾需求。4.3 自調(diào)用與傳播行為的組合陷阱一個(gè)案例拆到底下面這個(gè)案例我去年在某項(xiàng)目排查了整晚正好把“自調(diào)用 傳播行為”組合起來說明。Service public class OrderService { Autowired private OrderMapper orderMapper; public void createOrderWithLog() { // 同類調(diào)用事務(wù)不會(huì)在這里統(tǒng)一 this.saveOrder(); this.saveOrderLog(); } Transactional(propagation Propagation.REQUIRED) public void saveOrder() { orderMapper.insertOrder(...); } Transactional(propagation Propagation.REQUIRES_NEW) public void saveOrderLog() { orderMapper.insertOrderLog(...); } }執(zhí)行 createOrderWithLog 時(shí)this.saveOrder() 和 this.saveOrderLog() 都是直接調(diào)用內(nèi)部對(duì)象方法兩個(gè)方法上的 Transactional 全部失效saveOrderLog 的 REQUIRES_NEW 根本不會(huì)新建獨(dú)立事務(wù)。表面上看著是兩個(gè)獨(dú)立事務(wù)實(shí)際是零事務(wù)因?yàn)樗鼈兌紱]走代理。排查這類問題最典型的線索就是執(zhí)行失敗時(shí)數(shù)據(jù)庫數(shù)據(jù)已經(jīng)寫入了。因?yàn)楫惓１煌悆?nèi)部調(diào)用“截?cái)唷贝韺記]有任何攔截。正確的結(jié)構(gòu)應(yīng)當(dāng)是Service public class OrderService { Autowired private OrderService self; Autowired private OrderLogService orderLogService; public void createOrderWithLog() { // 通過代理調(diào)用自身主方法事務(wù)生效 self.saveOrder(); // 通過獨(dú)立 Bean 調(diào)用REQUIRES_NEW 生效 orderLogService.saveOrderLog(); } }把 saveOrderLog 拆到 OrderLogService 中并且用 OrderLogService 的代理對(duì)象去調(diào)用REQUIRES_NEW 才會(huì)真正意義上開啟新事務(wù)。自調(diào)用加傳播行為的組合是最容易讓經(jīng)驗(yàn)豐富的開發(fā)者都掉坑的地方。5. 隔離級(jí)別、只讀事務(wù)與連接綁定一次說清配置誤區(qū)5.1 隔離級(jí)別不是越高越好關(guān)鍵是匹配業(yè)務(wù)場(chǎng)景Spring 事務(wù)注解通過 isolation 屬性指定隔離級(jí)別默認(rèn)使用數(shù)據(jù)庫默認(rèn)隔離級(jí)別MySQL 為 REPEATABLE_READ。很多新手一上來直接設(shè)置 SERIALIZABLE覺得“最高級(jí)最安全”但代價(jià)是性能和并發(fā)能力斷崖式下降。各隔離級(jí)別解決的核心問題不同應(yīng)對(duì)的選擇應(yīng)該是從業(yè)務(wù)需求出發(fā)READ_UNCOMMITTED能讀到未提交數(shù)據(jù)臟讀風(fēng)險(xiǎn)大幾乎不會(huì)用在生產(chǎn)環(huán)境READ_COMMITTED解決臟讀但不可重復(fù)讀問題仍然存在適用對(duì)一致性要求不極致的查詢類場(chǎng)景REPEATABLE_READ解決臟讀和不可重復(fù)讀MySQL 默認(rèn)配合 MVCC 提供快照讀SERIALIZABLE完全串行化寫并發(fā)能力極差只用于極少數(shù)對(duì)數(shù)據(jù)一致性要求極端、寫并發(fā)低的場(chǎng)景實(shí)際開發(fā)中如果兩個(gè)并發(fā)事務(wù)要同時(shí)操作同一行庫存數(shù)據(jù)用 READ_COMMITTED 加數(shù)據(jù)庫悲觀鎖select ... for update通常比 REPEATABLE_READ 更可控。REPEATABLE_READ 在 MySQL 里通過快照讀實(shí)現(xiàn)兩個(gè)事務(wù)各自讀到自己的快照反而可能讓并發(fā)更新改為最后提交覆蓋結(jié)果帶來臟寫風(fēng)險(xiǎn)。我見過有人把隔離級(jí)別升到 SERIALIZABLE 來解決并發(fā)扣庫存問題結(jié)果壓測(cè)直接打滿數(shù)據(jù)庫連接業(yè)務(wù)超時(shí)一大片這不是事務(wù)注解的鍋是對(duì)隔離級(jí)別理解有偏差。5.2 readOnly true 到底做了什么別被名字誤導(dǎo)readOnly 屬性設(shè)置成 true 時(shí)Spring 會(huì)做兩件事向數(shù)據(jù)庫提示這是只讀事務(wù)有些數(shù)據(jù)庫會(huì)以此做優(yōu)化但 MySQL 的 InnoDB 引擎并不會(huì)因此跳過加鎖有些場(chǎng)景下Spring 會(huì)關(guān)閉某些持久層框架的臟檢查、flush 機(jī)制提升一點(diǎn)性能但要注意readOnly true 并不能阻止你在事務(wù)方法里執(zhí)行 insert、update、delete。它只是建議性提示不是硬性校驗(yàn)。Spring 默認(rèn)并不會(huì)攔截寫操作。如果你的項(xiàng)目里想通過 readOnly 做強(qiáng)制校驗(yàn)?zāi)鞘峭耆e(cuò)誤的用法。我平時(shí)會(huì)把 readOnly 用在以下兩類方法上查詢單條或多條數(shù)據(jù)的 Service 方法大批量只讀統(tǒng)計(jì)方法配合超時(shí)時(shí)間控制寫操作的方法一律不設(shè) readOnly避免和事務(wù)攔截器的行為產(chǎn)生模糊地帶。如果你的方法只讀但內(nèi)部還調(diào)了查詢后寫入 Redis 這類操作也最好別標(biāo) readOnly因?yàn)?Redis 操作不走數(shù)據(jù)庫事務(wù)但 Spring 的只讀提示沒有太大意義。穩(wěn)妥起見只對(duì)純數(shù)據(jù)庫查詢才設(shè)置。5.3 事務(wù)超時(shí)時(shí)間和連接綁定ThreadLocal 的另一個(gè)細(xì)節(jié)事務(wù)超時(shí)時(shí)間timeout單位是秒默認(rèn) -1 表示不超時(shí)。如果設(shè)置超時(shí)一旦事務(wù)執(zhí)行超過閾值Spring 會(huì)嘗試回滾事務(wù)但具體行為取決于數(shù)據(jù)庫驅(qū)動(dòng)和底層連接狀態(tài)并不保證一定會(huì)回滾。這里很容易出現(xiàn)“超時(shí)了但鎖沒釋放”的棘手問題。數(shù)據(jù)庫事務(wù)是通過連接綁定的連接又是從連接池借來的。Spring 把連接保存到 TransactionSynchronizationManager 的 ThreadLocal 中。每個(gè)線程里的操作都使用同一個(gè)線程綁定的連接確保整個(gè)事務(wù)操作的是同一個(gè)連接而不是從連接池里每次拿新連接。這就是事務(wù)一致性的基礎(chǔ)。如果方法內(nèi)部直接使用 new Thread() 或線程池去執(zhí)行數(shù)據(jù)庫操作子線程里的數(shù)據(jù)庫訪問不在同一個(gè) ThreadLocal 上下文里自然不會(huì)繼承父線程的事務(wù)連接。這種場(chǎng)景下的操作要么各自獨(dú)立提交要么直接拋錯(cuò)。有些團(tuán)隊(duì)因?yàn)橐粋€(gè)異步任務(wù)在事務(wù)里更新了兩張表子線程更新另一張表最后數(shù)據(jù)亂套就是這個(gè)原因。6. 什么時(shí)候必須放棄聲明式事務(wù)改用編程式事務(wù)6.1 聲明式事務(wù)的靈活性邊界Transactional 是“開箱即用”的代表但有個(gè)天然缺點(diǎn)方法粒度控制。事務(wù)邊界是從方法進(jìn)入開始方法結(jié)束提交或回滾。遇到下面這些場(chǎng)景聲明式事務(wù)反而不好用同一個(gè)方法里想在不同階段設(shè)置不同的回滾條件某一段邏輯失敗單獨(dú)回滾另一段邏輯失敗也單獨(dú)回滾但兩者之間還有業(yè)務(wù)依賴需要?jiǎng)討B(tài)決定事務(wù)是否開啟、是否參與當(dāng)前事務(wù)需要在一個(gè)循環(huán)里為多次操作各自開啟獨(dú)立事務(wù)需要精細(xì)控制事務(wù)的掛起與恢復(fù)這時(shí)編程式事務(wù)更香。Spring 提供了 TransactionTemplate直接手動(dòng)控制事務(wù)的提交和回滾。6.2 TransactionTemplate 的正確打開方式TransactionTemplate 的使用非常簡單但有的人會(huì)用成了“把聲明式注解搬進(jìn)了代碼”Autowired private TransactionTemplate transactionTemplate; public void batchProcess(ListLong ids) { for (Long id : ids) { transactionTemplate.execute(status - { try { // 每一條數(shù)據(jù)一個(gè)事務(wù)某條失敗不影響整體 mapper.update(id); return Boolean.TRUE; } catch (Exception e) { // 手動(dòng)回滾當(dāng)前事務(wù) status.setRollbackOnly(); log.error(處理失敗: {}, id, e); return Boolean.FALSE; } }); } }這個(gè)模式適合批處理任務(wù)。如果每個(gè)數(shù)據(jù)項(xiàng)的處理都希望獨(dú)立提交無論后續(xù)數(shù)據(jù)項(xiàng)成功失敗都不會(huì)相互影響這種結(jié)構(gòu)非常穩(wěn)定。注意 execute 方法返回后的狀態(tài)當(dāng)回調(diào)拋出異常時(shí)TransactionTemplate 會(huì)自動(dòng)回滾當(dāng)回調(diào)正常返回且沒有調(diào)用 setRollbackOnly它會(huì)自動(dòng)提交。所以 catch 塊里一定要把業(yè)務(wù)異常往外拋或設(shè)置 rollbackOnly否則只 catch 不處理照樣可能提交。另一種復(fù)雜場(chǎng)景手動(dòng)開啟事務(wù)、執(zhí)行操作、根據(jù)條件決定提交或回滾Autowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition definition new DefaultTransactionDefinition(); definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); definition.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); TransactionStatus status transactionManager.getTransaction(definition); try { // 業(yè)務(wù)操作1 // 業(yè)務(wù)操作2 boolean needRollback checkSomething(); if (needRollback) { transactionManager.rollback(status); return; } transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; } }這種寫法適合在同一個(gè)方法里實(shí)現(xiàn)多段事務(wù)控制聲明式注解做不到這么細(xì)膩。但它有個(gè)需要注意的地方代碼里 commit 和 rollback 必須保證成功執(zhí)行如果不小心寫漏了事務(wù)會(huì)一直掛著連接無法釋放。使用 TransactionTemplate 可以自動(dòng)管理比手寫 PlatformTransactionManager 的 commit/rollback 更安全。6.3 事務(wù)方法里調(diào)用遠(yuǎn)程接口的“長期鎖”問題聲明式事務(wù)一個(gè)隱蔽的大坑事務(wù)方法里調(diào)用了遠(yuǎn)程接口或 RPC但遠(yuǎn)程接口耗時(shí)很長事務(wù)一直沒提交數(shù)據(jù)庫連接一直占著。如果再涉及鎖其他事務(wù)只能干等。我處理過的一個(gè)問題訂單支付回調(diào)方法里Transactional 方法中調(diào)用了第三方 HTTP 接口原意是想在第三方確認(rèn)后更新訂單狀態(tài)。結(jié)果第三方接口超時(shí) 10 秒整個(gè)事務(wù)就掛了 10 秒。高峰期并發(fā)一上來數(shù)據(jù)庫連接直接被占滿業(yè)務(wù)崩潰還把問題定位到“連接池大小不夠”上誤導(dǎo)了排查方向。正確做法是事務(wù)方法里盡量不調(diào)用遠(yuǎn)程接口把遠(yuǎn)程調(diào)用放到事務(wù)外面。先拿數(shù)據(jù)、再調(diào)遠(yuǎn)程、再開事務(wù)去更新或者反過來先更新本地事務(wù)再調(diào)遠(yuǎn)程失敗后人工介入。遠(yuǎn)程調(diào)用參與事務(wù)只能增加鎖等待時(shí)間和不可控性。如果一定要在事務(wù)內(nèi)調(diào)遠(yuǎn)程也請(qǐng)把超時(shí)時(shí)間設(shè)置得短一些并評(píng)估連接池容量是否能扛住并發(fā)等待。7. 最終自查清單快速定位不生效或者回滾異常這里貢獻(xiàn)一份我實(shí)際用過的排障清單按順序檢查大多數(shù)問題五分鐘之內(nèi)能定位。確認(rèn) Spring 配置里啟用了 EnableTransactionManagement或 XML 的 tx:annotation-driven。沒有開啟注解驅(qū)動(dòng)任何 Transactional 都不會(huì)生效。確認(rèn)事務(wù)管理器是否配置正確數(shù)據(jù)源是否對(duì)得上。多數(shù)據(jù)源場(chǎng)景下不同數(shù)據(jù)源需要對(duì)應(yīng)不同的事務(wù)管理器。確認(rèn)目標(biāo)方法是被代理調(diào)用的不是內(nèi)部 this 調(diào)用。打印類名或判斷增強(qiáng)邏輯。確認(rèn)方法是 public 可見性否則 Spring 不會(huì)攔截。確認(rèn)異常沒有被 catch 吞掉且異常類型匹配回滾規(guī)則。默認(rèn)只有 RuntimeException 和 Error 觸發(fā)回滾checked exception 需要顯式指定 rollbackFor。確認(rèn)傳播行為設(shè)置符合預(yù)期不會(huì)因?yàn)?REQUIRES_NEW 或 NESTED 改變事務(wù)邊界。確認(rèn)方法內(nèi)部沒有新開線程訪問數(shù)據(jù)庫或者確認(rèn)子線程操作確實(shí)應(yīng)該獨(dú)立事務(wù)。確認(rèn)沒有配置 readOnlytrue 的方法執(zhí)行了寫操作且期望回滾以及是否出現(xiàn)鎖等待。還有一條很實(shí)用的經(jīng)驗(yàn)在方法入口和出口打印事務(wù)狀態(tài)信息用TransactionSynchronizationManager.isActualTransactionActive()判斷當(dāng)前是否存在真實(shí)事務(wù)比用日志猜要容易得多。boolean txActive TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(當(dāng)前是否存在真實(shí)事務(wù): txActive);這篇文章基于我實(shí)際踩坑后的總結(jié)把 Spring Transactional 的完整鏈路梳理了一遍。我個(gè)人特別想再強(qiáng)調(diào)一遍注解本身并不復(fù)雜復(fù)雜的是代理鏈路、異常傳播和事務(wù)資源綁定這幾條隱線。理解這幾條隱線遇到多少事務(wù)問題都不會(huì)慌。如果之后還有時(shí)間我會(huì)再整理一篇基于 Spring Boot 3 多數(shù)據(jù)源的項(xiàng)目里不同事務(wù)管理器如何協(xié)同、如何通過事務(wù)同步事件做事務(wù)后的回調(diào)處理。 Spring事務(wù)失效深度解析：@Transactional代理原理與實(shí)戰(zhàn)排查
1. 別再只看表面Transactional 失效背后的真實(shí)原因做了幾年 Java 開發(fā)用 Transactional 注解管理事務(wù)可能是最稀松平常的事。但我見過太多項(xiàng)目里因事務(wù)失效引發(fā)線上數(shù)據(jù)不一致的“事故現(xiàn)場(chǎng)”——庫存扣了、訂單沒生成賬戶扣款成功、余額表沒變化。排查到最后問題往往不在數(shù)據(jù)庫也不在 SQL而是 Transactional 壓根沒生效。我剛帶團(tuán)隊(duì)時(shí)也踩過類似的坑。某個(gè)定時(shí)任務(wù)批量處理對(duì)賬文件方法上加了 Transactional 注解測(cè)試環(huán)境數(shù)據(jù)量小一點(diǎn)問題沒有。上線后某個(gè)批次處理到一半拋了運(yùn)行時(shí)異常結(jié)果發(fā)現(xiàn)前一半已經(jīng)入庫的數(shù)據(jù)沒有回滾徹底把庫存數(shù)據(jù)搞花了。排查后才發(fā)現(xiàn)是同類內(nèi)部方法調(diào)用代理根本沒有攔截。這個(gè)注解到底怎么工作的失效場(chǎng)景有哪些傳播機(jī)制、隔離級(jí)別、連接管理又該怎么選這篇文章不打算停留在“注解真方便”的層面直接把 Spring 事務(wù)從代理原理到實(shí)戰(zhàn)配置拆一遍把那些常規(guī)文檔不會(huì)寫的細(xì)節(jié)講透。先特別強(qiáng)調(diào)一句Spring 的聲明式事務(wù)基于 AOP 動(dòng)態(tài)代理實(shí)現(xiàn)所有“失效”問題幾乎都能從代理機(jī)制上找到根源。Transactional 是 Spring 框架提供的一套聲明式事務(wù)解決方案核心價(jià)值在于將事務(wù)開啟、提交、回滾這些繁瑣操作交給容器去管理開發(fā)者只需在方法或類上標(biāo)注一個(gè)注解。但它的“自動(dòng)”是有前提的背后隱藏著代理對(duì)象、事務(wù)同步管理器、連接綁定等一堆細(xì)節(jié)。搞懂這些細(xì)節(jié)才算真正會(huì)用這個(gè)注解而不是被它坑。2. 手寫一個(gè)代理示例弄清方法調(diào)用為什么“穿透”代理2.1 Spring 事務(wù)的本質(zhì)AOP 動(dòng)態(tài)代理外加一個(gè)事務(wù)攔截器要理解 Transactional 失效原因先得從底層機(jī)制說起。我們平時(shí)寫的業(yè)務(wù) Bean經(jīng)過 Spring 容器初始化后并不是直接返回那個(gè)原始對(duì)象而是返回一個(gè)經(jīng)過 AOP 增強(qiáng)的代理對(duì)象。Spring 默認(rèn)使用 JDK 動(dòng)態(tài)代理也可以配置使用 CGLIB具體要看目標(biāo)類是否實(shí)現(xiàn)了接口。代理對(duì)象跟原始對(duì)象有相同的接口或繼承關(guān)系但內(nèi)部包裹了事務(wù)攔截器邏輯。每次調(diào)用被 Transactional 標(biāo)注的方法時(shí)實(shí)際調(diào)用鏈條是“調(diào)用方 - 代理對(duì)象 - 事務(wù)攔截器 - 原始對(duì)象方法”。事務(wù)攔截器會(huì)做這些事從配置中解析事務(wù)屬性傳播行為、隔離級(jí)別、超時(shí)時(shí)間、只讀標(biāo)志從 Spring 容器中獲取 PlatformTransactionManager 事務(wù)管理器通過事務(wù)管理器開啟事務(wù)、獲取數(shù)據(jù)庫連接把連接綁定到當(dāng)前線程的 ThreadLocal 中執(zhí)行原始對(duì)象的目標(biāo)方法根據(jù)方法執(zhí)行是否拋異常決定提交或回滾清理事務(wù)上下文把連接歸還連接池這個(gè)“代理”的存在意味著目標(biāo)方法被執(zhí)行前和后Spring 都插入了額外邏輯。核心問題在于代理攔截的前提是調(diào)用要經(jīng)過代理對(duì)象。如果調(diào)用沒有經(jīng)過代理而是直接調(diào)用了原始對(duì)象的方法事務(wù)攔截器根本沒有機(jī)會(huì)介入注解自然失效。2.2 自己動(dòng)手模擬代理鏈路的執(zhí)行順序?yàn)榱苏f清這個(gè)問題我用簡化代碼模擬一下代理攔截的過程。雖然 Spring 的 TransactionInterceptor 肯定復(fù)雜得多但整體鏈路就是這么回事。public class TransactionInterceptor { // 模擬代理攔截邏輯 public Object invoke(MethodInvocation invocation) throws Throwable { // 1. 事務(wù)開啟前獲取事務(wù)管理器開啟事務(wù)綁定連接 TransactionStatus status transactionManager.getTransaction(transactionAttribute); try { // 2. 執(zhí)行目標(biāo)方法 Object result invocation.proceed(); // 3. 方法正常返回提交事務(wù) transactionManager.commit(status); return result; } catch (Exception e) { // 4. 方法拋異常按規(guī)則回滾事務(wù) transactionManager.rollback(status); throw e; } finally { // 5. 清理事務(wù)同步狀態(tài) TransactionSynchronizationManager.clear(); } } }從這段鏈路就能看出幾個(gè)關(guān)鍵點(diǎn)。目標(biāo)方法正常結(jié)束才能提交拋了異常才回滾方法執(zhí)行期間事務(wù)相關(guān)信息通過 ThreadLocal 與當(dāng)前線程綁定。所以事務(wù)要不要回滾完全取決于你能不能“感知”到異常。感知不到異常Spring 就只能傻乎乎地提交。再進(jìn)一步說如果調(diào)用方拿到的是原始對(duì)象而不是代理對(duì)象那這段攔截邏輯根本不會(huì)執(zhí)行事務(wù)相當(dāng)于不存在。這種情況最常見的觸發(fā)點(diǎn)就是同類內(nèi)部方法調(diào)用。Component public class OrderService { public void createOrder() { // 這里直接調(diào)用內(nèi)部方法this 是原始對(duì)象不是代理對(duì)象 this.insertOrder(); this.insertOrderItem(); } Transactional public void insertOrder() { // 事務(wù)方法 } Transactional public void insertOrderItem() { // 事務(wù)方法 } }createOrder 方法內(nèi)部this.insertOrder() 和 this.insertOrderItem() 調(diào)用的是 OrderService 原始對(duì)象的方法代理對(duì)象根本沒有介入事務(wù)自然無效。如果 insertOrder 執(zhí)行成功、insertOrderItem 執(zhí)行失敗前者不會(huì)回滾最終造成數(shù)據(jù)不一致。這個(gè)例子描述的問題實(shí)在太常見網(wǎng)上面試題也是高頻考點(diǎn)。但真正落實(shí)到項(xiàng)目里很多人寫的代碼就是這個(gè)形態(tài)然后深夜查數(shù)據(jù)為啥不對(duì)。2.3 為什么 InvocationTargetException 會(huì)干擾你的問題判斷排查事務(wù)問題時(shí)很多人被 InvocationTargetException 繞暈。這個(gè)異常是反射調(diào)用目標(biāo)方法時(shí)的包裝異常目標(biāo)方法本身拋出的異常被包在它的 target 屬性里。代理對(duì)象調(diào)用目標(biāo)方法也是通過反射完成的所以事務(wù)方法內(nèi)部拋出的異常經(jīng)過反射層會(huì)被包裝。Spring 處理回滾時(shí)會(huì)層層解包來解析具體異常類型判斷是否匹配回滾規(guī)則。如果你自己用反射調(diào)用了事務(wù)方法你的 catch 邏輯沒解包直接對(duì)比 InvocationTargetException 的類型肯定對(duì)不上預(yù)期異常事務(wù)回滾判斷也可能出錯(cuò)。實(shí)際排查事務(wù)問題時(shí)第一步應(yīng)該去看目標(biāo)方法是否被代理而不是盯著異常棧一層層猜。最簡單的方式是打印調(diào)用對(duì)象類型。// 容器中注入的類型是代理類 System.out.println(orderService.getClass().getName()); // 輸出中會(huì)出現(xiàn) CGLIB 或 JDK 代理相關(guān)字樣 // 類似 OrderService$$EnhancerBySpringCGLIB如果在容器里這個(gè)類的名字帶了 EnhancerByCGLIB說明走代理鏈路沒問題如果就是普通類名那一定在配置層面出了岔子比如沒有開啟注解驅(qū)動(dòng)事務(wù)。3. 失效場(chǎng)景全排查同類的坑、異常吞掉、非 public 方法3.1 同類自調(diào)用、私有方法、非事務(wù)方法互相調(diào)用事務(wù)方法被同類內(nèi)部其他方法調(diào)用時(shí)事務(wù)失效這是壓倒性的第一大坑。我整理一下這類問題的幾種具體形式以及各自的解決思路。場(chǎng)景一同類內(nèi)部 this 調(diào)用。如上面代碼所示this.method() 調(diào)用繞過代理。解決辦法有幾個(gè)將事務(wù)方法拆分到獨(dú)立的 Service Bean通過注入代理對(duì)象調(diào)用注入自身代理Component public class OrderService { Autowired private OrderService self; public void createOrder() { // 調(diào)用代理自身的 insertOrder事務(wù)能生效 self.insertOrder(); } Transactional public void insertOrder() { ... } }使用 AopContext.currentProxy() 獲取當(dāng)前代理對(duì)象public void createOrder() { OrderService proxy (OrderService) AopContext.currentProxy(); proxy.insertOrder(); }使用 AopContext.currentProxy() 需要在配置里設(shè)置 exposeProxy true否則運(yùn)行時(shí)會(huì)直接拋 IllegalStateException。場(chǎng)景二方法不是 public。Spring 的注解驅(qū)動(dòng)事務(wù)默認(rèn)只對(duì) public 方法生效private、protected、默認(rèn)包可見方法上的 Transactional 都會(huì)失效。原因很簡單Spring 的代理邏輯只對(duì) public 方法進(jìn)行攔截其他可見性方法要么被子類覆蓋邏輯干擾要么根本不被代理鏈調(diào)用。項(xiàng)目里把這個(gè)坑踩穿的人不少特別是內(nèi)部私有方法想“順便”加個(gè)事務(wù)結(jié)果事務(wù)全程沒參與。場(chǎng)景三在非事務(wù)方法里直接調(diào)用另一個(gè)類的事務(wù)方法但那個(gè)非事務(wù)方法也屬于同一個(gè) Bean而且標(biāo)注事務(wù)的方法自己又調(diào)了內(nèi)部方法。這個(gè)組合拳容易和“傳播行為”疊加產(chǎn)生復(fù)雜效果需要先從結(jié)構(gòu)上理清楚調(diào)用鏈。一般建議事務(wù)邊界放在入口方法上而不是撒在多個(gè)內(nèi)部方法上。你可以在一個(gè)方法上統(tǒng)一管理事務(wù)內(nèi)部方法就不要再標(biāo)注事務(wù)以免傳播行為互相干擾。3.2 異常被 catch 吞掉事務(wù)提交了你以為回滾了這是事務(wù)失效的第二大場(chǎng)景。代碼長這樣Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); // 這里拋了業(yè)務(wù)異常 throw new RuntimeException(余額不足); } catch (Exception e) { // 異常被吞掉方法正常返回 log.info(轉(zhuǎn)賬失敗: {}, e.getMessage()); } }方法體內(nèi)部把異常 catch 了沒有重新拋出方法正常返回。Spring 事務(wù)攔截器看到方法正常返回認(rèn)為一切成功就把事務(wù)提交了。結(jié)果是余額已經(jīng)扣減但調(diào)用方根本不知道出了問題。這在真實(shí)項(xiàng)目中非常隱蔽因?yàn)槿罩纠锟雌饋碛袌?bào)錯(cuò)你以為事務(wù)回滾了實(shí)際數(shù)據(jù)庫已經(jīng)改動(dòng)。排查手段也很反直覺要看日志打印順序如果事務(wù)提交日志沒打印那可能是異常沒有被攔截器感知。正確做法有兩種。要么在 catch 塊中手工標(biāo)記回滾Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); throw new RuntimeException(余額不足); } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); log.info(轉(zhuǎn)賬失敗: {}, e.getMessage()); // 這里可以繼續(xù)做其他操作事務(wù)最終還是會(huì)回滾 } }要么就不要 catch讓異常傳到事務(wù)攔截器層面由 Spring 統(tǒng)一處理回滾。大多數(shù)情況下第二種更簡潔。如果需要 catch 做一些日志記錄可以 catch 之后再原樣拋出或者使用自定義異常封裝后拋出。吞異常是最不可取的。3.3 非異常導(dǎo)致回滾失效的其他隱蔽案例還有一個(gè)常見問題是 SQL 執(zhí)行成功但沒匹配到任何行。比如更新語句 set 的條件生效了但對(duì)列表為空導(dǎo)致影響行數(shù)為 0方法本身沒有任何異常。此時(shí)事務(wù)雖然參與但沒產(chǎn)生實(shí)際變化這不算事務(wù)失效只算業(yè)務(wù)邏輯問題。要判斷事務(wù)是否真的提交了應(yīng)該看數(shù)據(jù)庫鎖和日志而不是代碼。另一種隱蔽問題是多線程。Spring 事務(wù)是通過 ThreadLocal 把數(shù)據(jù)庫連接綁定到當(dāng)前線程的。如果你在事務(wù)方法內(nèi)啟動(dòng)了新線程去執(zhí)行數(shù)據(jù)庫操作那個(gè)新線程拿不到事務(wù)上下文綁定的連接也就無法參與當(dāng)前事務(wù)。如果子線程里操作的是另一個(gè)數(shù)據(jù)源更是各走各的。這種場(chǎng)景在異步任務(wù)、消息處理中很常見正確的做法是把事務(wù)邊界移到子線程要執(zhí)行的方法上或者使用編程式事務(wù)確保子線程有自己的事務(wù)上下文。還有一點(diǎn)值得記錄動(dòng)態(tài)代理生效范圍和方法可見性綁定。如果方法標(biāo)注了 Transactional 但不是 publicSpring 不會(huì)直接報(bào)錯(cuò)而是靜默忽略這很討厭。建議團(tuán)隊(duì) Code Review 時(shí)多加注意或者引入架構(gòu)守護(hù)工具掃描非 public 方法上的 Transactional。4. 傳播行為不是隨便選的REQUIRED 與 REQUIRES_NEW 實(shí)戰(zhàn)差異4.1 七種傳播行為的概念與關(guān)鍵選擇場(chǎng)景Spring 定義了七種事務(wù)傳播行為默認(rèn)是 REQUIRED。我用一張表把最常用的幾種整理出來重點(diǎn)關(guān)注它們的事務(wù)關(guān)系和行為效果。傳播行為當(dāng)前存在事務(wù)時(shí)當(dāng)前無事務(wù)時(shí)典型場(chǎng)景REQUIRED加入當(dāng)前事務(wù)新建事務(wù)同一事務(wù)內(nèi)多個(gè)操作默認(rèn)選它REQUIRES_NEW掛起當(dāng)前事務(wù)新建事務(wù)新建事務(wù)日志記錄、審計(jì)、消息發(fā)送必須獨(dú)立提交NESTED嵌套事務(wù)保存點(diǎn)回滾新建事務(wù)某一段邏輯失敗不影響主事務(wù)整體回滾SUPPORTS加入當(dāng)前事務(wù)非事務(wù)方式執(zhí)行查詢操作有事務(wù)就參與沒有也行NOT_SUPPORTED掛起當(dāng)前事務(wù)非事務(wù)執(zhí)行非事務(wù)方式執(zhí)行某些特殊操作不希望占用事務(wù)連接MANDATORY加入當(dāng)前事務(wù)拋異常強(qiáng)制要求必須在一個(gè)事務(wù)中執(zhí)行NEVER拋異常非事務(wù)方式執(zhí)行嚴(yán)格禁止事務(wù)實(shí)際團(tuán)隊(duì)里用得最多的就是前三個(gè)。如果不理解 REQUIRES_NEW 和 REQUIRED 的區(qū)別可能會(huì)出現(xiàn)這樣的場(chǎng)景用戶下訂單時(shí)往訂單流水表插一條記錄結(jié)果訂單主流程回滾了流水也跟著回滾審計(jì)日志全沒了。4.2 REQUIRES_NEW 是“停掉一個(gè)事務(wù)開另一個(gè)事務(wù)”不是嵌套R(shí)EQUIRES_NEW 的行為是外層事務(wù)被掛起內(nèi)層方法開啟一個(gè)全新事務(wù)內(nèi)外兩個(gè)事務(wù)彼此隔離。內(nèi)層事務(wù)提交后即使外層事務(wù)最終回滾內(nèi)層事務(wù)已經(jīng)提交的數(shù)據(jù)不會(huì)被回滾。這個(gè)特征特別適合某些“無論如何都要記錄”的場(chǎng)景比如消息發(fā)送、審計(jì)日志、操作記錄。但注意一點(diǎn)REQUIRES_NEW 是需要額外數(shù)據(jù)庫連接資源的。事務(wù)掛起期間外層連接被持有但處于閑置狀態(tài)內(nèi)層再獲取一個(gè)新連接高并發(fā)下連接池容易出現(xiàn)空閑等待。連接池如果很小這種方法容易成為瓶頸。如果確實(shí)想實(shí)現(xiàn)“部分成功、部分失敗不影響主流程”可以選擇 NESTED 結(jié)合保存點(diǎn)機(jī)制。NESTED 不會(huì)掛起外層事務(wù)而是使用數(shù)據(jù)庫 savepoint 特性在內(nèi)層方法出錯(cuò)時(shí)回滾到保存點(diǎn)。主事務(wù)依然持有連接連接資源消耗比 REQUIRES_NEW 小但 MySQL 等數(shù)據(jù)庫支持嵌套事務(wù)的能力要看具體驅(qū)動(dòng)配置。我在項(xiàng)目中通常優(yōu)先使用 REQUIRES_NEW 處理日志類獨(dú)立提交需求用 NESTED 處理復(fù)雜的批量業(yè)務(wù)分段回滾需求。4.3 自調(diào)用與傳播行為的組合陷阱一個(gè)案例拆到底下面這個(gè)案例我去年在某項(xiàng)目排查了整晚正好把“自調(diào)用 傳播行為”組合起來說明。Service public class OrderService { Autowired private OrderMapper orderMapper; public void createOrderWithLog() { // 同類調(diào)用事務(wù)不會(huì)在這里統(tǒng)一 this.saveOrder(); this.saveOrderLog(); } Transactional(propagation Propagation.REQUIRED) public void saveOrder() { orderMapper.insertOrder(...); } Transactional(propagation Propagation.REQUIRES_NEW) public void saveOrderLog() { orderMapper.insertOrderLog(...); } }執(zhí)行 createOrderWithLog 時(shí)this.saveOrder() 和 this.saveOrderLog() 都是直接調(diào)用內(nèi)部對(duì)象方法兩個(gè)方法上的 Transactional 全部失效saveOrderLog 的 REQUIRES_NEW 根本不會(huì)新建獨(dú)立事務(wù)。表面上看著是兩個(gè)獨(dú)立事務(wù)實(shí)際是零事務(wù)因?yàn)樗鼈兌紱]走代理。排查這類問題最典型的線索就是執(zhí)行失敗時(shí)數(shù)據(jù)庫數(shù)據(jù)已經(jīng)寫入了。因?yàn)楫惓１煌悆?nèi)部調(diào)用“截?cái)唷贝韺記]有任何攔截。正確的結(jié)構(gòu)應(yīng)當(dāng)是Service public class OrderService { Autowired private OrderService self; Autowired private OrderLogService orderLogService; public void createOrderWithLog() { // 通過代理調(diào)用自身主方法事務(wù)生效 self.saveOrder(); // 通過獨(dú)立 Bean 調(diào)用REQUIRES_NEW 生效 orderLogService.saveOrderLog(); } }把 saveOrderLog 拆到 OrderLogService 中并且用 OrderLogService 的代理對(duì)象去調(diào)用REQUIRES_NEW 才會(huì)真正意義上開啟新事務(wù)。自調(diào)用加傳播行為的組合是最容易讓經(jīng)驗(yàn)豐富的開發(fā)者都掉坑的地方。5. 隔離級(jí)別、只讀事務(wù)與連接綁定一次說清配置誤區(qū)5.1 隔離級(jí)別不是越高越好關(guān)鍵是匹配業(yè)務(wù)場(chǎng)景Spring 事務(wù)注解通過 isolation 屬性指定隔離級(jí)別默認(rèn)使用數(shù)據(jù)庫默認(rèn)隔離級(jí)別MySQL 為 REPEATABLE_READ。很多新手一上來直接設(shè)置 SERIALIZABLE覺得“最高級(jí)最安全”但代價(jià)是性能和并發(fā)能力斷崖式下降。各隔離級(jí)別解決的核心問題不同應(yīng)對(duì)的選擇應(yīng)該是從業(yè)務(wù)需求出發(fā)READ_UNCOMMITTED能讀到未提交數(shù)據(jù)臟讀風(fēng)險(xiǎn)大幾乎不會(huì)用在生產(chǎn)環(huán)境READ_COMMITTED解決臟讀但不可重復(fù)讀問題仍然存在適用對(duì)一致性要求不極致的查詢類場(chǎng)景REPEATABLE_READ解決臟讀和不可重復(fù)讀MySQL 默認(rèn)配合 MVCC 提供快照讀SERIALIZABLE完全串行化寫并發(fā)能力極差只用于極少數(shù)對(duì)數(shù)據(jù)一致性要求極端、寫并發(fā)低的場(chǎng)景實(shí)際開發(fā)中如果兩個(gè)并發(fā)事務(wù)要同時(shí)操作同一行庫存數(shù)據(jù)用 READ_COMMITTED 加數(shù)據(jù)庫悲觀鎖select ... for update通常比 REPEATABLE_READ 更可控。REPEATABLE_READ 在 MySQL 里通過快照讀實(shí)現(xiàn)兩個(gè)事務(wù)各自讀到自己的快照反而可能讓并發(fā)更新改為最后提交覆蓋結(jié)果帶來臟寫風(fēng)險(xiǎn)。我見過有人把隔離級(jí)別升到 SERIALIZABLE 來解決并發(fā)扣庫存問題結(jié)果壓測(cè)直接打滿數(shù)據(jù)庫連接業(yè)務(wù)超時(shí)一大片這不是事務(wù)注解的鍋是對(duì)隔離級(jí)別理解有偏差。5.2 readOnly true 到底做了什么別被名字誤導(dǎo)readOnly 屬性設(shè)置成 true 時(shí)Spring 會(huì)做兩件事向數(shù)據(jù)庫提示這是只讀事務(wù)有些數(shù)據(jù)庫會(huì)以此做優(yōu)化但 MySQL 的 InnoDB 引擎并不會(huì)因此跳過加鎖有些場(chǎng)景下Spring 會(huì)關(guān)閉某些持久層框架的臟檢查、flush 機(jī)制提升一點(diǎn)性能但要注意readOnly true 并不能阻止你在事務(wù)方法里執(zhí)行 insert、update、delete。它只是建議性提示不是硬性校驗(yàn)。Spring 默認(rèn)并不會(huì)攔截寫操作。如果你的項(xiàng)目里想通過 readOnly 做強(qiáng)制校驗(yàn)?zāi)鞘峭耆e(cuò)誤的用法。我平時(shí)會(huì)把 readOnly 用在以下兩類方法上查詢單條或多條數(shù)據(jù)的 Service 方法大批量只讀統(tǒng)計(jì)方法配合超時(shí)時(shí)間控制寫操作的方法一律不設(shè) readOnly避免和事務(wù)攔截器的行為產(chǎn)生模糊地帶。如果你的方法只讀但內(nèi)部還調(diào)了查詢后寫入 Redis 這類操作也最好別標(biāo) readOnly因?yàn)?Redis 操作不走數(shù)據(jù)庫事務(wù)但 Spring 的只讀提示沒有太大意義。穩(wěn)妥起見只對(duì)純數(shù)據(jù)庫查詢才設(shè)置。5.3 事務(wù)超時(shí)時(shí)間和連接綁定ThreadLocal 的另一個(gè)細(xì)節(jié)事務(wù)超時(shí)時(shí)間timeout單位是秒默認(rèn) -1 表示不超時(shí)。如果設(shè)置超時(shí)一旦事務(wù)執(zhí)行超過閾值Spring 會(huì)嘗試回滾事務(wù)但具體行為取決于數(shù)據(jù)庫驅(qū)動(dòng)和底層連接狀態(tài)并不保證一定會(huì)回滾。這里很容易出現(xiàn)“超時(shí)了但鎖沒釋放”的棘手問題。數(shù)據(jù)庫事務(wù)是通過連接綁定的連接又是從連接池借來的。Spring 把連接保存到 TransactionSynchronizationManager 的 ThreadLocal 中。每個(gè)線程里的操作都使用同一個(gè)線程綁定的連接確保整個(gè)事務(wù)操作的是同一個(gè)連接而不是從連接池里每次拿新連接。這就是事務(wù)一致性的基礎(chǔ)。如果方法內(nèi)部直接使用 new Thread() 或線程池去執(zhí)行數(shù)據(jù)庫操作子線程里的數(shù)據(jù)庫訪問不在同一個(gè) ThreadLocal 上下文里自然不會(huì)繼承父線程的事務(wù)連接。這種場(chǎng)景下的操作要么各自獨(dú)立提交要么直接拋錯(cuò)。有些團(tuán)隊(duì)因?yàn)橐粋€(gè)異步任務(wù)在事務(wù)里更新了兩張表子線程更新另一張表最后數(shù)據(jù)亂套就是這個(gè)原因。6. 什么時(shí)候必須放棄聲明式事務(wù)改用編程式事務(wù)6.1 聲明式事務(wù)的靈活性邊界Transactional 是“開箱即用”的代表但有個(gè)天然缺點(diǎn)方法粒度控制。事務(wù)邊界是從方法進(jìn)入開始方法結(jié)束提交或回滾。遇到下面這些場(chǎng)景聲明式事務(wù)反而不好用同一個(gè)方法里想在不同階段設(shè)置不同的回滾條件某一段邏輯失敗單獨(dú)回滾另一段邏輯失敗也單獨(dú)回滾但兩者之間還有業(yè)務(wù)依賴需要?jiǎng)討B(tài)決定事務(wù)是否開啟、是否參與當(dāng)前事務(wù)需要在一個(gè)循環(huán)里為多次操作各自開啟獨(dú)立事務(wù)需要精細(xì)控制事務(wù)的掛起與恢復(fù)這時(shí)編程式事務(wù)更香。Spring 提供了 TransactionTemplate直接手動(dòng)控制事務(wù)的提交和回滾。6.2 TransactionTemplate 的正確打開方式TransactionTemplate 的使用非常簡單但有的人會(huì)用成了“把聲明式注解搬進(jìn)了代碼”Autowired private TransactionTemplate transactionTemplate; public void batchProcess(ListLong ids) { for (Long id : ids) { transactionTemplate.execute(status - { try { // 每一條數(shù)據(jù)一個(gè)事務(wù)某條失敗不影響整體 mapper.update(id); return Boolean.TRUE; } catch (Exception e) { // 手動(dòng)回滾當(dāng)前事務(wù) status.setRollbackOnly(); log.error(處理失敗: {}, id, e); return Boolean.FALSE; } }); } }這個(gè)模式適合批處理任務(wù)。如果每個(gè)數(shù)據(jù)項(xiàng)的處理都希望獨(dú)立提交無論后續(xù)數(shù)據(jù)項(xiàng)成功失敗都不會(huì)相互影響這種結(jié)構(gòu)非常穩(wěn)定。注意 execute 方法返回后的狀態(tài)當(dāng)回調(diào)拋出異常時(shí)TransactionTemplate 會(huì)自動(dòng)回滾當(dāng)回調(diào)正常返回且沒有調(diào)用 setRollbackOnly它會(huì)自動(dòng)提交。所以 catch 塊里一定要把業(yè)務(wù)異常往外拋或設(shè)置 rollbackOnly否則只 catch 不處理照樣可能提交。另一種復(fù)雜場(chǎng)景手動(dòng)開啟事務(wù)、執(zhí)行操作、根據(jù)條件決定提交或回滾Autowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition definition new DefaultTransactionDefinition(); definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); definition.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); TransactionStatus status transactionManager.getTransaction(definition); try { // 業(yè)務(wù)操作1 // 業(yè)務(wù)操作2 boolean needRollback checkSomething(); if (needRollback) { transactionManager.rollback(status); return; } transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; } }這種寫法適合在同一個(gè)方法里實(shí)現(xiàn)多段事務(wù)控制聲明式注解做不到這么細(xì)膩。但它有個(gè)需要注意的地方代碼里 commit 和 rollback 必須保證成功執(zhí)行如果不小心寫漏了事務(wù)會(huì)一直掛著連接無法釋放。使用 TransactionTemplate 可以自動(dòng)管理比手寫 PlatformTransactionManager 的 commit/rollback 更安全。6.3 事務(wù)方法里調(diào)用遠(yuǎn)程接口的“長期鎖”問題聲明式事務(wù)一個(gè)隱蔽的大坑事務(wù)方法里調(diào)用了遠(yuǎn)程接口或 RPC但遠(yuǎn)程接口耗時(shí)很長事務(wù)一直沒提交數(shù)據(jù)庫連接一直占著。如果再涉及鎖其他事務(wù)只能干等。我處理過的一個(gè)問題訂單支付回調(diào)方法里Transactional 方法中調(diào)用了第三方 HTTP 接口原意是想在第三方確認(rèn)后更新訂單狀態(tài)。結(jié)果第三方接口超時(shí) 10 秒整個(gè)事務(wù)就掛了 10 秒。高峰期并發(fā)一上來數(shù)據(jù)庫連接直接被占滿業(yè)務(wù)崩潰還把問題定位到“連接池大小不夠”上誤導(dǎo)了排查方向。正確做法是事務(wù)方法里盡量不調(diào)用遠(yuǎn)程接口把遠(yuǎn)程調(diào)用放到事務(wù)外面。先拿數(shù)據(jù)、再調(diào)遠(yuǎn)程、再開事務(wù)去更新或者反過來先更新本地事務(wù)再調(diào)遠(yuǎn)程失敗后人工介入。遠(yuǎn)程調(diào)用參與事務(wù)只能增加鎖等待時(shí)間和不可控性。如果一定要在事務(wù)內(nèi)調(diào)遠(yuǎn)程也請(qǐng)把超時(shí)時(shí)間設(shè)置得短一些并評(píng)估連接池容量是否能扛住并發(fā)等待。7. 最終自查清單快速定位不生效或者回滾異常這里貢獻(xiàn)一份我實(shí)際用過的排障清單按順序檢查大多數(shù)問題五分鐘之內(nèi)能定位。確認(rèn) Spring 配置里啟用了 EnableTransactionManagement或 XML 的 tx:annotation-driven。沒有開啟注解驅(qū)動(dòng)任何 Transactional 都不會(huì)生效。確認(rèn)事務(wù)管理器是否配置正確數(shù)據(jù)源是否對(duì)得上。多數(shù)據(jù)源場(chǎng)景下不同數(shù)據(jù)源需要對(duì)應(yīng)不同的事務(wù)管理器。確認(rèn)目標(biāo)方法是被代理調(diào)用的不是內(nèi)部 this 調(diào)用。打印類名或判斷增強(qiáng)邏輯。確認(rèn)方法是 public 可見性否則 Spring 不會(huì)攔截。確認(rèn)異常沒有被 catch 吞掉且異常類型匹配回滾規(guī)則。默認(rèn)只有 RuntimeException 和 Error 觸發(fā)回滾checked exception 需要顯式指定 rollbackFor。確認(rèn)傳播行為設(shè)置符合預(yù)期不會(huì)因?yàn)?REQUIRES_NEW 或 NESTED 改變事務(wù)邊界。確認(rèn)方法內(nèi)部沒有新開線程訪問數(shù)據(jù)庫或者確認(rèn)子線程操作確實(shí)應(yīng)該獨(dú)立事務(wù)。確認(rèn)沒有配置 readOnlytrue 的方法執(zhí)行了寫操作且期望回滾以及是否出現(xiàn)鎖等待。還有一條很實(shí)用的經(jīng)驗(yàn)在方法入口和出口打印事務(wù)狀態(tài)信息用TransactionSynchronizationManager.isActualTransactionActive()判斷當(dāng)前是否存在真實(shí)事務(wù)比用日志猜要容易得多。boolean txActive TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(當(dāng)前是否存在真實(shí)事務(wù): txActive);這篇文章基于我實(shí)際踩坑后的總結(jié)把 Spring Transactional 的完整鏈路梳理了一遍。我個(gè)人特別想再強(qiáng)調(diào)一遍注解本身并不復(fù)雜復(fù)雜的是代理鏈路、異常傳播和事務(wù)資源綁定這幾條隱線。理解這幾條隱線遇到多少事務(wù)問題都不會(huì)慌。如果之后還有時(shí)間我會(huì)再整理一篇基于 Spring Boot 3 多數(shù)據(jù)源的項(xiàng)目里不同事務(wù)管理器如何協(xié)同、如何通過事務(wù)同步事件做事務(wù)后的回調(diào)處理。