一段被Try-Catch包裹的代碼，差點讓我丟了工作！
一段被 try-catch 包裹后的代碼在產線穩定運行了 200 天后忽然發生了異常，而這個異常竟然導致了產線事務回滾。
圖片來自 Pexels
這期間究竟發生了什么?日常在項目過程中該如何避免事務異常?就在這個時候，老板拿著《XX 公司關于三十歲員工優化通知》走了過來......
01
產線部分數據丟失了，因為一個蹊蹺的事務回滾。而造成事務回滾的，竟然是一段被 try-cath 包裹后的代碼，一段已經在產線穩定運行了 200 天的代碼，穩定到我們已經把它遺忘了。
誰也沒想到的是，它竟然以這樣一種方式重新回到了我們的視野，宣告著它的存在!
小九九是一個永遠 19 歲的程序員，和所有程序員一樣地陽光、帥氣(這句話不管你信不信，反正我自己也不信。為了能夠開始今天的文章，就這么瞎編吧，總比以“一個沒有頭發的程序員”開頭的好)。
當他告訴我一段 try-catch 的代碼造成產線事務回滾后，我溫柔、耐心地對他說：“滾一邊去，沒看我正忙著嗎?”，然后他給我甩出了一段代碼，用猥瑣又真誠的眼睛告訴我，他說的是真的。
02
我們來看一下這段導致了產線事務回滾的代碼，類似于下面這樣的：
- @Transactional
- public void main() {
- // 假設有多個user的操作，需要事務控制
- methodA();
- try {
- orderService.methodB();
- } catch (Exception e) {
- // order失敗了不能影響該方法,不回滾。
- // 異常處理，略
- }
- userOtherProcess();
- }
methodA 方法需要事務控制，methodB 方法不管遇到什么異常都不能影響 A 事務，所以加了 try-catch。
可能有的人和我的第一反應一樣，是不是最后的 userOtherProcess 方法執行異常造成了 methodA 的事務回滾?
小九九告訴我真的是因為 methodB，這段代碼當初經過嚴格的測試，而且已經 200 天沒人碰過了。
也可能已經有人猜出了問題的原因了，這里先賣個關子，因為這件事情里，最重要的是這個坑是如何一步步產生的。
為了更形象地描述這個事情我畫一個圖，紅色背景表示該方法是有事務控制的，白色背景表示該方法沒有事務：
一開始的時候，正如大家所看到的代碼，methodA 方法有事務，methodB 無事務且被 try-catch 包裹了，運行得很完美。
過了一段時間后來到了階段二，因為一些需求變更新增了 methodC，該業務也依賴了 methodB，依然很完美地上線了。
過了一段時間來到了階段 3，依賴 methodC 相關業務再次發生了變更，需要在 methodB 里增加一些邏輯且需要事務控制。
經過評估確實對 methodA 沒有影響，于是經過充分測試后再次完美地上線了，然而隱藏的炸彈就在這個時候埋下了。
小伙伴們這個時候應該已經猜到原因了，是的，你猜的沒錯。某一天 methodA 調用 methodB 時 methodB 發生了異常，由于是繼承性事務，雖然 methodB 發生了異常被 try-catch 了，依然造成了 methodA 事務回滾。
還沒有理解的小伙伴，可以看下面這張圖：
我們可以把事務控制機制理解為上圖這樣一個紅色的長長的房間，這個房間是有人看守的，他負責事務的開始、提交，還有一項重要的任務就是監控異常。
一旦發現 RuntimeException 異常直接回滾整個事務，我們給他一個 title，稱之為“監事”吧。
再來看階段三和一開始的代碼，方法的開頭有一個 @Transactional 注解，于是他打開了這個紅色房間的門，把 methodA 放了進去。
接著 methodB 過來了，也開啟了事務--繼承性事務，于是監事把 methodB 也安排到了這個房間。
methodB 雖然發生了異常且被 try-catch 包裹，但逃不過監事的火眼金睛，于是他按下了事務回滾的按鈕。
這樣理解了之后，我們再來簡單看一下源碼：
- org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
- at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:873)
- at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:710)
- at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:534)
根據異常提示，可以看到錯誤發生在 AbstractPlatformTransactionManager 的 873 行 processRollback 方法。
通過 Find Usages 找到調用方 commit 方法，顯然這是一段事務提交的邏輯。
- @Override
- public final void commit(TransactionStatus status) throws TransactionException {
- // 為便于閱讀，刪除部分代碼
- ......
- if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
- // 為便于閱讀，刪除部分代碼
- processRollback(defStatus, true);
- return;
- }
- processCommit(defStatus);
- }
shouldCommitOnGlobalRollbackOnly：默認實現是 false，意思是如果發現事務被標記全局回滾并且該標記不需要提交事務的話，那么則進行回滾。
defStatus.isGlobalRollbackOnly()：判斷是否是讀取 DefaultTransactionStatus 中 transaction 對象的 ConnectionHolder 的 rollbackOnly 標志位。
繼續往上追溯，來到 TransactionAspectSupport.invokeWithinTransaction 方法：
- @Nullable
- protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
- final InvocationCallback invocation) throws Throwable {
- // 為便于閱讀，刪除部分代碼
- ......
- // 如果是聲明式事務
- if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
- // Standard transaction demarcation with getTransaction and commit/rollback calls.
- TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
- Object retVal;
- try {
- // This is an around advice: Invoke the next interceptor in the chain.
- // This will normally result in a target object being invoked.
- // 執行事務方法
- retVal = invocation.proceedWithInvocation();
- }
- catch (Throwable ex) {
- // 捕獲異常，并將會把事務設置為Rollback回滾狀態。
- completeTransactionAfterThrowing(txInfo, ex);
- throw ex;
- }
- finally {
- cleanupTransactionInfo(txInfo);
- }
- // 提交事務
- commitTransactionAfterReturning(txInfo);
- return retVal;
- }
- else {
- // 聲明式事務，略
- }
- }
整個執行過程參見注釋說明，其它源碼就不羅列了。Spring 捕獲異常后，正如我們所猜測的，事務將會被設置全局 rollback。
而最外層的事務方法執行 commit 操作，這時由于事務狀態為 rollback，Spring 認為不應該 commit 提交事務，而應該回滾事務，所以拋出 rollback-only 異常。
03
還有一個比較典型的事務問題就是：在同一個類中，mehtodA 沒有事務，mehtodB 開啟了(聲明式)事務。
此時 mehtodA 調用 mehtodB 時事務是不生效的：
如上面這張圖所示，我們還是把 AOP 想像成一個長方形的房間，由于 mehtodA 沒有事務，這個房間已經被標志為沒有事務無人值守了，mehtodB 雖然標記了事務，但很顯然是不生效的。
接下來我們重新回顧一下事務的幾種配置：
- REQUIRED：支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。
- REQUIRES_NEW：新建事務，如果當前存在事務，把當前事務掛起。
- SUPPORTS：支持當前事務，如果當前沒有事務，就以非事務方式執行。
- MANDATORY：支持當前事務，如果當前沒有事務，就拋出異常。
- NEVER：以非事務方式執行，如果當前存在事務，則拋出異常。
- NOT_SUPPORTED：以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
- NESTED：支持當前事務，如果當前事務存在，則執行一個嵌套事務，如果當前沒有事務，就新建一個事務。
這方面的文章很多，這里就不做描述了。
04
事務問題本身是比較難通過測試發現的，我們再來聊一聊項目過程中如何防止事務問題的發生。
比如筆者之前曾負責過支付及資金處理相關系統，產品的單筆交易額比較大，每筆至少 1 萬+，正常 10 萬+，很多時候一筆支付就是 300 萬，所以容不得出現一筆資金差錯。好在我們資金交易從 0 做到了 3000 億，依然資金 0 差錯。
針對可能的事務問題，我們采取的措施有：
- 通過開發規范、產線坑集等文檔、培訓等讓開發人員對事務有足夠的了解、敏感度。
- 系統設計時，對于關鍵的業務場景需要寫明是否啟用了事務，哪些方法包裹在一個事務中，并進行評審。
- 代碼 Review 環節有很多專項 Review，比如資金 Review、多線程 Review 等等，也有一項專門的事務 Review：需不需要加事務?事務配置是否正確?異常是否處理等。
- 開發人員構造事務異常場景進行自測、交叉驗證。
- 測試團隊參與系統設計評審，并進行事務相關測試。比如通過防火墻阻斷請求、手動鎖表等方式來模擬可能的事務異常。
筆者在之前一家公司還有一種做法就是通過開發規范約束：所有事務的方法全部以 tx 開頭。
比如 methodB 方法需要開啟事務，則新增一個 txMethodB 方法，在該方法中調用 methodB。通過這種方式完全可以避免上面問題的發生，但很顯然這種方式相當地“丑陋”。
05
正和小九九聊著事務問題，老板手里拿著幾張 A4 紙走了過來。
作為公司唯一的 30 歲程序員，我提高了聲音對小九九說：你有沒有發現 @Transactional 中還有一個配置項 readOnly，如果需要使用這個參數，必須啟動一個事務。
但如果是讀取數據，根本就不需要事務啊?為什么會有這么一個自相矛盾的配置項呢?小九九一臉茫然地搖了搖頭。
老板沖我點了點頭，轉身回到了辦公室，坐下思考了一會，然后把手里的 A4 紙《XX 公司關于三十歲員工優化通知》放到了抽屜一疊資料的最下面，接著又抽出來放到了資料的中間。
看來我的程序生涯，又可以持續一段時間了!
作者：劍圣
編輯：陶家龍
出處：轉載自微信公眾號碼大叔(ID：ma_dashu)
