：Spring編程式事務(wù)的靈活控制之道)
我個人的經(jīng)驗里很多人對 Spring 事務(wù)的第一印象都是 Transactional 注解寫起來確實方便一行注解把事務(wù)邊界劃得清清楚楚。但它的問題也恰恰藏在方便里——事務(wù)的開啟、提交、回滾全都被框架接管了遇到需要精細控制事務(wù)邊界的場景比如一次業(yè)務(wù)里要分階段提交、要在一個事務(wù)里執(zhí)行多個回調(diào)、要把多個事務(wù)操作組合編排Transactional 就有點使不上勁。這時候就該 TransactionTemplate 登場了。TransactionTemplate 是 Spring 提供的編程式事務(wù)管理模板核心思路是把事務(wù)生命周期管理封裝起來但把控制權(quán)交還給你通過回調(diào)機制把事務(wù)邊界變成一段可執(zhí)行的代碼塊。簡單說它解決的是 Transactional 沒法覆蓋的場景動態(tài)事務(wù)邊界、條件提交、細粒度回滾、事務(wù)內(nèi)多步驟編排、以及更復(fù)雜的嵌套事務(wù)組合。適合在支付回調(diào)、批量任務(wù)、消息消費、異步處理這類需要精細控制事務(wù)行為的業(yè)務(wù)里使用。這篇文章會從原理到實戰(zhàn)拆一遍 TransactionTemplate包括它和聲明式事務(wù)的底層關(guān)系、核心 API 的完整走讀、事務(wù)屬性怎么配、嵌套事務(wù)怎么玩、以及在真正落地的時候會踩哪些坑。雖然是一個比較老的類但我在近期幾個項目里實測下來它依然是處理復(fù)雜事務(wù)場景最可靠的方案之一。1. 先搞清楚一個問題為什么有 Transactional 還不夠1.1 聲明式事務(wù)的管理模型Transactional 是聲明式事務(wù)的入口它的底層是通過 AOP 代理在方法調(diào)用前后織入事務(wù)邏輯?？蚣茉诜椒ㄩ_始時開啟事務(wù)方法正常返回時提交拋出異常時回滾開發(fā)者不需要寫任何事務(wù)代碼。這個模型的核心是方法即事務(wù)邊界——一個 public 方法的執(zhí)行過程對應(yīng)一個完整的事務(wù)生命周期。這個設(shè)計在絕大多數(shù)場景下是合理的。比如一個下單流程從扣庫存到寫訂單表整個方法就是一個事務(wù)要么全部成功要么全部不成功。但在實際項目里業(yè)務(wù)永遠比理想模型復(fù)雜。我遇到過幾個典型的場景聲明式事務(wù)處理起來很別扭第一種事務(wù)邊界需要動態(tài)變化。比如一個批量對賬任務(wù)要遍歷幾千條差異記錄每條記錄獨立的更新操作我希望每條記錄單獨一個事務(wù)某條失敗只回滾它自己不影響整體進度。用 Transactional 放方法上所有記錄共用一個事務(wù)失敗一條全部回滾。拆成多個方法再通過外層調(diào)用來隔離事務(wù)代碼會零散得沒法看。第二種事務(wù)中間需要人為干預(yù)。比如某個網(wǎng)關(guān)同步任務(wù)落庫之后要調(diào)一個外部系統(tǒng)對方返回結(jié)果來決定整個事務(wù)要不要提交。Transactional 只有在方法異常時才回滾沒法在正常流程里主動說等一下我覺得這筆賬不對別提交了。第三種事務(wù)內(nèi)需要多次組合編排。比如一個復(fù)雜的賬戶遷移任務(wù)先查一批數(shù)據(jù)做一部分更新稍作邏輯判斷后再更新另一批數(shù)據(jù)每一步之間的事務(wù)狀態(tài)是連續(xù)的而且中間可能需要根據(jù)狀態(tài)決定是繼續(xù)還是終止。這不是一個簡單的方法內(nèi)順序執(zhí)行而是事務(wù)控制的編排邏輯。這些場景的共同點是事務(wù)邊界經(jīng)常變化或者事務(wù)流程不可固定——聲明式事務(wù)的靜態(tài)邊界限制了大展拳腳的空間而 TransactionTemplate 正是為這類場景設(shè)計的。1.2 TransactionTemplate 的事務(wù)管理模型通過回調(diào)來控制生命周期TransactionTemplate 的事務(wù)模型從根本上就不一樣。它實現(xiàn)的 TransactionOperations 接口核心就一個方法public interface TransactionOperations { T T execute(TransactionCallbackT action) throws TransactionException; }這里的核心思想是模板方法 回調(diào)?？蚣軒湍闾幚硎聞?wù)的開啟、提交、回滾、異常處理這些樣板代碼但你通過 TransactionCallback 接口把業(yè)務(wù)邏輯塞進去public interface TransactionCallbackT { T doInTransaction(TransactionStatus status); }在這個回調(diào)方法里你拿到的 TransactionStatus 對象就是你在事務(wù)里的控制手柄。這個對象可以做幾件事調(diào)用 setRollbackOnly() 主動標(biāo)記事務(wù)回滾即使業(yè)務(wù)代碼沒有拋異常檢查當(dāng)前事務(wù)狀態(tài)比如 isNewTransaction()、isRollbackOnly()了解當(dāng)前事務(wù)處于什么階段在嵌套事務(wù)場景里協(xié)調(diào)不同層級的事務(wù)行為。所以整個模型就變成你定義事務(wù)邊界里要做的所有事回調(diào)框架按圖索驥把事務(wù)生命周期管理好模板。事務(wù)什么時候開始、什么時候提交、什么時候回滾都在這段代碼塊的范圍里而這個范圍是你自己在運行時動態(tài)定義的。1.3 模板與回調(diào)模式讓事務(wù)控制變得靈活可控模板方法模式把這個靈活性的價值發(fā)揮得淋漓盡致。你可以把事務(wù)的開啟、提交、回滾想象成一個流程框架比如烤肉店里客人下單 — 后廚備菜 — 上桌 — 結(jié)賬。模板要解決的是怎么把晚餐流程穩(wěn)定跑完而回調(diào)是今天晚上這一桌客人具體吃什么?？蚣懿糠譄o論誰來吃都是同樣的流程菜品的差異全部封裝在回調(diào)里而你可以隨時決定這道菜不做、換成別的。TransactionTemplate 把事務(wù)相關(guān)的樣板代碼全部收編業(yè)務(wù)代碼只需要專注在這個事務(wù)里做什么剩下的邊界、狀態(tài)管理、資源清理全部由模板保證。最常見的對比是這樣的// 傳統(tǒng)的手動事務(wù)管理 Connection conn dataSource.getConnection(); try { conn.setAutoCommit(false); // 執(zhí)行業(yè)務(wù)代碼... conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); }跟上面的代碼相比下面的寫法要清爽得多而且還能利用 Spring 管理的資源、統(tǒng)一異常處理機制、以及嵌套事務(wù)的協(xié)調(diào)能力transactionTemplate.execute(status - { // 執(zhí)行業(yè)務(wù)代碼... return result; });在真實項目里這種模板化帶來的可維護性收益在業(yè)務(wù)復(fù)雜之后會非常明顯地體現(xiàn)出來。2. 核心 API 與行為機制TransactionTemplate 的底層邏輯2.1 TransactionTemplate 本身如何完成事務(wù)管理TransactionTemplate 是一個類它自己并不直接操作數(shù)據(jù)庫連接而是依賴 Spring 事務(wù)機制里的 PlatformTransactionManager。初始化它的時候你需要給它設(shè)置一個事務(wù)管理器Configuration public class TransactionConfig { Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } Bean public TransactionTemplate transactionTemplate(PlatformTransactionManager transactionManager) { TransactionTemplate template new TransactionTemplate(); template.setTransactionManager(transactionManager); return template; } }DataSourceTransactionManager 是 JDBC 層面的實現(xiàn)負責(zé) DataSource 上連接的獲取、提交、回滾。如果你用的是 JPA需要配置 JpaTransactionManager如果同時操作多個數(shù)據(jù)源用 JtaTransactionManager 或者分布式事務(wù)方案。TransactionTemplate 本身是與具體數(shù)據(jù)源技術(shù)解耦的它只依賴 PlatformTransactionManager 接口約定的事務(wù)生命周期。關(guān)鍵點在于 execute 方法執(zhí)行的完整流程拆開看大概是這樣的根據(jù)設(shè)定的傳播行為事務(wù)管理器決定是新建一個事務(wù)還是加入已有事務(wù)如果新建事務(wù)把數(shù)據(jù)庫連接綁定到當(dāng)前線程自動提交關(guān)閉執(zhí)行回調(diào)里的業(yè)務(wù)代碼拿到返回值如果業(yè)務(wù)代碼拋出運行時異常并且沒有被標(biāo)記為不回滾事務(wù)管理器執(zhí)行回滾如果業(yè)務(wù)代碼正常返回或者拋出的異常被標(biāo)記為提交前不可回滾比如業(yè)務(wù)上主動 setRollbackOnly 后又想繼續(xù)事務(wù)管理器決定提交或回滾最后清理事務(wù)資源、恢復(fù)自動提交狀態(tài)、把連接釋放回連接池。這里有個容易忽略的技術(shù)細節(jié)TransactionTemplate 在事務(wù)管理過程中主要依據(jù)回調(diào)拋出的異常類型來判定是否回滾。默認情況下它是遇到 RuntimeException 和 Error 就回滾遇到受檢異常不回滾。這個默認行為繼承自 Spring 事務(wù)管理的整體設(shè)計——因為受檢異常在方法簽名中顯式聲明通常是為了捕獲后做補償或重試而不是為了回滾。讓我用一個實際場景來解釋這個機制的價值。比如一個銀行轉(zhuǎn)賬接口轉(zhuǎn)出方扣款成功之后轉(zhuǎn)入方入賬失敗正常情況下應(yīng)該整筆回滾。但如果異常已經(jīng)被外層捕獲并轉(zhuǎn)換成了受檢異常Transactional 默認不會觸發(fā)回滾。而用 TransactionTemplate 的話由于你是直接在回調(diào)里控制狀態(tài)可以更明確地指定什么情況必須回滾。看一段更接近真實業(yè)務(wù)的代碼public TransferResult transfer(TransferCommand command) { return transactionTemplate.execute(status - { try { accountService.debit(command.getFromAccount(), command.getAmount()); accountService.credit(command.getToAccount(), command.getAmount()); return new TransferResult(true, success); } catch (AccountNotFoundException e) { status.setRollbackOnly(); return new TransferResult(false, e.getMessage()); } catch (Exception e) { status.setRollbackOnly(); // 如果希望受檢異常也導(dǎo)致回滾需要在這里顯式處理 throw new RuntimeException(e); } }); }這段代碼里catch 到的受檢異常 AccountNotFoundException 本身不會自動觸發(fā)回滾但通過顯式調(diào)用 status.setRollbackOnly()事務(wù)依然被標(biāo)記為回滾同時能返回一個結(jié)構(gòu)化的業(yè)務(wù)結(jié)果而不是把異常直接拋出去讓上層還要做一層異常處理。這就是編程式事務(wù)比較適合做 API 類接口落到 DB 操作的場景的原因——事務(wù)回滾的決定權(quán)和業(yè)務(wù)返回結(jié)構(gòu)是統(tǒng)一的。2.2 事務(wù)傳播行為與 TransactionTemplate 的搭配玩法事務(wù)傳播行為Propagation是 Spring 事務(wù)模型里比較繞的一部分但跟 TransactionTemplate 搭配起來非常自然。TransactionTemplate 可以通過 setPropagationBehavior 來設(shè)定事務(wù)邊界與當(dāng)前存在事務(wù)之間的關(guān)系TransactionTemplate template new TransactionTemplate(txManager); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);常用傳播行為對照傳播行為語義典型場景PROPAGATION_REQUIRED當(dāng)前有事務(wù)則加入無則新建大多數(shù)業(yè)務(wù)默認行為PROPAGATION_REQUIRES_NEW掛起當(dāng)前事務(wù)新建一個獨立事務(wù)日志記錄、審計、操作記錄PROPAGATION_NESTED當(dāng)前有事務(wù)時使用 Savepoint無則新建分段回滾部分失敗只回滾子段PROPAGATION_SUPPORTS當(dāng)前有事務(wù)則加入無則以非事務(wù)方式執(zhí)行只讀查詢、非關(guān)鍵輔助操作PROPAGATION_NOT_SUPPORTED始終以非事務(wù)方式執(zhí)行掛起現(xiàn)有事務(wù)事務(wù)中有非事務(wù)性操作如大文件操作PROPAGATION_MANDATORY必須有現(xiàn)有事務(wù)無則拋異常強約束某些操作必須在事務(wù)內(nèi)PROPAGATION_NEVER絕不能有事務(wù)有則拋異常事務(wù)里不能執(zhí)行的特定操作這里值得展開的是 NESTED它跟 REQUIRES_NEW 經(jīng)常有人混淆。REQUIRES_NEW 的特點是徹底隔離它新建一個完全獨立的事務(wù)跟外部事務(wù)互不影響。外部事務(wù)回滾不影響內(nèi)部事務(wù)已經(jīng)提交的數(shù)據(jù)內(nèi)部事務(wù)回滾也不影響外部事務(wù)待提交的數(shù)據(jù)。這聽起來很省事但代價是物理上開了兩個數(shù)據(jù)庫事務(wù)連接占用、鎖等待、性能消耗都會增加。NESTED 則完全不同它是基于 Savepoint 的嵌套。如果外部事務(wù)存在NESTED 事務(wù)會在當(dāng)前事務(wù)里創(chuàng)建一個 Savepoint內(nèi)部業(yè)務(wù)如果回滾只回滾到 Savepoint 位置外部事務(wù)仍然可以繼續(xù)。這個語義像把事務(wù)切了幾段某一段壞了只重做這一段。它是邏輯上的嵌套而不是另開一個物理事務(wù)。場景差異就很明顯了。比如一個報表任務(wù)先匯總一筆總賬寫到匯總表再寫大量的明細記錄。明細中偶發(fā)一條數(shù)據(jù)格式錯誤我希望只回滾出錯的那段明細不動總賬還要繼續(xù)處理后面幾條用 NESTED 比較合適。但如果是寫審計日志要求不管主流程成不成功日志一定留下來那就得用 REQUIRES_NEW因為日志事務(wù)必須脫離主事務(wù)的生命周期。需要注意的是NESTED 依賴底層數(shù)據(jù)庫的 Savepoint 支持在 MySQL 的 InnoDB、PostgreSQL、Oracle 上都能正常工作但如果你用的數(shù)據(jù)庫不支持 Savepoint比如某些老版本 MyISAM它會在運行時拋異常。所以選 NESTED 之前先確認數(shù)據(jù)庫能力。在 TransactionTemplate 上設(shè)置傳播行為之后配合不同的回調(diào)組合就能很靈活地控制嵌套事務(wù)。比如外層一個 template內(nèi)部某段業(yè)務(wù)又注入另一個配了 REQUIRES_NEW 的 template那這段業(yè)務(wù)會單獨事務(wù)執(zhí)行。2.3 隔離級別、超時與只讀TransactionTemplate 三個容易被忽略的屬性TransactionTemplate 除了傳播行為還可以設(shè)置事務(wù)的隔離級別、超時時間、是否只讀。這幾個屬性在實際項目中經(jīng)常被漏配但其實都很有用。隔離級別事務(wù)隔離級別解決的是并發(fā)下數(shù)據(jù)可見性的問題。TransactionTemplate 支持標(biāo)準(zhǔn)的五個級別DEFAULT使用數(shù)據(jù)庫默認隔離級別MySQL 默認是 REPEATABLE_READREAD_UNCOMMITTED能讀到未提交數(shù)據(jù)可能會臟讀READ_COMMITTED只能讀到已提交數(shù)據(jù)解決臟讀REPEATABLE_READ同一個事務(wù)里多次查詢結(jié)果一致解決不可重復(fù)讀SERIALIZABLE完全串行化解決幻讀但性能影響很大。數(shù)據(jù)庫并發(fā)場景不同選法也不同。比如一個統(tǒng)計報表任務(wù)讀多寫少用 REPEATABLE_READ 就能保證一次事務(wù)里多次查詢看到的快照一致如果要做賬務(wù)核對類操作精度要求高的話就要考慮 SERIALIZABLE但要衡量對并發(fā)性能的影響。在 TransactionTemplate 上設(shè)置隔離級別template.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);超時時間事務(wù)超時是針對事務(wù)內(nèi)所有數(shù)據(jù)庫操作耗時總和的約束。設(shè)置之后如果超過時間限制Spring 會讓事務(wù)回滾并拋出異常。默認超時是 -1表示使用底層數(shù)據(jù)源的默認值或不設(shè)限制。這個屬性在長時間運行的批處理任務(wù)、運營后臺的 Excel 導(dǎo)入里很有用。沒有超時約束時如果數(shù)據(jù)庫鎖等待時間過長事務(wù)會一直占著連接連接池耗盡之后整個應(yīng)用就假死了。設(shè)一個合理的超時時間比如 30 秒就能在事務(wù)卡住的時候快速失敗并釋放連接。template.setTimeout(30); // 單位秒但要注意一點這個超時是通過 JDBC 層的定時檢查來實現(xiàn)的如果在事務(wù)里有一個特別耗時的第三方調(diào)用那是不會被這個超時約束的。它只約束數(shù)據(jù)庫操作自身的時間。只讀事務(wù)把事務(wù)標(biāo)記為只讀可以讓數(shù)據(jù)庫優(yōu)化器做一些查詢路徑上的優(yōu)化在 MySQL 里主要是提示服務(wù)器不產(chǎn)生讀鎖寫日志等開銷同時也是一種語義約束——在只讀事務(wù)里發(fā)生的寫操作通常會在提交階段報錯。在查詢類任務(wù)里把事務(wù)標(biāo)記為只讀配合 REPEATABLE_READ 隔離級別能減少不必要的開銷。比如template.setReadOnly(true);要注意的是如果這個對象還被復(fù)用于寫操作那就不能設(shè)置只讀否則后續(xù)的寫操作會出問題。因此模板如果是被多個業(yè)務(wù)共享的建議針對不同用途配置多個 TransactionTemplate 實例而不是一個模板走到底。2.4 使用 TransactionCallbackWithoutResult 簡化無返回值場景TransactionTemplate.execute 需要返回一個值但很多時候我們只是在事務(wù)里執(zhí)行更新不需要返回任何對象。Spring 提供了一個子接口 TransactionCallbackWithoutResult它把返回值定義為 void執(zhí)行完成之后模板自動提交或者根據(jù)異?；貪L。transactionTemplate.execute(new TransactionCallbackWithoutResult() { Override protected void doInTransactionWithoutResult(TransactionStatus status) { orderDao.updateStatus(orderId, OrderStatus.PAID); accountDao.incrementBalance(userId, amount); } });使用 Lambda 表達式可以更簡潔transactionTemplate.executeWithoutResult(status - { orderDao.updateStatus(orderId, OrderStatus.PAID); accountDao.incrementBalance(userId, amount); });代碼里的 executeWithoutResult 是 TransactionOperations 接口的 default 方法內(nèi)部會把回調(diào)包裝成 TransactionCallback返回 null然后模板統(tǒng)一處理事務(wù)生命周期。這個寫法適合那些通知一下、更新幾個字段、不需要拿返回值的事務(wù)操作可以讓業(yè)務(wù)方法表達出真實意圖——我不關(guān)心返回值只要這段代碼在一個事務(wù)里執(zhí)行。2.5 編程式事務(wù) vs 聲明式事務(wù)怎么選才合適很多團隊會有這種討論到底是用 Transactional 還是 TransactionTemplate我的結(jié)論是不是二選一而是看事務(wù)邊界的可預(yù)測性。事務(wù)邊界固定整個方法就是事務(wù)方法結(jié)束即事務(wù)結(jié)束那就用聲明式 Transactional代碼最簡潔意圖最清晰。事務(wù)邊界動態(tài)需要根據(jù)運行時的數(shù)據(jù)、狀態(tài)或者外部調(diào)用結(jié)果來決定事務(wù)怎么結(jié)束那就用 TransactionTemplate。事務(wù)粒度細分一個業(yè)務(wù)里需要多次獨立事務(wù)、嵌套事務(wù)、分段提交那也適合用 TransactionTemplate。新舊代碼混合老項目里已經(jīng)有聲明式事務(wù)新加的功能又需要更靈活的控制可以在同一個服務(wù)里混用只要互相清楚各自的事務(wù)邊界。我實際看到過一種比較推薦的做法是在 Service 層定義一個注入的 TransactionTemplate用它來完成所有需要編程式事務(wù)控制的方法其他地方保持 Transactional 做透明事務(wù)。兩者職責(zé)分開不會互相干擾。3. 深入事務(wù)狀態(tài)對象TransactionStatus 背后的設(shè)計思想3.1 TransactionStatus 能做什么回調(diào)里拿到的 TransactionStatus 接口定義了幾個關(guān)鍵方法public interface TransactionStatus { boolean isNewTransaction(); boolean hasSavepoint(); void setRollbackOnly(); boolean isRollbackOnly(); void flush(); boolean isCompleted(); }逐個說isNewTransaction()當(dāng)前事務(wù)是否是新建的。如果因為傳播行為加入了外層已有事務(wù)這個方法返回 false。這個判斷在嵌套編排里特別有用——如果你需要一個獨立事務(wù)但發(fā)現(xiàn)自己是在外層事務(wù)里就要考慮調(diào)整傳播行為或者拆分模板。hasSavepoint()當(dāng)前事務(wù)是否保存了 Savepoint。跟 NESTED 傳播行為配合判斷當(dāng)前是否處于嵌套層級。setRollbackOnly()把事務(wù)標(biāo)記為只能回滾不能提交。調(diào)用這個方法之后即使回調(diào)正常結(jié)束事務(wù)在提交階段也會被強制回滾。這是編程式事務(wù)最核心的控制能力。isRollbackOnly()查詢當(dāng)前事務(wù)是否已經(jīng)被標(biāo)記為回滾。flush()強制把當(dāng)前會話中的修改同步到數(shù)據(jù)庫。在 JPA/Hibernate 這類帶持久化上下文的場景下有時候需要提前 flush 以讓后續(xù)查詢看到更新或者讓數(shù)據(jù)庫約束檢查提前觸發(fā)。isCompleted()事務(wù)是否已經(jīng)結(jié)束提交或回滾。3.2 setRollbackOnly 的實際價值setRollbackOnly 在實際業(yè)務(wù)中有兩個關(guān)鍵應(yīng)用場景。場景一是業(yè)務(wù)上判定失敗但代碼沒拋異常。比如在業(yè)務(wù)校驗中某個賬戶已經(jīng)凍結(jié)再往下執(zhí)行沒有意義但你要的是回滾而不必制造一個異常transactionTemplate.executeWithoutResult(status - { deductionService.deductPoints(userId, points); if (memberService.isFrozen(userId)) { status.setRollbackOnly(); return; } // 繼續(xù)其他正常業(yè)務(wù)... });這里如果直接 throw new RuntimeException會導(dǎo)致業(yè)務(wù)異常堆棧被包裝成框架異常調(diào)用方要解析這一層而 setRollbackOnly 直接回滾事務(wù)同時代碼還能正常返回業(yè)務(wù)狀態(tài)可以繼續(xù)處理。場景二是外部調(diào)用成功后本事務(wù)主動放棄。比如支付回調(diào)本地事務(wù)先更新訂單狀態(tài)再調(diào)用外部支付系統(tǒng)確認如果外部確認結(jié)果要求本地事務(wù)取消則 setRollbackOnly 回滾本地變更。需要特別注意的是一旦調(diào)用了 setRollbackOnly這個事務(wù)就被打上了回滾標(biāo)簽。在同一個事務(wù)里即使你后續(xù)再執(zhí)行其他操作也無法撤銷這個標(biāo)記。這也是一個經(jīng)典的踩坑點——在一個共享事務(wù)里某個組件標(biāo)記了回滾但外層業(yè)務(wù)還繼續(xù)執(zhí)行并且最終想提交結(jié)果整個事務(wù)還是回滾了。3.3 flush() 在 ORM 場景中的應(yīng)用如果你在 TransactionTemplate 里使用 JPA那么 flush() 的使用頻率會比 JDBC 高得多。原因是 JPA 是一種延遲寫的模型實體更新之后不會立刻刷到數(shù)據(jù)庫而是攢到事務(wù)提交前統(tǒng)一 flush。如果業(yè)務(wù)邏輯緊接著要查詢剛剛更新的數(shù)據(jù)或者要讓數(shù)據(jù)庫唯一約束提前生效就需要主動 flush。舉個例子事務(wù)里先給用戶分配一個優(yōu)惠碼然后立刻判斷這個優(yōu)惠碼是否已被使用過。如果依賴數(shù)據(jù)庫的唯一索引來校驗而 flush 發(fā)生在事務(wù)提交時那么第二次查詢可能還沒把第一次的寫入刷進去導(dǎo)致查不到數(shù)據(jù)。顯式調(diào)用 status.flush() 會把當(dāng)前的實體變化同步到數(shù)據(jù)庫讓后續(xù)邏輯能看到最新狀態(tài)同時唯一索引沖突也能提前暴露。這個知識點在先寫后查同一事務(wù)的場景里很容易救你一命。4. 實操篇一個事務(wù)模板搞定復(fù)雜業(yè)務(wù)場景4.1 方法一標(biāo)準(zhǔn)模板配置與復(fù)用在實際項目里強烈建議不要每次 new 一個 TransactionTemplate而是把它作為 Spring Bean 注入使用。原因有兩個一個實例配置一次事務(wù)屬性后續(xù)復(fù)用省去重復(fù)配置另外 Spring 容器管理生命周期也更符合統(tǒng)一配置原則。最典型的配置方式Component public class TransactionTemplates { Bean public TransactionTemplate requiredTemplate(PlatformTransactionManager tm) { TransactionTemplate template new TransactionTemplate(tm); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); template.setTimeout(30); return template; } Bean public TransactionTemplate requiresNewTemplate(PlatformTransactionManager tm) { TransactionTemplate template new TransactionTemplate(tm); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); return template; } }這樣你在 Service 里就能按場景選擇合適的模板Service public class OrderService { private final TransactionTemplate requiredTemplate; private final TransactionTemplate requiresNewTemplate; public void createOrder(OrderCommand command) { requiredTemplate.executeWithoutResult(status - { orderDao.insert(command.toOrder()); // 給用戶加積分 requiresNewTemplate.executeWithoutResult(innerStatus - { pointsDao.increment(command.getUserId(), command.getPoints()); }); }); } }這段代碼的含義是創(chuàng)建訂單和加積分在同一個事務(wù) REQUIRED 里但給用戶加積分這個動作又單獨做了一個 REQUIRES_NEW 事務(wù)。即使創(chuàng)建訂單的事務(wù)最終回滾積分增加的記錄也已經(jīng)被獨立提交了這在某些場景下恰恰是業(yè)務(wù)需要的比如只要用戶點擊了下單按鈕積分就要加不管訂單最終有沒有落庫成功。當(dāng)然真實業(yè)務(wù)要不要這么做要看產(chǎn)品定義但 TransactionTemplate 的組合使用方式就是這么靈活。4.2 方法二在一個事務(wù)里分階段執(zhí)行業(yè)務(wù)并決定提交還是回滾很多系統(tǒng)對接場景需要本地更新 遠程確認的組合。比如支付回調(diào)處理過程中本地先更新訂單狀態(tài)、記賬然后調(diào)用遠程接口做風(fēng)控確認確認結(jié)果決定事務(wù)走向。用 TransactionTemplate 實現(xiàn)public PaymentResult handleCallback(PaymentCallback callback) { return transactionTemplate.execute(status - { // 階段一本地數(shù)據(jù)更新 orderService.markPaid(callback.getOrderId()); paymentLogService.record(callback); // 階段二遠程確認 RiskCheckResult riskResult riskClient.check(callback); if (!riskResult.isPass()) { status.setRollbackOnly(); return PaymentResult.reject(riskResult.getReason()); } // 階段三本地數(shù)據(jù)二次更新 orderService.confirmPaid(callback.getOrderId()); return PaymentResult.accept(); }); }這里有幾個好處事務(wù)邊界覆蓋整個本地數(shù)據(jù)更新鏈路任何一步發(fā)現(xiàn)需要終止setRollbackOnly 就能讓全部本地變更回滾返回結(jié)果是一個結(jié)構(gòu)化的業(yè)務(wù)對象不用依賴異常傳播來表達失敗語義遠程調(diào)用的時間被包含在事務(wù)生命周期里如果超時可以設(shè)置整體事務(wù)超時兜底在回調(diào)里可以自由編排階段順序、跳過某些步驟代碼直觀。4.3 方法三批量任務(wù)中實現(xiàn)行級事務(wù)與隔離批量處理是 TransactionTemplate 比較能發(fā)揮優(yōu)勢的場景。比如定時任務(wù)要遍歷一個比較大的數(shù)據(jù)集合幾萬條每條記錄執(zhí)行獨立的更新 校驗 記錄流程。要求是單條失敗不影響后續(xù)記錄且每條記錄的事務(wù)互不干擾。實現(xiàn)方式有兩種思路取決于對事務(wù)邊界的理解。第一種每一條記錄一個獨立事務(wù)for (Record record : records) { try { transactionTemplate.executeWithoutResult(status - { validate(record); update(record); audit(record); }); } catch (Exception e) { log.error(記錄處理失敗, recordId{}, record.getId(), e); // 單條失敗不影響循環(huán)繼續(xù) } }這里的 TransactionTemplate 配 PROPAGATION_REQUIRED每次循環(huán)開啟一個新事務(wù)處理完立即提交。某條失敗異常被 catch 捕獲本事務(wù)回滾其他記錄照常處理。這個模式在數(shù)據(jù)庫鎖競爭不大、單條操作耗時不長的任務(wù)中很高效。第二種如果單條處理邏輯內(nèi)部還分多個階段可以用 NESTED 做局部回滾transactionTemplate.executeWithoutResult(status - { // 匯總更新 summaryDao.updateSummary(records); // 分階段處理細分回滾段 try { transactionTemplate.executeWithoutResult(innerStatus - { for (Record record : records) { detailDao.insert(record); } }); } catch (Exception e) { // 明細插入失敗回滾到 Savepoint但匯總結(jié)論還在 log.error(明細處理失敗但匯總已更新, e); } });這里外層事務(wù)控制總體內(nèi)層用 NESTED 細分回滾讓明細失敗但匯總保留成為可能。實際項目中具體怎么設(shè)計取決于業(yè)務(wù)要求的隔離粒度。4.4 方法四事務(wù)模板與 CompletableFuture 異步任務(wù)的組合TransactionTemplate 在異步場景里也有獨特的價值。Spring 聲明式事務(wù)是綁定在線程上的異步線程里如果用 Transactional 會面臨事務(wù)上下文丟失的問題。而 TransactionTemplate 因為把事務(wù)邊界的控制權(quán)交給你可以在異步任務(wù)內(nèi)部開啟獨立事務(wù)天然規(guī)避了這個坑。比如某個任務(wù)需要先同步做一段預(yù)處理再異步插入大量明細public void processAsync(ListData batchData) { transactionTemplate.executeWithoutResult(status - { prepareMainData(batchData); }); CompletableFuture.runAsync(() - { transactionTemplate.executeWithoutResult(status - { for (Data data : batchData) { detailDao.save(data); } }); }).exceptionally(ex - { log.error(異步寫明細失敗, ex); return null; }); }這里同步部分先提交一個事務(wù)異步部分另起一個事務(wù)兩個事務(wù)互不干擾異步里如果失敗也不影響主流程已提交的數(shù)據(jù)。這正是 TransactionTemplate 在異步場景里相對聲明式事務(wù)的優(yōu)勢體現(xiàn)。當(dāng)然異步場景下真正需要注意的是分布式事務(wù)的一致性方案比如本地消息表 定時任務(wù)、事務(wù)消息等。但只要你把事務(wù)邊界定義清楚這些方案里的本地事務(wù)部分TransactionTemplate 都可以承擔(dān)。4.5 TransactionTemplate 和 Transactional 的混合使用技巧可能有人會問一個 Service 里能不能同時用 TransactionTemplate 和 Transactional可以的Spring 的事務(wù)管理是雙通道的只要事務(wù)管理器一致它們就共享同一個事務(wù)設(shè)施。一個常見的設(shè)計是對外暴露的入口方法用 Transactional 聲明統(tǒng)一事務(wù)內(nèi)部某些特殊步驟用 TransactionTemplate 做獨立的子事務(wù)REQUIRES_NEW 或 NESTED。示例如下Transactional public void processOrder(Order order) { // 主事務(wù)處理 orderDao.updateStatus(order.getId(), OrderStatus.PROCESSING); // 子事務(wù)記錄操作日志即使主事務(wù)回滾也保留 auditTemplate.executeWithoutResult(status - { logDao.insert(processOrder, order.getId()); }); }這里 processOrder 用 Transactional 劃定了主事務(wù)邊界而審計日志使用獨立的 REQUIRES_NEW 事務(wù)。這樣即使主流程后續(xù)拋異常導(dǎo)致回滾審計日志也已經(jīng)落庫了可以追溯這個訂單確實被嘗試處理過。混合使用的關(guān)鍵約束是參與同一個物理事務(wù)的代碼必須保持一致的傳播行為認知不能出現(xiàn)一邊期待獨立回滾、一邊又共享事務(wù)狀態(tài)的邏輯混亂。因此混合使用之前最好寫清楚每個方法的事務(wù)語義注釋。5. 踩坑記錄與排查實錄TransactionTemplate 使用中的高發(fā)問題5.1 坑一事務(wù)管理器配置錯了導(dǎo)致事務(wù)根本沒生效TransactionTemplate 最典型的配置錯誤是給它塞了一個跟實際數(shù)據(jù)源不匹配的事務(wù)管理器。比如項目里用了 JPA卻從容器里拿了一個 DataSourceTransactionManager或者配置了兩個數(shù)據(jù)源但只給事務(wù)管理器設(shè)了一個。排查思路出現(xiàn)明明在事務(wù)里執(zhí)行的代碼異常了卻沒回滾的詭異現(xiàn)象第一步去看 TransactionTemplate 的 transactionManager 到底是什么類型。如果事務(wù)管理器跟數(shù)據(jù)源對不上整個事務(wù)就是空轉(zhuǎn)狀態(tài)——業(yè)務(wù)代碼執(zhí)行了但根本沒有物理事務(wù)來保護它。另外如果多個數(shù)據(jù)源配置了多個事務(wù)管理器那么 Spring 容器會有多個 PlatformTransactionManager Bean注入 TransactionTemplate 時要通過 Qualifier 明確指定Bean public TransactionTemplate orderTemplate(Qualifier(orderTransactionManager) PlatformTransactionManager tm) { return new TransactionTemplate(tm); }這個錯誤隱蔽性比較強因為代碼不會編譯報錯日志也看不出明顯異常。5.2 坑二事務(wù)鎖與連接池耗盡問題長事務(wù)占用連接是最常見的高危場景。TransactionTemplate 的 execute 從進入回調(diào)到方法返回整個期間都持有一個數(shù)據(jù)庫連接。如果回調(diào)里有個慢查詢或者同步調(diào)用了外部接口事務(wù)就一直掛著連接遲遲不歸還。這種情況在并發(fā)上來之后容易出事連接池默認 10 個連接10 個請求都在事務(wù)里等外部接口后續(xù)請求全部阻塞在獲取連接的環(huán)節(jié)系統(tǒng)假死。解決經(jīng)驗回調(diào)里盡量別做耗時操作外部 HTTP 調(diào)用建議放在事務(wù)外配置合理的超時時間至少讓連接不無限等待監(jiān)控連接池使用率超過閾值要報警。如果確實需要在事務(wù)里做外部調(diào)用某些強一致場景無法避免至少要給外部調(diào)用設(shè)置單獨的短超時別讓一個事務(wù)等外部接口 60 秒。5.3 坑三setRollbackOnly 之后還想提交事務(wù)已經(jīng)回滾這個坑的迷惑性很強。比如某個嵌套事務(wù)里內(nèi)層事務(wù)調(diào)用了 setRollbackOnly但外層邏輯覺得不影響大局繼續(xù)提交。結(jié)果是整個事務(wù)在提交階段被強制回滾代碼上沒有拋出任何異?？雌饋砭拖袷裁炊紱]發(fā)生但數(shù)據(jù)沒落庫。我碰到過一次經(jīng)典的案例一個交易系統(tǒng)主流程調(diào)用了內(nèi)部記賬模塊記賬模塊在某個分支里 setRollbackOnly 后返回了一個正常對象主流程繼續(xù)執(zhí)行其他步驟最終想提交整個事務(wù)結(jié)果數(shù)據(jù)完全沒有寫入。當(dāng)時排查了很久才發(fā)現(xiàn)是內(nèi)部模塊的 rollbackOnly 標(biāo)記傳遞到了整個物理事務(wù)上。這個問題的根源是在 REQUIRED 傳播行為下內(nèi)層事務(wù)和外層事務(wù)共享同一個物理事務(wù)setRollbackOnly 修改的是整個物理事務(wù)的狀態(tài)。解決辦法如果內(nèi)層業(yè)務(wù)對標(biāo)記回滾有獨立語義應(yīng)該配置 REQUIRES_NEW 讓內(nèi)層單獨開物理事務(wù)或者在外層調(diào)用前檢查 status.isRollbackOnly()提前中斷別讓后續(xù)代碼繼續(xù)空跑。5.4 坑四受檢異常默認不回滾數(shù)據(jù)部分成功回想一下TransactionTemplate 的默認回滾策略跟 Spring 其他事務(wù)策略一致遇到 RuntimeException 和 Error 回滾受檢異常默認不回滾。這就會導(dǎo)致一個隱蔽問題如果你的業(yè)務(wù)代碼 catch 了一個受檢異常并向上層拋出比如轉(zhuǎn)換為自定義業(yè)務(wù)異常事務(wù)不會回滾但之前的數(shù)據(jù)改動已經(jīng)留在數(shù)據(jù)庫里了看起來像部分數(shù)據(jù)更新成功。例如transactionTemplate.executeWithoutResult(status - { accountDao.deduct(userId, amount); transferDao.record(transfer); throw new BusinessException(賬戶凍結(jié)); // BusinessException extends Exception });BusinessException 如果是受檢異常上面的代碼不會觸發(fā)回滾扣款和記錄都已經(jīng)提交了。這就需要顯式處理要么讓 BusinessException 繼承 RuntimeException要么在 catch 中調(diào)用 status.setRollbackOnly()。排查方法如果發(fā)現(xiàn)數(shù)據(jù)異常但沒拋錯先從哪些異常是不會觸發(fā)回滾的查起確認異常體系是不是用了受檢異常。5.5 坑五事務(wù)內(nèi)操作跨線程事務(wù)上下文丟失Spring 的事務(wù)核心是把連接綁定在 ThreadLocal 上的所以它天然是線程綁定的。如果你在回調(diào)里使用 new Thread 或線程池異步執(zhí)行數(shù)據(jù)庫操作這些異步線程不持有當(dāng)前線程的事務(wù)上下文它們跑的 SQL 會走獨立連接、獨立提交完全不受事務(wù)控制。典型錯誤transactionTemplate.executeWithoutResult(status - { orderDao.update(order); new Thread(() - logDao.save(log)).start(); // 這個 logDao.save 不在當(dāng)前事務(wù)里 });如果需要異步操作參與當(dāng)前事務(wù)必須想辦法把事務(wù)上下文傳遞過去比如 TransactionSynchronizationManager 的機制但它也只適用于少數(shù)可控線程池場景實現(xiàn)成本高。更推薦的做法是讓異步任務(wù)用自己的事務(wù)模板明確它的事務(wù)邊界不要指望它繼承外層事務(wù)。5.6 坑六事務(wù)模板被多個業(yè)務(wù)共用時屬性互相污染TransactionTemplate 實例內(nèi)部保存了事務(wù)屬性傳播行為、超時、只讀等如果有多個業(yè)務(wù)流程共用同一個實例其中一個業(yè)務(wù)修改了屬性雖然少但可能有人會 set 一下其他業(yè)務(wù)也會受影響。更常見的是你設(shè)置了 readOnly后續(xù)的寫操作全被拒了或者設(shè)置了超時 5 秒一個跑批業(yè)務(wù)進來直接超時。最佳實踐是針對不同場景拆分模板每個模板的配置固定不要運行時改動屬性。如果需要動態(tài)改變傳播行為可以 new 一個新的 TransactionTemplate 實例而不是去改共享實例。5.7 常見問題速查表問題表現(xiàn)可能原因排查/解決思路事務(wù)沒回滾數(shù)據(jù)成功寫入事務(wù)管理器類型不匹配檢查注入的事務(wù)管理器和實際數(shù)據(jù)源事務(wù)回滾了但整體沒報錯內(nèi)部模塊 setRollbackOnly 傳播檢查嵌套調(diào)用的 propagate 配置連接池耗盡系統(tǒng)卡住長事務(wù) 慢SQL / 外部調(diào)用縮短事務(wù)內(nèi)耗時配置合理超時受檢異常沒觸發(fā)回滾默認回滾策略不含受檢異常改為 RuntimeException 或顯式 setRollbackOnly異步線程數(shù)據(jù)不在事務(wù)里事務(wù)上下文是線程綁定的異步任務(wù)用單獨模板開事務(wù)模板屬性互相影響多個業(yè)務(wù)共用同一實例按場景拆分模板運行時不改屬性6. 工具選型與設(shè)計建議讓 TransactionTemplate 發(fā)揮最大價值6.1 事務(wù)管理器的選擇與配置建議DataSourceTransactionManager 是 JDBC 場景的標(biāo)準(zhǔn)選擇在絕大部分單體項目中就夠用了。JpaTransactionManager 適合 JPA/Hibernate 項目它會同時管理 JPA 的 EntityManager 和底層 JDBC 連接保證兩者在同一個事務(wù)里協(xié)同。如果項目里同時用 MyBatis 和 JPA那可能需要兩個數(shù)據(jù)源管理器按用戶維度切分或者用 JtaTransactionManager 處理跨資源事務(wù)但后者復(fù)雜度更高。配置建議單一數(shù)據(jù)源 MyBatis/JDBCDataSourceTransactionManager單一數(shù)據(jù)源 JPA/HibernateJpaTransactionManager多數(shù)據(jù)源按數(shù)據(jù)源各配一個事務(wù)管理器業(yè)務(wù)上用路由或分布式事務(wù)方案微服務(wù)跨服務(wù)不建議直接用 TransactionTemplate 去控制分布式事務(wù)而是用 TCC、事務(wù)消息、SAGA 等專門方案TransactionTemplate 在其中的本地事務(wù)部分仍然可用。6.2 事務(wù)模板實例的生命周期管理在一個 Spring 項目中TransactionTemplate 實例可以交給容器管理作為單例 Bean 使用。它本身是無狀態(tài)的屬性在構(gòu)造時設(shè)定運行時不修改線程安全可以被多個線程并發(fā)調(diào)用。這個特性讓它可以放心地注入到任意 Service 里。如果你的服務(wù)需要不同的事務(wù)屬性組合創(chuàng)建多個 Bean 是合理的方式命名上建議語義清晰比如 orderRequiredTemplate、auditRequiresNewTemplate、readOnlyTemplate 等。這樣代碼里一看名字就知道這個模板的語義比直接在調(diào)用處 new 要清晰得多。6.3 與聲明式事務(wù)的邊界設(shè)計原則在同一個項目里混用 TransactionTemplate 和 Transactional需要的人為約束是明確每種事務(wù)方式的管轄邊界。我的建議是三層劃分入口層Controller / API / 定時任務(wù)入口用 Transactional 做整體事務(wù)邊界一個入口對應(yīng)一個業(yè)務(wù)完整流程服務(wù)層Service內(nèi)部特殊環(huán)節(jié)用 TransactionTemplate 控制局部事務(wù)數(shù)據(jù)層Dao / Repository保持無事務(wù)語義事務(wù)完全由上層決定。這條邊界規(guī)則能有效避免到處開事務(wù)的混亂。而且一旦團隊形成這種習(xí)慣代碼評審時看到某個 Service 方法里又出現(xiàn) Transactional 又要特別注意嵌套邊界就能快速判斷是否合理。6.4 測試與調(diào)試工具如何驗證事務(wù)行為真的符合預(yù)期TransactionTemplate 寫完之后測試驗證是必要的。我用過的幾個比較實用的調(diào)試手段在回調(diào)里故意拋一個 RuntimeException然后斷言數(shù)據(jù)庫數(shù)據(jù)沒有變化驗證回滾路徑在回調(diào)里調(diào)用 setRollbackOnly 后正常返回斷言數(shù)據(jù)沒有落庫驗證邏輯回滾路徑配置一個極短超時觀察超時之后事務(wù)狀態(tài)是否被正確清理用日志輸出當(dāng)前線程的事務(wù)狀態(tài)TransactionSynchronizationManager.isActualTransactionActive()、isCurrentTransactionReadOnly() 可以快速確認當(dāng)前是否真的在一個物理事務(wù)里。這些測試不需要復(fù)雜的框架寫在集成測試里就能早一點發(fā)現(xiàn)問題尤其是那些沒有異常但數(shù)據(jù)沒落庫的隱蔽坑靠這個能提前暴露。7. 最后再分享一點個人經(jīng)驗坦率地說TransactionTemplate 并不是一個炫技的技術(shù)點它的價值在于讓事務(wù)控制回歸到開發(fā)者手里。如果你所在的團隊經(jīng)常被 Transactional 的邊界問題困擾、批量任務(wù)經(jīng)常因一條臟數(shù)據(jù)拖垮整個事務(wù)、異步場景里事務(wù)上下文總是丟來丟去那么花時間把 TransactionTemplate 用熟回報率會非常高。我個人在項目中偏向一套固定的寫法事務(wù)模板全部由 Spring 容器管理并按業(yè)務(wù)命名回調(diào)方法命名以 doXxxInTransaction 開頭異常處理盡量在回調(diào)內(nèi)部消化并返回業(yè)務(wù)結(jié)果實在要拋出異常就顯式 setRollbackOnly 或者繼承 RuntimeException。這套規(guī)則一旦跑習(xí)慣事務(wù)相關(guān)的代碼不僅穩(wěn)定而且一年后回來翻代碼還能一眼看明白當(dāng)初為什么要這么寫。最后再提一個小技巧如果團隊里有人總是分不清一個事務(wù)到底是提交了還是回滾了可以在回調(diào)末尾打印一下 TransactionSynchronizationManager.getCurrentTransactionName() 和當(dāng)前事務(wù)的 rollbackOnly 狀態(tài)。這兩行日志在很多疑難問題上會節(jié)省大量排查時間。 TransactionTemplate實戰(zhàn)：Spring編程式事務(wù)的靈活控制之道
我個人的經(jīng)驗里很多人對 Spring 事務(wù)的第一印象都是 Transactional 注解寫起來確實方便一行注解把事務(wù)邊界劃得清清楚楚。但它的問題也恰恰藏在方便里——事務(wù)的開啟、提交、回滾全都被框架接管了遇到需要精細控制事務(wù)邊界的場景比如一次業(yè)務(wù)里要分階段提交、要在一個事務(wù)里執(zhí)行多個回調(diào)、要把多個事務(wù)操作組合編排Transactional 就有點使不上勁。這時候就該 TransactionTemplate 登場了。TransactionTemplate 是 Spring 提供的編程式事務(wù)管理模板核心思路是把事務(wù)生命周期管理封裝起來但把控制權(quán)交還給你通過回調(diào)機制把事務(wù)邊界變成一段可執(zhí)行的代碼塊。簡單說它解決的是 Transactional 沒法覆蓋的場景動態(tài)事務(wù)邊界、條件提交、細粒度回滾、事務(wù)內(nèi)多步驟編排、以及更復(fù)雜的嵌套事務(wù)組合。適合在支付回調(diào)、批量任務(wù)、消息消費、異步處理這類需要精細控制事務(wù)行為的業(yè)務(wù)里使用。這篇文章會從原理到實戰(zhàn)拆一遍 TransactionTemplate包括它和聲明式事務(wù)的底層關(guān)系、核心 API 的完整走讀、事務(wù)屬性怎么配、嵌套事務(wù)怎么玩、以及在真正落地的時候會踩哪些坑。雖然是一個比較老的類但我在近期幾個項目里實測下來它依然是處理復(fù)雜事務(wù)場景最可靠的方案之一。1. 先搞清楚一個問題為什么有 Transactional 還不夠1.1 聲明式事務(wù)的管理模型Transactional 是聲明式事務(wù)的入口它的底層是通過 AOP 代理在方法調(diào)用前后織入事務(wù)邏輯?？蚣茉诜椒ㄩ_始時開啟事務(wù)方法正常返回時提交拋出異常時回滾開發(fā)者不需要寫任何事務(wù)代碼。這個模型的核心是方法即事務(wù)邊界——一個 public 方法的執(zhí)行過程對應(yīng)一個完整的事務(wù)生命周期。這個設(shè)計在絕大多數(shù)場景下是合理的。比如一個下單流程從扣庫存到寫訂單表整個方法就是一個事務(wù)要么全部成功要么全部不成功。但在實際項目里業(yè)務(wù)永遠比理想模型復(fù)雜。我遇到過幾個典型的場景聲明式事務(wù)處理起來很別扭第一種事務(wù)邊界需要動態(tài)變化。比如一個批量對賬任務(wù)要遍歷幾千條差異記錄每條記錄獨立的更新操作我希望每條記錄單獨一個事務(wù)某條失敗只回滾它自己不影響整體進度。用 Transactional 放方法上所有記錄共用一個事務(wù)失敗一條全部回滾。拆成多個方法再通過外層調(diào)用來隔離事務(wù)代碼會零散得沒法看。第二種事務(wù)中間需要人為干預(yù)。比如某個網(wǎng)關(guān)同步任務(wù)落庫之后要調(diào)一個外部系統(tǒng)對方返回結(jié)果來決定整個事務(wù)要不要提交。Transactional 只有在方法異常時才回滾沒法在正常流程里主動說等一下我覺得這筆賬不對別提交了。第三種事務(wù)內(nèi)需要多次組合編排。比如一個復(fù)雜的賬戶遷移任務(wù)先查一批數(shù)據(jù)做一部分更新稍作邏輯判斷后再更新另一批數(shù)據(jù)每一步之間的事務(wù)狀態(tài)是連續(xù)的而且中間可能需要根據(jù)狀態(tài)決定是繼續(xù)還是終止。這不是一個簡單的方法內(nèi)順序執(zhí)行而是事務(wù)控制的編排邏輯。這些場景的共同點是事務(wù)邊界經(jīng)常變化或者事務(wù)流程不可固定——聲明式事務(wù)的靜態(tài)邊界限制了大展拳腳的空間而 TransactionTemplate 正是為這類場景設(shè)計的。1.2 TransactionTemplate 的事務(wù)管理模型通過回調(diào)來控制生命周期TransactionTemplate 的事務(wù)模型從根本上就不一樣。它實現(xiàn)的 TransactionOperations 接口核心就一個方法public interface TransactionOperations { T T execute(TransactionCallbackT action) throws TransactionException; }這里的核心思想是模板方法 回調(diào)?？蚣軒湍闾幚硎聞?wù)的開啟、提交、回滾、異常處理這些樣板代碼但你通過 TransactionCallback 接口把業(yè)務(wù)邏輯塞進去public interface TransactionCallbackT { T doInTransaction(TransactionStatus status); }在這個回調(diào)方法里你拿到的 TransactionStatus 對象就是你在事務(wù)里的控制手柄。這個對象可以做幾件事調(diào)用 setRollbackOnly() 主動標(biāo)記事務(wù)回滾即使業(yè)務(wù)代碼沒有拋異常檢查當(dāng)前事務(wù)狀態(tài)比如 isNewTransaction()、isRollbackOnly()了解當(dāng)前事務(wù)處于什么階段在嵌套事務(wù)場景里協(xié)調(diào)不同層級的事務(wù)行為。所以整個模型就變成你定義事務(wù)邊界里要做的所有事回調(diào)框架按圖索驥把事務(wù)生命周期管理好模板。事務(wù)什么時候開始、什么時候提交、什么時候回滾都在這段代碼塊的范圍里而這個范圍是你自己在運行時動態(tài)定義的。1.3 模板與回調(diào)模式讓事務(wù)控制變得靈活可控模板方法模式把這個靈活性的價值發(fā)揮得淋漓盡致。你可以把事務(wù)的開啟、提交、回滾想象成一個流程框架比如烤肉店里客人下單 — 后廚備菜 — 上桌 — 結(jié)賬。模板要解決的是怎么把晚餐流程穩(wěn)定跑完而回調(diào)是今天晚上這一桌客人具體吃什么?？蚣懿糠譄o論誰來吃都是同樣的流程菜品的差異全部封裝在回調(diào)里而你可以隨時決定這道菜不做、換成別的。TransactionTemplate 把事務(wù)相關(guān)的樣板代碼全部收編業(yè)務(wù)代碼只需要專注在這個事務(wù)里做什么剩下的邊界、狀態(tài)管理、資源清理全部由模板保證。最常見的對比是這樣的// 傳統(tǒng)的手動事務(wù)管理 Connection conn dataSource.getConnection(); try { conn.setAutoCommit(false); // 執(zhí)行業(yè)務(wù)代碼... conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); }跟上面的代碼相比下面的寫法要清爽得多而且還能利用 Spring 管理的資源、統(tǒng)一異常處理機制、以及嵌套事務(wù)的協(xié)調(diào)能力transactionTemplate.execute(status - { // 執(zhí)行業(yè)務(wù)代碼... return result; });在真實項目里這種模板化帶來的可維護性收益在業(yè)務(wù)復(fù)雜之后會非常明顯地體現(xiàn)出來。2. 核心 API 與行為機制TransactionTemplate 的底層邏輯2.1 TransactionTemplate 本身如何完成事務(wù)管理TransactionTemplate 是一個類它自己并不直接操作數(shù)據(jù)庫連接而是依賴 Spring 事務(wù)機制里的 PlatformTransactionManager。初始化它的時候你需要給它設(shè)置一個事務(wù)管理器Configuration public class TransactionConfig { Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } Bean public TransactionTemplate transactionTemplate(PlatformTransactionManager transactionManager) { TransactionTemplate template new TransactionTemplate(); template.setTransactionManager(transactionManager); return template; } }DataSourceTransactionManager 是 JDBC 層面的實現(xiàn)負責(zé) DataSource 上連接的獲取、提交、回滾。如果你用的是 JPA需要配置 JpaTransactionManager如果同時操作多個數(shù)據(jù)源用 JtaTransactionManager 或者分布式事務(wù)方案。TransactionTemplate 本身是與具體數(shù)據(jù)源技術(shù)解耦的它只依賴 PlatformTransactionManager 接口約定的事務(wù)生命周期。關(guān)鍵點在于 execute 方法執(zhí)行的完整流程拆開看大概是這樣的根據(jù)設(shè)定的傳播行為事務(wù)管理器決定是新建一個事務(wù)還是加入已有事務(wù)如果新建事務(wù)把數(shù)據(jù)庫連接綁定到當(dāng)前線程自動提交關(guān)閉執(zhí)行回調(diào)里的業(yè)務(wù)代碼拿到返回值如果業(yè)務(wù)代碼拋出運行時異常并且沒有被標(biāo)記為不回滾事務(wù)管理器執(zhí)行回滾如果業(yè)務(wù)代碼正常返回或者拋出的異常被標(biāo)記為提交前不可回滾比如業(yè)務(wù)上主動 setRollbackOnly 后又想繼續(xù)事務(wù)管理器決定提交或回滾最后清理事務(wù)資源、恢復(fù)自動提交狀態(tài)、把連接釋放回連接池。這里有個容易忽略的技術(shù)細節(jié)TransactionTemplate 在事務(wù)管理過程中主要依據(jù)回調(diào)拋出的異常類型來判定是否回滾。默認情況下它是遇到 RuntimeException 和 Error 就回滾遇到受檢異常不回滾。這個默認行為繼承自 Spring 事務(wù)管理的整體設(shè)計——因為受檢異常在方法簽名中顯式聲明通常是為了捕獲后做補償或重試而不是為了回滾。讓我用一個實際場景來解釋這個機制的價值。比如一個銀行轉(zhuǎn)賬接口轉(zhuǎn)出方扣款成功之后轉(zhuǎn)入方入賬失敗正常情況下應(yīng)該整筆回滾。但如果異常已經(jīng)被外層捕獲并轉(zhuǎn)換成了受檢異常Transactional 默認不會觸發(fā)回滾。而用 TransactionTemplate 的話由于你是直接在回調(diào)里控制狀態(tài)可以更明確地指定什么情況必須回滾。看一段更接近真實業(yè)務(wù)的代碼public TransferResult transfer(TransferCommand command) { return transactionTemplate.execute(status - { try { accountService.debit(command.getFromAccount(), command.getAmount()); accountService.credit(command.getToAccount(), command.getAmount()); return new TransferResult(true, success); } catch (AccountNotFoundException e) { status.setRollbackOnly(); return new TransferResult(false, e.getMessage()); } catch (Exception e) { status.setRollbackOnly(); // 如果希望受檢異常也導(dǎo)致回滾需要在這里顯式處理 throw new RuntimeException(e); } }); }這段代碼里catch 到的受檢異常 AccountNotFoundException 本身不會自動觸發(fā)回滾但通過顯式調(diào)用 status.setRollbackOnly()事務(wù)依然被標(biāo)記為回滾同時能返回一個結(jié)構(gòu)化的業(yè)務(wù)結(jié)果而不是把異常直接拋出去讓上層還要做一層異常處理。這就是編程式事務(wù)比較適合做 API 類接口落到 DB 操作的場景的原因——事務(wù)回滾的決定權(quán)和業(yè)務(wù)返回結(jié)構(gòu)是統(tǒng)一的。2.2 事務(wù)傳播行為與 TransactionTemplate 的搭配玩法事務(wù)傳播行為Propagation是 Spring 事務(wù)模型里比較繞的一部分但跟 TransactionTemplate 搭配起來非常自然。TransactionTemplate 可以通過 setPropagationBehavior 來設(shè)定事務(wù)邊界與當(dāng)前存在事務(wù)之間的關(guān)系TransactionTemplate template new TransactionTemplate(txManager); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);常用傳播行為對照傳播行為語義典型場景PROPAGATION_REQUIRED當(dāng)前有事務(wù)則加入無則新建大多數(shù)業(yè)務(wù)默認行為PROPAGATION_REQUIRES_NEW掛起當(dāng)前事務(wù)新建一個獨立事務(wù)日志記錄、審計、操作記錄PROPAGATION_NESTED當(dāng)前有事務(wù)時使用 Savepoint無則新建分段回滾部分失敗只回滾子段PROPAGATION_SUPPORTS當(dāng)前有事務(wù)則加入無則以非事務(wù)方式執(zhí)行只讀查詢、非關(guān)鍵輔助操作PROPAGATION_NOT_SUPPORTED始終以非事務(wù)方式執(zhí)行掛起現(xiàn)有事務(wù)事務(wù)中有非事務(wù)性操作如大文件操作PROPAGATION_MANDATORY必須有現(xiàn)有事務(wù)無則拋異常強約束某些操作必須在事務(wù)內(nèi)PROPAGATION_NEVER絕不能有事務(wù)有則拋異常事務(wù)里不能執(zhí)行的特定操作這里值得展開的是 NESTED它跟 REQUIRES_NEW 經(jīng)常有人混淆。REQUIRES_NEW 的特點是徹底隔離它新建一個完全獨立的事務(wù)跟外部事務(wù)互不影響。外部事務(wù)回滾不影響內(nèi)部事務(wù)已經(jīng)提交的數(shù)據(jù)內(nèi)部事務(wù)回滾也不影響外部事務(wù)待提交的數(shù)據(jù)。這聽起來很省事但代價是物理上開了兩個數(shù)據(jù)庫事務(wù)連接占用、鎖等待、性能消耗都會增加。NESTED 則完全不同它是基于 Savepoint 的嵌套。如果外部事務(wù)存在NESTED 事務(wù)會在當(dāng)前事務(wù)里創(chuàng)建一個 Savepoint內(nèi)部業(yè)務(wù)如果回滾只回滾到 Savepoint 位置外部事務(wù)仍然可以繼續(xù)。這個語義像把事務(wù)切了幾段某一段壞了只重做這一段。它是邏輯上的嵌套而不是另開一個物理事務(wù)。場景差異就很明顯了。比如一個報表任務(wù)先匯總一筆總賬寫到匯總表再寫大量的明細記錄。明細中偶發(fā)一條數(shù)據(jù)格式錯誤我希望只回滾出錯的那段明細不動總賬還要繼續(xù)處理后面幾條用 NESTED 比較合適。但如果是寫審計日志要求不管主流程成不成功日志一定留下來那就得用 REQUIRES_NEW因為日志事務(wù)必須脫離主事務(wù)的生命周期。需要注意的是NESTED 依賴底層數(shù)據(jù)庫的 Savepoint 支持在 MySQL 的 InnoDB、PostgreSQL、Oracle 上都能正常工作但如果你用的數(shù)據(jù)庫不支持 Savepoint比如某些老版本 MyISAM它會在運行時拋異常。所以選 NESTED 之前先確認數(shù)據(jù)庫能力。在 TransactionTemplate 上設(shè)置傳播行為之后配合不同的回調(diào)組合就能很靈活地控制嵌套事務(wù)。比如外層一個 template內(nèi)部某段業(yè)務(wù)又注入另一個配了 REQUIRES_NEW 的 template那這段業(yè)務(wù)會單獨事務(wù)執(zhí)行。2.3 隔離級別、超時與只讀TransactionTemplate 三個容易被忽略的屬性TransactionTemplate 除了傳播行為還可以設(shè)置事務(wù)的隔離級別、超時時間、是否只讀。這幾個屬性在實際項目中經(jīng)常被漏配但其實都很有用。隔離級別事務(wù)隔離級別解決的是并發(fā)下數(shù)據(jù)可見性的問題。TransactionTemplate 支持標(biāo)準(zhǔn)的五個級別DEFAULT使用數(shù)據(jù)庫默認隔離級別MySQL 默認是 REPEATABLE_READREAD_UNCOMMITTED能讀到未提交數(shù)據(jù)可能會臟讀READ_COMMITTED只能讀到已提交數(shù)據(jù)解決臟讀REPEATABLE_READ同一個事務(wù)里多次查詢結(jié)果一致解決不可重復(fù)讀SERIALIZABLE完全串行化解決幻讀但性能影響很大。數(shù)據(jù)庫并發(fā)場景不同選法也不同。比如一個統(tǒng)計報表任務(wù)讀多寫少用 REPEATABLE_READ 就能保證一次事務(wù)里多次查詢看到的快照一致如果要做賬務(wù)核對類操作精度要求高的話就要考慮 SERIALIZABLE但要衡量對并發(fā)性能的影響。在 TransactionTemplate 上設(shè)置隔離級別template.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);超時時間事務(wù)超時是針對事務(wù)內(nèi)所有數(shù)據(jù)庫操作耗時總和的約束。設(shè)置之后如果超過時間限制Spring 會讓事務(wù)回滾并拋出異常。默認超時是 -1表示使用底層數(shù)據(jù)源的默認值或不設(shè)限制。這個屬性在長時間運行的批處理任務(wù)、運營后臺的 Excel 導(dǎo)入里很有用。沒有超時約束時如果數(shù)據(jù)庫鎖等待時間過長事務(wù)會一直占著連接連接池耗盡之后整個應(yīng)用就假死了。設(shè)一個合理的超時時間比如 30 秒就能在事務(wù)卡住的時候快速失敗并釋放連接。template.setTimeout(30); // 單位秒但要注意一點這個超時是通過 JDBC 層的定時檢查來實現(xiàn)的如果在事務(wù)里有一個特別耗時的第三方調(diào)用那是不會被這個超時約束的。它只約束數(shù)據(jù)庫操作自身的時間。只讀事務(wù)把事務(wù)標(biāo)記為只讀可以讓數(shù)據(jù)庫優(yōu)化器做一些查詢路徑上的優(yōu)化在 MySQL 里主要是提示服務(wù)器不產(chǎn)生讀鎖寫日志等開銷同時也是一種語義約束——在只讀事務(wù)里發(fā)生的寫操作通常會在提交階段報錯。在查詢類任務(wù)里把事務(wù)標(biāo)記為只讀配合 REPEATABLE_READ 隔離級別能減少不必要的開銷。比如template.setReadOnly(true);要注意的是如果這個對象還被復(fù)用于寫操作那就不能設(shè)置只讀否則后續(xù)的寫操作會出問題。因此模板如果是被多個業(yè)務(wù)共享的建議針對不同用途配置多個 TransactionTemplate 實例而不是一個模板走到底。2.4 使用 TransactionCallbackWithoutResult 簡化無返回值場景TransactionTemplate.execute 需要返回一個值但很多時候我們只是在事務(wù)里執(zhí)行更新不需要返回任何對象。Spring 提供了一個子接口 TransactionCallbackWithoutResult它把返回值定義為 void執(zhí)行完成之后模板自動提交或者根據(jù)異?；貪L。transactionTemplate.execute(new TransactionCallbackWithoutResult() { Override protected void doInTransactionWithoutResult(TransactionStatus status) { orderDao.updateStatus(orderId, OrderStatus.PAID); accountDao.incrementBalance(userId, amount); } });使用 Lambda 表達式可以更簡潔transactionTemplate.executeWithoutResult(status - { orderDao.updateStatus(orderId, OrderStatus.PAID); accountDao.incrementBalance(userId, amount); });代碼里的 executeWithoutResult 是 TransactionOperations 接口的 default 方法內(nèi)部會把回調(diào)包裝成 TransactionCallback返回 null然后模板統(tǒng)一處理事務(wù)生命周期。這個寫法適合那些通知一下、更新幾個字段、不需要拿返回值的事務(wù)操作可以讓業(yè)務(wù)方法表達出真實意圖——我不關(guān)心返回值只要這段代碼在一個事務(wù)里執(zhí)行。2.5 編程式事務(wù) vs 聲明式事務(wù)怎么選才合適很多團隊會有這種討論到底是用 Transactional 還是 TransactionTemplate我的結(jié)論是不是二選一而是看事務(wù)邊界的可預(yù)測性。事務(wù)邊界固定整個方法就是事務(wù)方法結(jié)束即事務(wù)結(jié)束那就用聲明式 Transactional代碼最簡潔意圖最清晰。事務(wù)邊界動態(tài)需要根據(jù)運行時的數(shù)據(jù)、狀態(tài)或者外部調(diào)用結(jié)果來決定事務(wù)怎么結(jié)束那就用 TransactionTemplate。事務(wù)粒度細分一個業(yè)務(wù)里需要多次獨立事務(wù)、嵌套事務(wù)、分段提交那也適合用 TransactionTemplate。新舊代碼混合老項目里已經(jīng)有聲明式事務(wù)新加的功能又需要更靈活的控制可以在同一個服務(wù)里混用只要互相清楚各自的事務(wù)邊界。我實際看到過一種比較推薦的做法是在 Service 層定義一個注入的 TransactionTemplate用它來完成所有需要編程式事務(wù)控制的方法其他地方保持 Transactional 做透明事務(wù)。兩者職責(zé)分開不會互相干擾。3. 深入事務(wù)狀態(tài)對象TransactionStatus 背后的設(shè)計思想3.1 TransactionStatus 能做什么回調(diào)里拿到的 TransactionStatus 接口定義了幾個關(guān)鍵方法public interface TransactionStatus { boolean isNewTransaction(); boolean hasSavepoint(); void setRollbackOnly(); boolean isRollbackOnly(); void flush(); boolean isCompleted(); }逐個說isNewTransaction()當(dāng)前事務(wù)是否是新建的。如果因為傳播行為加入了外層已有事務(wù)這個方法返回 false。這個判斷在嵌套編排里特別有用——如果你需要一個獨立事務(wù)但發(fā)現(xiàn)自己是在外層事務(wù)里就要考慮調(diào)整傳播行為或者拆分模板。hasSavepoint()當(dāng)前事務(wù)是否保存了 Savepoint。跟 NESTED 傳播行為配合判斷當(dāng)前是否處于嵌套層級。setRollbackOnly()把事務(wù)標(biāo)記為只能回滾不能提交。調(diào)用這個方法之后即使回調(diào)正常結(jié)束事務(wù)在提交階段也會被強制回滾。這是編程式事務(wù)最核心的控制能力。isRollbackOnly()查詢當(dāng)前事務(wù)是否已經(jīng)被標(biāo)記為回滾。flush()強制把當(dāng)前會話中的修改同步到數(shù)據(jù)庫。在 JPA/Hibernate 這類帶持久化上下文的場景下有時候需要提前 flush 以讓后續(xù)查詢看到更新或者讓數(shù)據(jù)庫約束檢查提前觸發(fā)。isCompleted()事務(wù)是否已經(jīng)結(jié)束提交或回滾。3.2 setRollbackOnly 的實際價值setRollbackOnly 在實際業(yè)務(wù)中有兩個關(guān)鍵應(yīng)用場景。場景一是業(yè)務(wù)上判定失敗但代碼沒拋異常。比如在業(yè)務(wù)校驗中某個賬戶已經(jīng)凍結(jié)再往下執(zhí)行沒有意義但你要的是回滾而不必制造一個異常transactionTemplate.executeWithoutResult(status - { deductionService.deductPoints(userId, points); if (memberService.isFrozen(userId)) { status.setRollbackOnly(); return; } // 繼續(xù)其他正常業(yè)務(wù)... });這里如果直接 throw new RuntimeException會導(dǎo)致業(yè)務(wù)異常堆棧被包裝成框架異常調(diào)用方要解析這一層而 setRollbackOnly 直接回滾事務(wù)同時代碼還能正常返回業(yè)務(wù)狀態(tài)可以繼續(xù)處理。場景二是外部調(diào)用成功后本事務(wù)主動放棄。比如支付回調(diào)本地事務(wù)先更新訂單狀態(tài)再調(diào)用外部支付系統(tǒng)確認如果外部確認結(jié)果要求本地事務(wù)取消則 setRollbackOnly 回滾本地變更。需要特別注意的是一旦調(diào)用了 setRollbackOnly這個事務(wù)就被打上了回滾標(biāo)簽。在同一個事務(wù)里即使你后續(xù)再執(zhí)行其他操作也無法撤銷這個標(biāo)記。這也是一個經(jīng)典的踩坑點——在一個共享事務(wù)里某個組件標(biāo)記了回滾但外層業(yè)務(wù)還繼續(xù)執(zhí)行并且最終想提交結(jié)果整個事務(wù)還是回滾了。3.3 flush() 在 ORM 場景中的應(yīng)用如果你在 TransactionTemplate 里使用 JPA那么 flush() 的使用頻率會比 JDBC 高得多。原因是 JPA 是一種延遲寫的模型實體更新之后不會立刻刷到數(shù)據(jù)庫而是攢到事務(wù)提交前統(tǒng)一 flush。如果業(yè)務(wù)邏輯緊接著要查詢剛剛更新的數(shù)據(jù)或者要讓數(shù)據(jù)庫唯一約束提前生效就需要主動 flush。舉個例子事務(wù)里先給用戶分配一個優(yōu)惠碼然后立刻判斷這個優(yōu)惠碼是否已被使用過。如果依賴數(shù)據(jù)庫的唯一索引來校驗而 flush 發(fā)生在事務(wù)提交時那么第二次查詢可能還沒把第一次的寫入刷進去導(dǎo)致查不到數(shù)據(jù)。顯式調(diào)用 status.flush() 會把當(dāng)前的實體變化同步到數(shù)據(jù)庫讓后續(xù)邏輯能看到最新狀態(tài)同時唯一索引沖突也能提前暴露。這個知識點在先寫后查同一事務(wù)的場景里很容易救你一命。4. 實操篇一個事務(wù)模板搞定復(fù)雜業(yè)務(wù)場景4.1 方法一標(biāo)準(zhǔn)模板配置與復(fù)用在實際項目里強烈建議不要每次 new 一個 TransactionTemplate而是把它作為 Spring Bean 注入使用。原因有兩個一個實例配置一次事務(wù)屬性后續(xù)復(fù)用省去重復(fù)配置另外 Spring 容器管理生命周期也更符合統(tǒng)一配置原則。最典型的配置方式Component public class TransactionTemplates { Bean public TransactionTemplate requiredTemplate(PlatformTransactionManager tm) { TransactionTemplate template new TransactionTemplate(tm); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); template.setTimeout(30); return template; } Bean public TransactionTemplate requiresNewTemplate(PlatformTransactionManager tm) { TransactionTemplate template new TransactionTemplate(tm); template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); return template; } }這樣你在 Service 里就能按場景選擇合適的模板Service public class OrderService { private final TransactionTemplate requiredTemplate; private final TransactionTemplate requiresNewTemplate; public void createOrder(OrderCommand command) { requiredTemplate.executeWithoutResult(status - { orderDao.insert(command.toOrder()); // 給用戶加積分 requiresNewTemplate.executeWithoutResult(innerStatus - { pointsDao.increment(command.getUserId(), command.getPoints()); }); }); } }這段代碼的含義是創(chuàng)建訂單和加積分在同一個事務(wù) REQUIRED 里但給用戶加積分這個動作又單獨做了一個 REQUIRES_NEW 事務(wù)。即使創(chuàng)建訂單的事務(wù)最終回滾積分增加的記錄也已經(jīng)被獨立提交了這在某些場景下恰恰是業(yè)務(wù)需要的比如只要用戶點擊了下單按鈕積分就要加不管訂單最終有沒有落庫成功。當(dāng)然真實業(yè)務(wù)要不要這么做要看產(chǎn)品定義但 TransactionTemplate 的組合使用方式就是這么靈活。4.2 方法二在一個事務(wù)里分階段執(zhí)行業(yè)務(wù)并決定提交還是回滾很多系統(tǒng)對接場景需要本地更新 遠程確認的組合。比如支付回調(diào)處理過程中本地先更新訂單狀態(tài)、記賬然后調(diào)用遠程接口做風(fēng)控確認確認結(jié)果決定事務(wù)走向。用 TransactionTemplate 實現(xiàn)public PaymentResult handleCallback(PaymentCallback callback) { return transactionTemplate.execute(status - { // 階段一本地數(shù)據(jù)更新 orderService.markPaid(callback.getOrderId()); paymentLogService.record(callback); // 階段二遠程確認 RiskCheckResult riskResult riskClient.check(callback); if (!riskResult.isPass()) { status.setRollbackOnly(); return PaymentResult.reject(riskResult.getReason()); } // 階段三本地數(shù)據(jù)二次更新 orderService.confirmPaid(callback.getOrderId()); return PaymentResult.accept(); }); }這里有幾個好處事務(wù)邊界覆蓋整個本地數(shù)據(jù)更新鏈路任何一步發(fā)現(xiàn)需要終止setRollbackOnly 就能讓全部本地變更回滾返回結(jié)果是一個結(jié)構(gòu)化的業(yè)務(wù)對象不用依賴異常傳播來表達失敗語義遠程調(diào)用的時間被包含在事務(wù)生命周期里如果超時可以設(shè)置整體事務(wù)超時兜底在回調(diào)里可以自由編排階段順序、跳過某些步驟代碼直觀。4.3 方法三批量任務(wù)中實現(xiàn)行級事務(wù)與隔離批量處理是 TransactionTemplate 比較能發(fā)揮優(yōu)勢的場景。比如定時任務(wù)要遍歷一個比較大的數(shù)據(jù)集合幾萬條每條記錄執(zhí)行獨立的更新 校驗 記錄流程。要求是單條失敗不影響后續(xù)記錄且每條記錄的事務(wù)互不干擾。實現(xiàn)方式有兩種思路取決于對事務(wù)邊界的理解。第一種每一條記錄一個獨立事務(wù)for (Record record : records) { try { transactionTemplate.executeWithoutResult(status - { validate(record); update(record); audit(record); }); } catch (Exception e) { log.error(記錄處理失敗, recordId{}, record.getId(), e); // 單條失敗不影響循環(huán)繼續(xù) } }這里的 TransactionTemplate 配 PROPAGATION_REQUIRED每次循環(huán)開啟一個新事務(wù)處理完立即提交。某條失敗異常被 catch 捕獲本事務(wù)回滾其他記錄照常處理。這個模式在數(shù)據(jù)庫鎖競爭不大、單條操作耗時不長的任務(wù)中很高效。第二種如果單條處理邏輯內(nèi)部還分多個階段可以用 NESTED 做局部回滾transactionTemplate.executeWithoutResult(status - { // 匯總更新 summaryDao.updateSummary(records); // 分階段處理細分回滾段 try { transactionTemplate.executeWithoutResult(innerStatus - { for (Record record : records) { detailDao.insert(record); } }); } catch (Exception e) { // 明細插入失敗回滾到 Savepoint但匯總結(jié)論還在 log.error(明細處理失敗但匯總已更新, e); } });這里外層事務(wù)控制總體內(nèi)層用 NESTED 細分回滾讓明細失敗但匯總保留成為可能。實際項目中具體怎么設(shè)計取決于業(yè)務(wù)要求的隔離粒度。4.4 方法四事務(wù)模板與 CompletableFuture 異步任務(wù)的組合TransactionTemplate 在異步場景里也有獨特的價值。Spring 聲明式事務(wù)是綁定在線程上的異步線程里如果用 Transactional 會面臨事務(wù)上下文丟失的問題。而 TransactionTemplate 因為把事務(wù)邊界的控制權(quán)交給你可以在異步任務(wù)內(nèi)部開啟獨立事務(wù)天然規(guī)避了這個坑。比如某個任務(wù)需要先同步做一段預(yù)處理再異步插入大量明細public void processAsync(ListData batchData) { transactionTemplate.executeWithoutResult(status - { prepareMainData(batchData); }); CompletableFuture.runAsync(() - { transactionTemplate.executeWithoutResult(status - { for (Data data : batchData) { detailDao.save(data); } }); }).exceptionally(ex - { log.error(異步寫明細失敗, ex); return null; }); }這里同步部分先提交一個事務(wù)異步部分另起一個事務(wù)兩個事務(wù)互不干擾異步里如果失敗也不影響主流程已提交的數(shù)據(jù)。這正是 TransactionTemplate 在異步場景里相對聲明式事務(wù)的優(yōu)勢體現(xiàn)。當(dāng)然異步場景下真正需要注意的是分布式事務(wù)的一致性方案比如本地消息表 定時任務(wù)、事務(wù)消息等。但只要你把事務(wù)邊界定義清楚這些方案里的本地事務(wù)部分TransactionTemplate 都可以承擔(dān)。4.5 TransactionTemplate 和 Transactional 的混合使用技巧可能有人會問一個 Service 里能不能同時用 TransactionTemplate 和 Transactional可以的Spring 的事務(wù)管理是雙通道的只要事務(wù)管理器一致它們就共享同一個事務(wù)設(shè)施。一個常見的設(shè)計是對外暴露的入口方法用 Transactional 聲明統(tǒng)一事務(wù)內(nèi)部某些特殊步驟用 TransactionTemplate 做獨立的子事務(wù)REQUIRES_NEW 或 NESTED。示例如下Transactional public void processOrder(Order order) { // 主事務(wù)處理 orderDao.updateStatus(order.getId(), OrderStatus.PROCESSING); // 子事務(wù)記錄操作日志即使主事務(wù)回滾也保留 auditTemplate.executeWithoutResult(status - { logDao.insert(processOrder, order.getId()); }); }這里 processOrder 用 Transactional 劃定了主事務(wù)邊界而審計日志使用獨立的 REQUIRES_NEW 事務(wù)。這樣即使主流程后續(xù)拋異常導(dǎo)致回滾審計日志也已經(jīng)落庫了可以追溯這個訂單確實被嘗試處理過。混合使用的關(guān)鍵約束是參與同一個物理事務(wù)的代碼必須保持一致的傳播行為認知不能出現(xiàn)一邊期待獨立回滾、一邊又共享事務(wù)狀態(tài)的邏輯混亂。因此混合使用之前最好寫清楚每個方法的事務(wù)語義注釋。5. 踩坑記錄與排查實錄TransactionTemplate 使用中的高發(fā)問題5.1 坑一事務(wù)管理器配置錯了導(dǎo)致事務(wù)根本沒生效TransactionTemplate 最典型的配置錯誤是給它塞了一個跟實際數(shù)據(jù)源不匹配的事務(wù)管理器。比如項目里用了 JPA卻從容器里拿了一個 DataSourceTransactionManager或者配置了兩個數(shù)據(jù)源但只給事務(wù)管理器設(shè)了一個。排查思路出現(xiàn)明明在事務(wù)里執(zhí)行的代碼異常了卻沒回滾的詭異現(xiàn)象第一步去看 TransactionTemplate 的 transactionManager 到底是什么類型。如果事務(wù)管理器跟數(shù)據(jù)源對不上整個事務(wù)就是空轉(zhuǎn)狀態(tài)——業(yè)務(wù)代碼執(zhí)行了但根本沒有物理事務(wù)來保護它。另外如果多個數(shù)據(jù)源配置了多個事務(wù)管理器那么 Spring 容器會有多個 PlatformTransactionManager Bean注入 TransactionTemplate 時要通過 Qualifier 明確指定Bean public TransactionTemplate orderTemplate(Qualifier(orderTransactionManager) PlatformTransactionManager tm) { return new TransactionTemplate(tm); }這個錯誤隱蔽性比較強因為代碼不會編譯報錯日志也看不出明顯異常。5.2 坑二事務(wù)鎖與連接池耗盡問題長事務(wù)占用連接是最常見的高危場景。TransactionTemplate 的 execute 從進入回調(diào)到方法返回整個期間都持有一個數(shù)據(jù)庫連接。如果回調(diào)里有個慢查詢或者同步調(diào)用了外部接口事務(wù)就一直掛著連接遲遲不歸還。這種情況在并發(fā)上來之后容易出事連接池默認 10 個連接10 個請求都在事務(wù)里等外部接口后續(xù)請求全部阻塞在獲取連接的環(huán)節(jié)系統(tǒng)假死。解決經(jīng)驗回調(diào)里盡量別做耗時操作外部 HTTP 調(diào)用建議放在事務(wù)外配置合理的超時時間至少讓連接不無限等待監(jiān)控連接池使用率超過閾值要報警。如果確實需要在事務(wù)里做外部調(diào)用某些強一致場景無法避免至少要給外部調(diào)用設(shè)置單獨的短超時別讓一個事務(wù)等外部接口 60 秒。5.3 坑三setRollbackOnly 之后還想提交事務(wù)已經(jīng)回滾這個坑的迷惑性很強。比如某個嵌套事務(wù)里內(nèi)層事務(wù)調(diào)用了 setRollbackOnly但外層邏輯覺得不影響大局繼續(xù)提交。結(jié)果是整個事務(wù)在提交階段被強制回滾代碼上沒有拋出任何異?？雌饋砭拖袷裁炊紱]發(fā)生但數(shù)據(jù)沒落庫。我碰到過一次經(jīng)典的案例一個交易系統(tǒng)主流程調(diào)用了內(nèi)部記賬模塊記賬模塊在某個分支里 setRollbackOnly 后返回了一個正常對象主流程繼續(xù)執(zhí)行其他步驟最終想提交整個事務(wù)結(jié)果數(shù)據(jù)完全沒有寫入。當(dāng)時排查了很久才發(fā)現(xiàn)是內(nèi)部模塊的 rollbackOnly 標(biāo)記傳遞到了整個物理事務(wù)上。這個問題的根源是在 REQUIRED 傳播行為下內(nèi)層事務(wù)和外層事務(wù)共享同一個物理事務(wù)setRollbackOnly 修改的是整個物理事務(wù)的狀態(tài)。解決辦法如果內(nèi)層業(yè)務(wù)對標(biāo)記回滾有獨立語義應(yīng)該配置 REQUIRES_NEW 讓內(nèi)層單獨開物理事務(wù)或者在外層調(diào)用前檢查 status.isRollbackOnly()提前中斷別讓后續(xù)代碼繼續(xù)空跑。5.4 坑四受檢異常默認不回滾數(shù)據(jù)部分成功回想一下TransactionTemplate 的默認回滾策略跟 Spring 其他事務(wù)策略一致遇到 RuntimeException 和 Error 回滾受檢異常默認不回滾。這就會導(dǎo)致一個隱蔽問題如果你的業(yè)務(wù)代碼 catch 了一個受檢異常并向上層拋出比如轉(zhuǎn)換為自定義業(yè)務(wù)異常事務(wù)不會回滾但之前的數(shù)據(jù)改動已經(jīng)留在數(shù)據(jù)庫里了看起來像部分數(shù)據(jù)更新成功。例如transactionTemplate.executeWithoutResult(status - { accountDao.deduct(userId, amount); transferDao.record(transfer); throw new BusinessException(賬戶凍結(jié)); // BusinessException extends Exception });BusinessException 如果是受檢異常上面的代碼不會觸發(fā)回滾扣款和記錄都已經(jīng)提交了。這就需要顯式處理要么讓 BusinessException 繼承 RuntimeException要么在 catch 中調(diào)用 status.setRollbackOnly()。排查方法如果發(fā)現(xiàn)數(shù)據(jù)異常但沒拋錯先從哪些異常是不會觸發(fā)回滾的查起確認異常體系是不是用了受檢異常。5.5 坑五事務(wù)內(nèi)操作跨線程事務(wù)上下文丟失Spring 的事務(wù)核心是把連接綁定在 ThreadLocal 上的所以它天然是線程綁定的。如果你在回調(diào)里使用 new Thread 或線程池異步執(zhí)行數(shù)據(jù)庫操作這些異步線程不持有當(dāng)前線程的事務(wù)上下文它們跑的 SQL 會走獨立連接、獨立提交完全不受事務(wù)控制。典型錯誤transactionTemplate.executeWithoutResult(status - { orderDao.update(order); new Thread(() - logDao.save(log)).start(); // 這個 logDao.save 不在當(dāng)前事務(wù)里 });如果需要異步操作參與當(dāng)前事務(wù)必須想辦法把事務(wù)上下文傳遞過去比如 TransactionSynchronizationManager 的機制但它也只適用于少數(shù)可控線程池場景實現(xiàn)成本高。更推薦的做法是讓異步任務(wù)用自己的事務(wù)模板明確它的事務(wù)邊界不要指望它繼承外層事務(wù)。5.6 坑六事務(wù)模板被多個業(yè)務(wù)共用時屬性互相污染TransactionTemplate 實例內(nèi)部保存了事務(wù)屬性傳播行為、超時、只讀等如果有多個業(yè)務(wù)流程共用同一個實例其中一個業(yè)務(wù)修改了屬性雖然少但可能有人會 set 一下其他業(yè)務(wù)也會受影響。更常見的是你設(shè)置了 readOnly后續(xù)的寫操作全被拒了或者設(shè)置了超時 5 秒一個跑批業(yè)務(wù)進來直接超時。最佳實踐是針對不同場景拆分模板每個模板的配置固定不要運行時改動屬性。如果需要動態(tài)改變傳播行為可以 new 一個新的 TransactionTemplate 實例而不是去改共享實例。5.7 常見問題速查表問題表現(xiàn)可能原因排查/解決思路事務(wù)沒回滾數(shù)據(jù)成功寫入事務(wù)管理器類型不匹配檢查注入的事務(wù)管理器和實際數(shù)據(jù)源事務(wù)回滾了但整體沒報錯內(nèi)部模塊 setRollbackOnly 傳播檢查嵌套調(diào)用的 propagate 配置連接池耗盡系統(tǒng)卡住長事務(wù) 慢SQL / 外部調(diào)用縮短事務(wù)內(nèi)耗時配置合理超時受檢異常沒觸發(fā)回滾默認回滾策略不含受檢異常改為 RuntimeException 或顯式 setRollbackOnly異步線程數(shù)據(jù)不在事務(wù)里事務(wù)上下文是線程綁定的異步任務(wù)用單獨模板開事務(wù)模板屬性互相影響多個業(yè)務(wù)共用同一實例按場景拆分模板運行時不改屬性6. 工具選型與設(shè)計建議讓 TransactionTemplate 發(fā)揮最大價值6.1 事務(wù)管理器的選擇與配置建議DataSourceTransactionManager 是 JDBC 場景的標(biāo)準(zhǔn)選擇在絕大部分單體項目中就夠用了。JpaTransactionManager 適合 JPA/Hibernate 項目它會同時管理 JPA 的 EntityManager 和底層 JDBC 連接保證兩者在同一個事務(wù)里協(xié)同。如果項目里同時用 MyBatis 和 JPA那可能需要兩個數(shù)據(jù)源管理器按用戶維度切分或者用 JtaTransactionManager 處理跨資源事務(wù)但后者復(fù)雜度更高。配置建議單一數(shù)據(jù)源 MyBatis/JDBCDataSourceTransactionManager單一數(shù)據(jù)源 JPA/HibernateJpaTransactionManager多數(shù)據(jù)源按數(shù)據(jù)源各配一個事務(wù)管理器業(yè)務(wù)上用路由或分布式事務(wù)方案微服務(wù)跨服務(wù)不建議直接用 TransactionTemplate 去控制分布式事務(wù)而是用 TCC、事務(wù)消息、SAGA 等專門方案TransactionTemplate 在其中的本地事務(wù)部分仍然可用。6.2 事務(wù)模板實例的生命周期管理在一個 Spring 項目中TransactionTemplate 實例可以交給容器管理作為單例 Bean 使用。它本身是無狀態(tài)的屬性在構(gòu)造時設(shè)定運行時不修改線程安全可以被多個線程并發(fā)調(diào)用。這個特性讓它可以放心地注入到任意 Service 里。如果你的服務(wù)需要不同的事務(wù)屬性組合創(chuàng)建多個 Bean 是合理的方式命名上建議語義清晰比如 orderRequiredTemplate、auditRequiresNewTemplate、readOnlyTemplate 等。這樣代碼里一看名字就知道這個模板的語義比直接在調(diào)用處 new 要清晰得多。6.3 與聲明式事務(wù)的邊界設(shè)計原則在同一個項目里混用 TransactionTemplate 和 Transactional需要的人為約束是明確每種事務(wù)方式的管轄邊界。我的建議是三層劃分入口層Controller / API / 定時任務(wù)入口用 Transactional 做整體事務(wù)邊界一個入口對應(yīng)一個業(yè)務(wù)完整流程服務(wù)層Service內(nèi)部特殊環(huán)節(jié)用 TransactionTemplate 控制局部事務(wù)數(shù)據(jù)層Dao / Repository保持無事務(wù)語義事務(wù)完全由上層決定。這條邊界規(guī)則能有效避免到處開事務(wù)的混亂。而且一旦團隊形成這種習(xí)慣代碼評審時看到某個 Service 方法里又出現(xiàn) Transactional 又要特別注意嵌套邊界就能快速判斷是否合理。6.4 測試與調(diào)試工具如何驗證事務(wù)行為真的符合預(yù)期TransactionTemplate 寫完之后測試驗證是必要的。我用過的幾個比較實用的調(diào)試手段在回調(diào)里故意拋一個 RuntimeException然后斷言數(shù)據(jù)庫數(shù)據(jù)沒有變化驗證回滾路徑在回調(diào)里調(diào)用 setRollbackOnly 后正常返回斷言數(shù)據(jù)沒有落庫驗證邏輯回滾路徑配置一個極短超時觀察超時之后事務(wù)狀態(tài)是否被正確清理用日志輸出當(dāng)前線程的事務(wù)狀態(tài)TransactionSynchronizationManager.isActualTransactionActive()、isCurrentTransactionReadOnly() 可以快速確認當(dāng)前是否真的在一個物理事務(wù)里。這些測試不需要復(fù)雜的框架寫在集成測試里就能早一點發(fā)現(xiàn)問題尤其是那些沒有異常但數(shù)據(jù)沒落庫的隱蔽坑靠這個能提前暴露。7. 最后再分享一點個人經(jīng)驗坦率地說TransactionTemplate 并不是一個炫技的技術(shù)點它的價值在于讓事務(wù)控制回歸到開發(fā)者手里。如果你所在的團隊經(jīng)常被 Transactional 的邊界問題困擾、批量任務(wù)經(jīng)常因一條臟數(shù)據(jù)拖垮整個事務(wù)、異步場景里事務(wù)上下文總是丟來丟去那么花時間把 TransactionTemplate 用熟回報率會非常高。我個人在項目中偏向一套固定的寫法事務(wù)模板全部由 Spring 容器管理并按業(yè)務(wù)命名回調(diào)方法命名以 doXxxInTransaction 開頭異常處理盡量在回調(diào)內(nèi)部消化并返回業(yè)務(wù)結(jié)果實在要拋出異常就顯式 setRollbackOnly 或者繼承 RuntimeException。這套規(guī)則一旦跑習(xí)慣事務(wù)相關(guān)的代碼不僅穩(wěn)定而且一年后回來翻代碼還能一眼看明白當(dāng)初為什么要這么寫。最后再提一個小技巧如果團隊里有人總是分不清一個事務(wù)到底是提交了還是回滾了可以在回調(diào)末尾打印一下 TransactionSynchronizationManager.getCurrentTransactionName() 和當(dāng)前事務(wù)的 rollbackOnly 狀態(tài)。這兩行日志在很多疑難問題上會節(jié)省大量排查時間。