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