一、引言為什么面試官總盯著 Spring 事務(wù)不放在 Java 后端面試中Spring 事務(wù)幾乎是必考項(xiàng)。很多候選人能張口就背「Spring 事務(wù)通過(guò) AOP 實(shí)現(xiàn)」「Transactional 注解底層是動(dòng)態(tài)代理」「事務(wù)的傳播行為有七種」。但當(dāng)面試官繼續(xù)追問(wèn)一句「那你說(shuō)說(shuō) TransactionInterceptor 內(nèi)部到底做了什么」「為什么自調(diào)用會(huì)讓事務(wù)失效」「REQUIRES_NEW 和 NESTED 在底層有何本質(zhì)區(qū)別」不少人就開始露怯。原因很簡(jiǎn)單大多數(shù)人只記住了結(jié)論卻沒(méi)有真正理解 Spring 事務(wù)的設(shè)計(jì)原理。本文嘗試從面試官的視角把 Spring 事務(wù)從核心抽象、AOP 攔截、事務(wù)管理器體系、傳播行為源碼、同步機(jī)制到失效場(chǎng)景系統(tǒng)梳理一遍力求講透「為什么這么設(shè)計(jì)」以及「源碼里到底發(fā)生了什么」。閱讀本文后你將能夠清晰地回答以下高頻問(wèn)題Spring 事務(wù)的核心接口有哪些分別承擔(dān)什么職責(zé)聲明式事務(wù)的底層實(shí)現(xiàn)原理是什么TransactionInterceptor 的完整執(zhí)行流程是怎樣的七種傳播行為在源碼層面如何實(shí)現(xiàn)為什么事務(wù)方法自調(diào)用會(huì)失效事務(wù)失效的常見(jiàn)場(chǎng)景有哪些事務(wù)同步機(jī)制 TransactionSynchronizationManager 的作用是什么二、事務(wù)基礎(chǔ)回顧先把地基打牢在深入 Spring 之前必須先回顧數(shù)據(jù)庫(kù)事務(wù)的基本概念。如果這部分不扎實(shí)后面理解 Spring 的事務(wù)抽象會(huì)比較吃力。2.1 什么是事務(wù)事務(wù)是一組操作的集合這組操作要么全部成功要么全部失敗。最經(jīng)典的例子是銀行轉(zhuǎn)賬A 賬戶扣款 100 元B 賬戶加款 100 元這兩個(gè)操作必須同時(shí)成功或同時(shí)失敗否則就會(huì)出現(xiàn)資金憑空消失或憑空多出的問(wèn)題。事務(wù)存在的根本目的是保證數(shù)據(jù)的一致性。數(shù)據(jù)庫(kù)通過(guò)事務(wù)把多個(gè)寫操作綁定為一個(gè)原子單元并在系統(tǒng)故障、并發(fā)訪問(wèn)等復(fù)雜場(chǎng)景下維持?jǐn)?shù)據(jù)的正確性。2.2 ACID 四大特性事務(wù)具備四個(gè)基本特性簡(jiǎn)稱 ACID原子性Atomicity事務(wù)中的所有操作要么全部執(zhí)行成功要么全部不執(zhí)行。即使中途發(fā)生錯(cuò)誤也必須回滾到事務(wù)開始前的狀態(tài)。一致性Consistency事務(wù)執(zhí)行前后數(shù)據(jù)庫(kù)必須從一個(gè)一致性狀態(tài)轉(zhuǎn)換到另一個(gè)一致性狀態(tài)。例如轉(zhuǎn)賬前后兩個(gè)賬戶的總金額必須保持不變。隔離性Isolation多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)彼此之間不能互相干擾。一個(gè)事務(wù)的執(zhí)行過(guò)程對(duì)其他事務(wù)應(yīng)該是隔離的。持久性Durability事務(wù)一旦提交對(duì)數(shù)據(jù)的修改就是永久性的即使系統(tǒng)崩潰也不會(huì)丟失。其中隔離性是最復(fù)雜、也是面試最愛(ài)考的點(diǎn)因?yàn)樗苯雨P(guān)系到并發(fā)場(chǎng)景下的數(shù)據(jù)正確性。2.3 數(shù)據(jù)庫(kù)隔離級(jí)別如果事務(wù)完全串行執(zhí)行隔離性自然最好但并發(fā)性能會(huì)非常差。數(shù)據(jù)庫(kù)為了在隔離性和性能之間做權(quán)衡定義了四種隔離級(jí)別隔離級(jí)別臟讀不可重復(fù)讀幻讀讀未提交READ UNCOMMITTED可能可能可能讀已提交READ COMMITTED不可能可能可能可重復(fù)讀REPEATABLE READ不可能不可能可能MySQL 通過(guò)間隙鎖基本解決串行化SERIALIZABLE不可能不可能不可能這里解釋三個(gè)并發(fā)問(wèn)題臟讀一個(gè)事務(wù)讀到了另一個(gè)事務(wù)尚未提交的數(shù)據(jù)。如果另一個(gè)事務(wù)最終回滾讀到的就是無(wú)效的「臟數(shù)據(jù)」。不可重復(fù)讀同一個(gè)事務(wù)內(nèi)多次讀取同一條數(shù)據(jù)結(jié)果不一致。原因是其他事務(wù)在兩次讀取之間提交了修改?；米x同一個(gè)事務(wù)內(nèi)兩次查詢得到的記錄條數(shù)不一致。原因是其他事務(wù)在兩次查詢之間插入或刪除了記錄。理解這三個(gè)概念非常重要因?yàn)?Spring 事務(wù)的隔離級(jí)別底層最終依賴數(shù)據(jù)庫(kù)實(shí)現(xiàn)而 MySQL 的默認(rèn)隔離級(jí)別是可重復(fù)讀。2.4 事務(wù)傳播行為傳播行為解決的是這樣一個(gè)問(wèn)題當(dāng)一個(gè)事務(wù)方法被另一個(gè)事務(wù)方法調(diào)用時(shí)應(yīng)該如何處理事務(wù)邊界是加入已有事務(wù)還是新建事務(wù)還是以非事務(wù)方式運(yùn)行標(biāo)準(zhǔn)定義中有七種傳播行為Spring 全部支持REQUIRED如果當(dāng)前存在事務(wù)則加入否則新建事務(wù)。默認(rèn)行為。REQUIRES_NEW每次都新建事務(wù)。如果當(dāng)前存在事務(wù)則把當(dāng)前事務(wù)掛起。SUPPORTS如果當(dāng)前存在事務(wù)則加入否則以非事務(wù)方式運(yùn)行。NOT_SUPPORTED以非事務(wù)方式運(yùn)行。如果當(dāng)前存在事務(wù)則把當(dāng)前事務(wù)掛起。MANDATORY必須在事務(wù)中運(yùn)行否則拋出異常。NEVER必須在非事務(wù)中運(yùn)行否則拋出異常。NESTED如果當(dāng)前存在事務(wù)則創(chuàng)建嵌套事務(wù)否則新建事務(wù)。其中REQUIRED、REQUIRES_NEW、NESTED 是面試重點(diǎn)后文會(huì)結(jié)合源碼深入分析。三、Spring 事務(wù)的核心抽象三大接口Spring 并沒(méi)有重新發(fā)明事務(wù)而是對(duì)底層 JDBC、JPA、Hibernate 等事務(wù)操作進(jìn)行了統(tǒng)一抽象。這一設(shè)計(jì)思想正是 Spring 一貫的「抽象統(tǒng)一、屏蔽差異」策略。Spring 事務(wù)模塊的核心抽象主要包含三個(gè)接口PlatformTransactionManager、TransactionDefinition和TransactionStatus。3.1 PlatformTransactionManager事務(wù)管理器PlatformTransactionManager 是事務(wù)管理的核心接口負(fù)責(zé)事務(wù)的創(chuàng)建、提交和回滾。其定義如下public interface PlatformTransactionManager extends TransactionManager { TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException; void commit(TransactionStatus status) throws TransactionException; void rollback(TransactionStatus status) throws TransactionException; }這個(gè)接口只有三個(gè)方法設(shè)計(jì)非常簡(jiǎn)潔getTransaction根據(jù)事務(wù)定義獲取事務(wù)狀態(tài)。如果當(dāng)前已有事務(wù)則根據(jù)傳播行為決定是否加入如果沒(méi)有事務(wù)則創(chuàng)建新事務(wù)。commit提交事務(wù)。rollback回滾事務(wù)。為什么叫 Platform因?yàn)樗强缙脚_(tái)的抽象。無(wú)論底層是 JDBC、JPA 還是 Hibernate上層處理事務(wù)的邏輯完全一致只需要針對(duì)不同數(shù)據(jù)訪問(wèn)技術(shù)提供不同的實(shí)現(xiàn)類即可。3.2 TransactionDefinition事務(wù)定義TransactionDefinition 描述了一個(gè)事務(wù)的基本屬性包括傳播行為、隔離級(jí)別、超時(shí)時(shí)間、是否只讀以及事務(wù)名稱。它相當(dāng)于事務(wù)的「配置元數(shù)據(jù)」。public interface TransactionDefinition { int PROPAGATION_REQUIRED 0; int PROPAGATION_SUPPORTS 1; int PROPAGATION_MANDATORY 2; int PROPAGATION_REQUIRES_NEW 3; int PROPAGATION_NOT_SUPPORTED 4; int PROPAGATION_NEVER 5; int PROPAGATION_NESTED 6; int ISOLATION_DEFAULT -1; int ISOLATION_READ_UNCOMMITTED 1; int ISOLATION_READ_COMMITTED 2; int ISOLATION_REPEATABLE_READ 4; int ISOLATION_SERIALIZABLE 8; int TIMEOUT_DEFAULT -1; int getPropagationBehavior(); int getIsolationLevel(); int getTimeout(); boolean isReadOnly(); String getName(); }這里可以看到傳播行為、隔離級(jí)別本質(zhì)上都是 int 常量。之所以用 int 而不用枚舉是因?yàn)?Spring 早期版本為了兼容性采用了常量設(shè)計(jì)。3.3 TransactionStatus事務(wù)狀態(tài)TransactionStatus 表示事務(wù)的運(yùn)行時(shí)狀態(tài)它讓事務(wù)管理器能夠跟蹤當(dāng)前事務(wù)的執(zhí)行情況并決定提交還是回滾。public interface TransactionStatus extends TransactionExecution, SavepointManager { boolean isNewTransaction(); boolean hasSavepoint(); void setRollbackOnly(); boolean isRollbackOnly(); void flush(); boolean isCompleted(); }其中幾個(gè)關(guān)鍵方法isNewTransaction判斷當(dāng)前事務(wù)是否是新創(chuàng)建的。這個(gè)狀態(tài)對(duì)傳播行為至關(guān)重要。如果是加入已有事務(wù)該方法會(huì)返回 false如果是新建事務(wù)返回 true。setRollbackOnly / isRollbackOnly標(biāo)記事務(wù)只能回滾。當(dāng)內(nèi)部方法捕獲了異常但沒(méi)有繼續(xù)拋出時(shí)外部事務(wù)可以通過(guò)這個(gè)標(biāo)記感知異常從而回滾。hasSavepoint是否存在保存點(diǎn)與 NESTED 傳播行為相關(guān)。這套「定義 管理器 狀態(tài)」的三元抽象把事務(wù)的配置、執(zhí)行和狀態(tài)完全解耦是 Spring 事務(wù)模塊優(yōu)雅設(shè)計(jì)的體現(xiàn)。四、Spring 事務(wù)的兩種使用方式Spring 提供兩種事務(wù)使用方式編程式事務(wù)和聲明式事務(wù)。4.1 編程式事務(wù)編程式事務(wù)需要開發(fā)者在代碼中手動(dòng)控制事務(wù)的開啟、提交和回滾。最直接的方式是使用 TransactionTemplateService public class AccountService { private final TransactionTemplate transactionTemplate; public AccountService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); } public void transfer(Long fromId, Long toId, BigDecimal amount) { transactionTemplate.execute(status - { try { accountDao.decrease(fromId, amount); accountDao.increase(toId, amount); return null; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); } }編程式事務(wù)的優(yōu)點(diǎn)是控制粒度細(xì)、邏輯直觀缺點(diǎn)是業(yè)務(wù)代碼與事務(wù)代碼耦合重復(fù)代碼多。4.2 聲明式事務(wù)聲明式事務(wù)通過(guò) AOP 將事務(wù)管理與業(yè)務(wù)代碼完全解耦開發(fā)者只需要在方法上加上 Transactional 注解即可Service public class AccountService { Transactional(rollbackFor Exception.class) public void transfer(Long fromId, Long toId, BigDecimal amount) { accountDao.decrease(fromId, amount); accountDao.increase(toId, amount); } }聲明式事務(wù)的優(yōu)點(diǎn)是非侵入、代碼簡(jiǎn)潔也是實(shí)際開發(fā)中最常見(jiàn)的方式。4.3 兩種方式的底層一致性很多候選人以為編程式事務(wù)和聲明式事務(wù)是兩套完全不同的機(jī)制。實(shí)際上它們最終都匯聚到同一個(gè)核心PlatformTransactionManager。無(wú)論是 TransactionTemplate 的 execute 方法還是 Transactional 注解觸發(fā)的攔截器最終都是調(diào)用事務(wù)管理器的 getTransaction、commit、rollback 方法。換句話說(shuō)聲明式事務(wù)只是編程式事務(wù)的「AOP 封裝」。理解這一點(diǎn)是吃透 Spring 事務(wù)原理的關(guān)鍵。五、聲明式事務(wù)的底層原理AOP 代理聲明式事務(wù)之所以能夠做到「加個(gè)注解就生效」核心依賴 Spring AOP。這一節(jié)我們從代理機(jī)制講起。5.1 動(dòng)態(tài)代理機(jī)制Spring AOP 底層有兩種動(dòng)態(tài)代理實(shí)現(xiàn)JDK 動(dòng)態(tài)代理目標(biāo)類必須實(shí)現(xiàn)接口通過(guò) java.lang.reflect.Proxy 生成代理對(duì)象。CGLIB 代理目標(biāo)類無(wú)需實(shí)現(xiàn)接口通過(guò)繼承目標(biāo)類并覆寫方法生成子類代理。Spring 默認(rèn)的策略是如果目標(biāo)類實(shí)現(xiàn)了接口默認(rèn)使用 JDK 動(dòng)態(tài)代理。如果目標(biāo)類沒(méi)有實(shí)現(xiàn)接口使用 CGLIB 代理?？梢酝ㄟ^(guò) proxyTargetClass 屬性強(qiáng)制使用 CGLIB。在 Spring Boot 2.x 中默認(rèn)的代理策略會(huì)根據(jù)目標(biāo)對(duì)象是否實(shí)現(xiàn)接口來(lái)決定。需要特別注意的是使用 CGLIB 代理時(shí)被代理的方法不能是 final 或 private否則無(wú)法被覆寫。5.2 TransactionInterceptor事務(wù)攔截器當(dāng)我們用 EnableTransactionManagement 開啟事務(wù)管理后Spring 會(huì)向容器中注冊(cè)一個(gè) TransactionInterceptor。這個(gè)攔截器實(shí)現(xiàn)了 MethodInterceptor 接口是 AOP 中的「環(huán)繞通知」核心。public class TransactionInterceptor extends TransactionAspectSupport implements MethodInterceptor, Serializable { public Object invoke(MethodInvocation invocation) throws Throwable { Class? targetClass AopUtils.getTargetClass(invocation.getThis()); return invokeWithinTransaction(invocation.getMethod(), targetClass, new CoroutinesInvocationCallback() { public Object proceedWithInvocation() throws Throwable { return invocation.proceed(); } }); } }當(dāng)代理對(duì)象的目標(biāo)方法被調(diào)用時(shí)調(diào)用鏈會(huì)經(jīng)過(guò) TransactionInterceptor.invoke 方法最終進(jìn)入 invokeWithinTransaction 這個(gè)核心方法。這才是 Spring 事務(wù)真正的入口。5.3 事務(wù)屬性解析在 invokeWithinTransaction 執(zhí)行之前需要先獲取目標(biāo)方法的事務(wù)屬性。事務(wù)屬性來(lái)自 Transactional 注解的元數(shù)據(jù)Spring 通過(guò) TransactionAttributeSource 進(jìn)行解析。解析策略遵循「方法級(jí)優(yōu)先于類級(jí)」的原則先查找方法上的 Transactional 注解如果方法上沒(méi)有再查找方法所在類上的 Transactional 注解如果類上也沒(méi)有再向父類或接口查找。解析結(jié)果為 TransactionAttribute 對(duì)象它繼承自 TransactionDefinition包含了傳播行為、隔離級(jí)別、超時(shí)、只讀和回滾規(guī)則等完整信息。六、事務(wù)攔截器核心流程源碼級(jí)剖析這一節(jié)是全文的重點(diǎn)?？炊?invokeWithinTransaction 的流程基本就能回答「Spring 事務(wù)底層是怎么工作的」這個(gè)問(wèn)題。6.1 invokeWithinTransaction 整體流程TransactionAspectSupport.invokeWithinTransaction 是整個(gè)聲明式事務(wù)的執(zhí)行骨架。其簡(jiǎn)化后的邏輯如下protected Object invokeWithinTransaction(Method method, Class? targetClass, InvocationCallback invocation) throws Throwable { TransactionAttributeSource tas getTransactionAttributeSource(); TransactionAttribute txAttr (tas ! null ? tas.getTransactionAttribute(method, targetClass) : null); TransactionManager tm determineTransactionManager(txAttr); PlatformTransactionManager ptm asPlatformTransactionManager(tm); String joinpointIdentification methodIdentification(method, targetClass, txAttr); if (txAttr null || !(ptm instanceof CallbackPreferringPlatformTransactionManager)) { TransactionInfo txInfo createTransactionIfNecessary(ptm, txAttr, joinpointIdentification); Object retVal; try { retVal invocation.proceedWithInvocation(); } catch (Throwable ex) { completeTransactionAfterThrowing(txInfo, ex); throw ex; } finally { cleanupTransactionInfo(txInfo); } commitTransactionAfterReturning(txInfo); return retVal; } // 省略回調(diào)式事務(wù)處理分支 }從這個(gè)骨架中可以提煉出五個(gè)關(guān)鍵步驟獲取事務(wù)屬性通過(guò) TransactionAttributeSource 解析目標(biāo)方法上的 Transactional 配置。確定事務(wù)管理器根據(jù)事務(wù)屬性或默認(rèn)配置找到對(duì)應(yīng)的 PlatformTransactionManager。創(chuàng)建事務(wù)上下文調(diào)用 createTransactionIfNecessary內(nèi)部會(huì)調(diào)用事務(wù)管理器的 getTransaction 方法在必要時(shí)開啟事務(wù)。執(zhí)行目標(biāo)方法調(diào)用 invocation.proceedWithInvocation() 進(jìn)入真正的業(yè)務(wù)邏輯。提交或回滾方法正常返回時(shí)調(diào)用 commitTransactionAfterReturning 提交事務(wù)拋出異常時(shí)調(diào)用 completeTransactionAfterThrowing 判斷是否需要回滾最后在 finally 塊中調(diào)用 cleanupTransactionInfo 清理事務(wù)上下文。6.2 createTransactionIfNecessary事務(wù)上下文的創(chuàng)建createTransactionIfNecessary 是 TransactionAspectSupport 中的一個(gè)關(guān)鍵方法。它不只負(fù)責(zé)「開啟事務(wù)」更重要的是把事務(wù)相關(guān)的三樣?xùn)|西組裝成一個(gè)可追蹤的上下文并綁定到當(dāng)前線程。其核心邏輯可以分為三步調(diào)用事務(wù)管理器的 getTransaction 方法拿到當(dāng)前方法的 TransactionStatus。這一步內(nèi)部會(huì)根據(jù)傳播行為判斷是新建事務(wù)、加入已有事務(wù)還是掛起當(dāng)前事務(wù)。把 PlatformTransactionManager、TransactionAttribute、TransactionStatus 以及當(dāng)前線程上舊的 TransactionInfo 封裝成一個(gè)新的 TransactionInfo 對(duì)象。通過(guò) bindToThread 方法把新 TransactionInfo 綁定到 ThreadLocal 中。這樣后續(xù)任何一層被代理的方法都能通過(guò) currentTransactionInfo() 拿到當(dāng)前事務(wù)上下文異常處理和清理時(shí)也能準(zhǔn)確恢復(fù)上一級(jí)事務(wù)。之所以要保存舊的 TransactionInfo是為了支持嵌套調(diào)用場(chǎng)景內(nèi)層事務(wù)結(jié)束后需要把外層事務(wù)的信息恢復(fù)回線程否則外層方法在提交或回滾時(shí)會(huì)拿到錯(cuò)誤的事務(wù)狀態(tài)。6.3 七種傳播行為在源碼中的實(shí)現(xiàn)傳播行為最終是在 AbstractPlatformTransactionManager.getTransaction 方法中完成的。這個(gè)方法是 Spring 事務(wù)傳播邏輯的核心其簡(jiǎn)化流程如下public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException { Object transaction doGetTransaction(); if (isExistingTransaction(transaction)) { return handleExistingTransaction(definition, transaction, false); } if (definition.getPropagationBehavior() TransactionDefinition.PROPAGATION_MANDATORY) { throw new IllegalTransactionStateException( No existing transaction found for transaction marked with propagation mandatory); } if (definition.getPropagationBehavior() TransactionDefinition.PROPAGATION_REQUIRED || definition.getPropagationBehavior() TransactionDefinition.PROPAGATION_REQUIRES_NEW || definition.getPropagationBehavior() TransactionDefinition.PROPAGATION_NESTED) { SuspendedResourcesHolder suspendedResources suspend(null); try { DefaultTransactionStatus status newTransactionStatus( definition, transaction, true, true, false, null, null); doBegin(transaction, definition); prepareSynchronization(status, definition); return status; } catch (RuntimeException | Error ex) { resume(null, suspendedResources); throw ex; } } boolean newSynchronization (getTransactionSynchronization() SYNCHRONIZATION_ALWAYS); return prepareTransactionStatus(definition, null, true, newSynchronization, false, null, null, null); }面試常問(wèn)的三種傳播行為可以這樣理解REQUIRED如果當(dāng)前沒(méi)有事務(wù)走的是上面「新建事務(wù)」的分支調(diào)用 doBegin 真正開啟物理事務(wù)如果當(dāng)前已經(jīng)有事務(wù)則直接返回已有事務(wù)isNewTransaction 為 false。REQUIRES_NEW在 handleExistingTransaction 中先把當(dāng)前事務(wù)掛起也就是調(diào)用 suspend 把當(dāng)前連接和同步信息保存到 SuspendedResourcesHolder然后重新走 doBegin 開啟一個(gè)全新的物理事務(wù)。內(nèi)層提交后再通過(guò) resume 恢復(fù)外層事務(wù)。NESTED不會(huì)掛起外層事務(wù)而是利用 JDBC Savepoint 建立一個(gè)保存點(diǎn)。內(nèi)層事務(wù)回滾時(shí)只回滾到保存點(diǎn)不會(huì)影響外層事務(wù)但外層事務(wù)如果最終回滾內(nèi)層的修改也會(huì)一起被回滾。這就是它與 REQUIRES_NEW 最本質(zhì)的區(qū)別。需要注意的是NESTED 依賴數(shù)據(jù)庫(kù)對(duì) Savepoint 的支持常見(jiàn)的 MySQL InnoDB 和 PostgreSQL 都支持但需要底層使用 JDBC 事務(wù)管理器而不是 JTA 這類不支持嵌套保存點(diǎn)的事務(wù)管理器。6.4 事務(wù)同步機(jī)制TransactionSynchronizationManager在整個(gè)事務(wù)執(zhí)行過(guò)程中Spring 需要把「當(dāng)前線程正在使用的事務(wù)資源」保存起來(lái)并允許開發(fā)者在事務(wù)的各個(gè)階段注冊(cè)回調(diào)。這件事由 TransactionSynchronizationManager 完成。它的底層是 ThreadLocal主要保存三類信息事務(wù)資源例如 DataSourceTransactionManager 會(huì)把當(dāng)前線程持有的 ConnectionHolder 綁定到 ThreadLocal 上保證同一個(gè)事務(wù)內(nèi)的多次數(shù)據(jù)庫(kù)操作復(fù)用同一個(gè)連接。事務(wù)同步狀態(tài)記錄當(dāng)前事務(wù)是否是新建的、是否有活躍的 synchronization 等。TransactionSynchronization 集合保存開發(fā)者注冊(cè)的回調(diào)在事務(wù)提交、回滾、完成后依次觸發(fā)。常見(jiàn)的應(yīng)用場(chǎng)景是某些操作不適合和數(shù)據(jù)庫(kù)事務(wù)綁定得太死但又希望在事務(wù)提交成功后再執(zhí)行。例如發(fā)送 MQ 消息、刷新本地緩存等。此時(shí)可以注冊(cè) afterCommit 回調(diào)Transactional public void createOrder(Order order) { orderDao.insert(order); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { messageSender.send(orderCreatedEvent(order)); } }); }這樣只有當(dāng)事務(wù)真正提交后消息才會(huì)發(fā)送如果事務(wù)回滾消息不會(huì)發(fā)出避免了「數(shù)據(jù)庫(kù)沒(méi)提交但消息已經(jīng)發(fā)出」的數(shù)據(jù)不一致問(wèn)題。七、Spring 事務(wù)失效的常見(jiàn)場(chǎng)景事務(wù)失效是面試中的高頻追問(wèn)。很多開發(fā)者以為加一個(gè) Transactional 就能一勞永逸但實(shí)際上有不少場(chǎng)景會(huì)導(dǎo)致注解形同虛設(shè)。下面按照出現(xiàn)頻率逐條分析。7.1 自調(diào)用導(dǎo)致事務(wù)失效這是最經(jīng)典的失效場(chǎng)景。聲明式事務(wù)依賴 AOP 代理只有在外部通過(guò)代理對(duì)象調(diào)用方法時(shí)TransactionalInterceptor 才會(huì)介入。如果在一個(gè)類內(nèi)部通過(guò) this 調(diào)用另一個(gè)帶 Transactional 的方法調(diào)用直接發(fā)生在原始對(duì)象上根本不會(huì)經(jīng)過(guò)代理。Service public class UserService { Transactional public void outer() { this.inner(); // 自調(diào)用不會(huì)經(jīng)過(guò)代理inner 的事務(wù)失效 } Transactional(propagation Propagation.REQUIRES_NEW) public void inner() { // 期望開啟獨(dú)立新事務(wù)實(shí)際并不會(huì)生效 } }解決辦法通常有三種把被調(diào)用的方法拆分到另一個(gè) Bean 中通過(guò)注入的 Bean 調(diào)用或者通過(guò) AopContext.currentProxy() 獲取當(dāng)前代理對(duì)象后調(diào)用也可以在 Spring Boot 項(xiàng)目中使用 EnableAspectJAutoProxy(exposeProxy true) 暴露代理對(duì)象。7.2 異常被方法內(nèi)部捕獲事務(wù)是否回滾取決于異常是否繼續(xù)向上拋出到 TransactionInterceptor。如果業(yè)務(wù)方法內(nèi)部通過(guò) try-catch 把異常吞掉攔截器感知不到任何異常自然認(rèn)為方法正常執(zhí)行并提交事務(wù)。Transactional public void transfer(Long fromId, Long toId, BigDecimal amount) { try { accountDao.decrease(fromId, amount); accountDao.increase(toId, amount); } catch (Exception e) { log.error(轉(zhuǎn)賬失敗, e); // 異常被吞掉事務(wù)仍然會(huì)提交 } }如果確實(shí)需要捕獲異?？梢栽?catch 塊中主動(dòng)設(shè)置 currentTransactionStatus().setRollbackOnly()或者重新拋出異常讓攔截器執(zhí)行回滾邏輯。7.3 方法不是 publicSpring 聲明式事務(wù)的底層代理只能攔截到外部可訪問(wèn)的方法。對(duì)于 private、protected 或包級(jí)私有方法JDK 動(dòng)態(tài)代理和 CGLIB 代理都無(wú)法對(duì)它們進(jìn)行有效增強(qiáng)。特別是 private 方法CGLIB 也無(wú)法覆寫事務(wù)必然失效。Service public class OrderService { Transactional private void updateInternal(Long id, Integer status) { // private 方法無(wú)法被代理增強(qiáng)事務(wù)不生效 orderDao.updateStatus(id, status); } }因此需要事務(wù)管理的方法必須聲明為 public并且通過(guò) Spring 容器注入的代理對(duì)象來(lái)調(diào)用。7.4 回滾異常類型不匹配默認(rèn)情況下Spring 只對(duì) RuntimeException 和 Error 進(jìn)行回滾對(duì)受檢異常不會(huì)回滾。如果業(yè)務(wù)方法聲明拋出 IOException 等受檢異常即使異常被攔截器捕獲事務(wù)也只會(huì)提交。Transactional public void importData() throws IOException { fileService.parse(); // 拋出 IOException默認(rèn)不會(huì)回滾 } Transactional(rollbackFor Exception.class) public void importDataWithRollback() throws IOException { fileService.parse(); // 明確指定 Exception 后才會(huì)回滾 }面試或規(guī)范審查中通常建議統(tǒng)一寫成 Transactional(rollbackFor Exception.class)讓所有業(yè)務(wù)異常都能觸發(fā)回滾。7.5 目標(biāo)類被 final 修飾或方法被 final、static 修飾當(dāng)使用 CGLIB 代理時(shí)代理類是目標(biāo)類的子類依賴?yán)^承和覆寫來(lái)增強(qiáng)方法。如果目標(biāo)類被 final 修飾子類無(wú)法繼承如果方法被 final 修飾子類無(wú)法覆寫如果方法是 static它屬于類而不是實(shí)例也不會(huì)走代理。這些情況下事務(wù)都會(huì)失效。7.6 數(shù)據(jù)庫(kù)或存儲(chǔ)引擎不支持事務(wù)事務(wù)最終要落到數(shù)據(jù)庫(kù)層。如果底層數(shù)據(jù)源是 MySQL 的 MyISAM 存儲(chǔ)引擎或者某些不支持事務(wù)的 NoSQL 數(shù)據(jù)源即使 Spring 層面配置完全正確也無(wú)法提供真正的 ACID 保障。需要確認(rèn)存儲(chǔ)引擎為 InnoDB 等支持事務(wù)的引擎并且事務(wù)管理器與數(shù)據(jù)源匹配。八、總結(jié)用一條主線串起 Spring 事務(wù)如果把 Spring 事務(wù)的知識(shí)點(diǎn)壓縮成一條回答主線可以這樣梳理一層抽象Spring 通過(guò) PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 三個(gè)接口統(tǒng)一了不同數(shù)據(jù)訪問(wèn)技術(shù)的事務(wù)操作。一種增強(qiáng)聲明式事務(wù)本質(zhì)上是 AOP通過(guò) JDK 動(dòng)態(tài)代理或 CGLIB 生成代理對(duì)象由 TransactionInterceptor 在執(zhí)行方法前后織入事務(wù)邏輯。一條流程invokeWithinTransaction 負(fù)責(zé)解析事務(wù)屬性、確定事務(wù)管理器、創(chuàng)建事務(wù)上下文、執(zhí)行目標(biāo)方法并根據(jù)異常情況決定提交或回滾。一組行為傳播行為由 AbstractPlatformTransactionManager.getTransaction 實(shí)現(xiàn)其中 REQUIRED、REQUIRES_NEW 和 NESTED 是理解事務(wù)嵌套關(guān)系的關(guān)鍵。一道防線理解自調(diào)用、異常被吞、非 public 方法、回滾類型不匹配等失效場(chǎng)景才能寫出真正可靠的事務(wù)代碼。掌握了這條主線無(wú)論是解釋 Spring 事務(wù)的啟動(dòng)過(guò)程、傳播行為還是分析線上事務(wù)不生效的問(wèn)題都能給出清晰、有層次的回答。建議讀者結(jié)合實(shí)際調(diào)試在 TransactionInterceptor.invoke 和 AbstractPlatformTransactionManager.getTransaction 兩處打上斷點(diǎn)觀察代理調(diào)用鏈和事務(wù)狀態(tài)的流轉(zhuǎn)會(huì)對(duì)本文內(nèi)容有更直觀的理解。