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