兄弟們，工作這些年，踩過的坑數不勝數，其中關于@Transactional注解的坑，可真是讓我印象深刻。今天，我就把這些年遇到的坑整理出來，分享給大家，希望能讓大家少走一些彎路。

一、@Transactional 基本概念回顧

在開始填坑之前，咱們先簡單回顧一下@Transactional注解的基本概念。@Transactional是 Spring 框架提供的用于聲明式事務管理的注解，它可以應用在方法或類上，用于指定該方法或類中的所有公共方法在執行時需要進行事務管理。

使用@Transactional注解可以讓我們無需手動編寫事務開啟、提交、回滾的代碼，大大簡化了事務管理的工作。但是，如果你以為只要加上這個注解就萬事大吉了，那可就大錯特錯了，接下來咱們就來看看那些隱藏的坑。

二、注解生效條件的坑

（一）非 public 方法無效

你以為把@Transactional注解加在任何方法上都能生效嗎？錯啦！Spring 的@Transactional注解默認只能應用在 public 修飾的方法上。如果我們把注解加在 protected、private 或者默認訪問修飾符的方法上，注解會失效，事務不會被管理。

我就曾經犯過這樣的錯誤，在一個工具類里寫了一個 private 方法，加上了@Transactional注解，結果發現事務根本沒有生效，數據出現了不一致的情況。當時找了好久的原因，最后才發現是方法訪問修飾符的問題。

為什么會這樣呢？這是因為 Spring 在掃描方法的時候，默認只會處理 public 方法。如果我們希望在非 public 方法上使用事務，可以通過配置來修改這個行為，不過一般情況下，不建議這么做，還是按照規范把事務注解加在 public 方法上比較好。

（二）類內部方法調用失效

假設我們有一個類UserService，里面有兩個方法，一個 public 的addUser方法和一個 private 的updateUser方法，addUser方法中調用了updateUser方法，并且在addUser方法上加上了@Transactional注解。這時候，如果你認為updateUser方法中的操作也會在同一個事務中執行，那就錯了。

當我們在同一個類內部調用方法時，Spring 的事務代理機制不會起作用，因為此時調用的是目標對象本身，而不是代理對象。所以，updateUser方法中的操作不會被納入到事務管理中，如果在updateUser方法中出現異常，不會觸發事務的回滾。

舉個例子，比如在addUser方法中，先插入一條用戶數據，然后調用updateUser方法更新用戶的某個字段，如果updateUser方法中拋出了異常，而addUser方法沒有捕獲這個異常，按照我們的預期，應該回滾插入操作，但實際上，由于事務沒有覆蓋到updateUser方法，插入操作已經提交，導致數據不一致。

解決這個問題的方法是，將需要事務管理的方法暴露為 public 方法，或者通過注入自身的代理對象來調用方法。比如，在 Spring 中，我們可以通過@Autowired注入自己，然后通過代理對象來調用方法，這樣就能讓事務生效了。

三、方法調用方式的坑

（一）異步調用事務失效

在實際開發中，我們可能會使用異步方法來提高系統的性能，比如使用@Async注解來標記異步方法。這時候，如果在異步方法上使用了@Transactional注解，需要注意事務可能會失效。

原因是異步方法是在另一個線程中執行的，而 Spring 的事務是基于線程綁定的，不同的線程擁有不同的事務上下文。當我們在主線程中調用異步方法時，異步方法所在的線程并沒有獲取到主線程的事務上下文，所以事務注解會失效。

我之前在處理一個發送短信的業務時，為了不阻塞主線程，將發送短信的方法標記為異步方法，并且加上了@Transactional注解，希望在發送短信失敗時回滾相關的業務操作。結果發現，即使發送短信拋出了異常，相關的業務操作也沒有回滾，就是因為異步調用導致事務失效了。

要解決這個問題，我們需要確保異步方法所在的線程能夠獲取到事務上下文，或者在異步方法中單獨開啟事務。不過，一般情況下，異步操作和主線程的業務操作屬于不同的事務邊界，我們需要根據具體的業務需求來設計事務的管理方式。

（二）子類重寫方法注解失效

如果我們有一個父類BaseService，在父類的方法上加上了@Transactional注解，然后子類SubService繼承了父類，并重寫了這個方法。這時候，如果子類沒有在重寫的方法上添加@Transactional注解，那么父類的注解是否會生效呢？

答案是不一定。這取決于 Spring 的事務代理方式。如果使用的是基于接口的代理（JDK 動態代理），那么只有當子類實現了父類的接口時，父類的注解才會生效；如果使用的是基于類的代理（CGLIB 代理），那么子類重寫方法時，如果方法不是 final 的，父類的注解可能會生效，但如果子類的方法訪問修飾符比父類更嚴格，比如父類是 public，子類是 protected，那么注解會失效。

為了避免這種情況，我們最好在子類重寫的方法上顯式地加上@Transactional注解，明確指定事務的配置，這樣可以保證事務的行為符合我們的預期。

四、異常處理的坑

（一）未捕獲的 Checked 異常不回滾

@Transactional注解默認情況下只會回滾 RuntimeException 及其子類（即未檢查異常），對于 Checked 異常（即受檢查異常），如果沒有被捕獲，事務不會自動回滾。

這是一個非常容易踩的坑。比如，我們在方法中調用了一個可能拋出 SQLException（Checked 異常）的數據庫操作，而沒有對這個異常進行處理，也沒有在@Transactional注解中指定回滾該異常，那么即使操作失敗，事務也不會回滾，數據會被提交。

我曾經在處理一個文件上傳的業務時，需要同時將文件信息保存到數據庫中。在保存數據庫時，可能會因為唯一約束沖突拋出 SQLException，而我沒有在方法上添加rollbackFor = SQLException.class，結果導致文件上傳成功了，但數據庫中的文件信息沒有回滾，出現了數據不一致的情況。

所以，當我們的方法可能拋出 Checked 異常時，一定要在@Transactional注解中指定需要回滾的異常類型，或者在方法內部捕獲異常并轉換為 RuntimeException，這樣才能讓事務回滾。

（二）異常被捕獲導致回滾失效

即使我們的方法可能拋出需要回滾的異常，如果在方法內部捕獲了這個異常并且沒有重新拋出，那么事務也不會回滾。

比如，我們在方法中使用了 try-catch 塊來處理異常，但是在 catch 塊中沒有調用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()方法，或者沒有重新拋出異常，那么事務會認為操作成功，從而提交事務。

正確的做法是，如果我們需要在捕獲異常后回滾事務，可以在 catch 塊中調用setRollbackOnly()方法，或者重新拋出異常（可以是原異常，也可以是包裝后的 RuntimeException）。

（三）自定義異常回滾問題

在實際開發中，我們可能會定義自己的異常類。這時候，如果自定義異常是 RuntimeException 的子類，那么@Transactional注解會默認回滾；如果是 Checked 異常，就需要像處理其他 Checked 異常一樣，在注解中指定回滾該異常。

需要注意的是，自定義異常的繼承結構一定要正確，否則可能會導致回滾策略不符合預期。比如，如果你定義了一個自定義異常MyException，并且讓它繼承自 Exception（Checked 異常），那么在沒有指定回滾該異常的情況下，事務不會回滾。

五、隔離級別和傳播行為的坑

（一）隔離級別設置不當

@Transactional注解可以通過isolation屬性來設置事務的隔離級別，不同的隔離級別會影響事務之間的可見性和數據一致性。如果隔離級別設置不當，可能會導致臟讀、不可重復讀、幻讀等問題。

比如，在默認情況下，Spring 的事務隔離級別是ISOLATION_DEFAULT，這取決于數據庫的默認隔離級別（MySQL 默認是可重復讀，Oracle 默認是讀已提交）。如果我們的業務對數據一致性要求很高，需要避免幻讀，就需要將隔離級別設置為ISOLATION_SERIALIZABLE，但這會影響系統的性能。

我曾經在一個庫存管理的業務中，沒有正確設置隔離級別，導致出現了超賣的問題。后來分析發現，是因為在高并發情況下，沒有使用合適的隔離級別，導致幻讀的發生，庫存數量被錯誤地修改。

所以，我們需要根據具體的業務場景來選擇合適的隔離級別，在數據一致性和性能之間找到平衡點。

（二）傳播行為理解錯誤

@Transactional注解的propagation屬性用于指定事務的傳播行為，即當一個事務方法被另一個事務方法調用時，如何處理事務的開啟和提交。如果對傳播行為理解錯誤，可能會導致事務范圍不正確，出現數據不一致的問題。

常見的傳播行為有REQUIRED（默認值，支持當前事務，如果沒有則新建一個）、SUPPORTS（支持當前事務，如果沒有則以非事務方式執行）、REQUIRES_NEW（新建一個事務，掛起當前事務）、NOT_SUPPORTED（以非事務方式執行，掛起當前事務）等。

比如，當我們在方法 A（使用REQUIRED傳播行為）中調用方法 B（使用REQUIRES_NEW傳播行為）時，方法 B 會新建一個事務，與方法 A 的事務無關。如果方法 B 執行失敗，只會回滾方法 B 的事務，不會影響方法 A 的事務；而如果方法 A 執行失敗，即使方法 B 已經提交，方法 A 的事務回滾也不會影響方法 B 的結果，因為它們是兩個不同的事務。

我之前在一個轉賬業務中，錯誤地使用了SUPPORTS傳播行為，導致在沒有外部事務的情況下，轉賬操作以非事務方式執行，當出現異常時，沒有回滾數據，造成了資金的損失。這真是一個深刻的教訓，所以大家一定要正確理解和使用事務的傳播行為。

六、數據庫方言的坑

（一）不同數據庫對事務的支持差異

不同的數據庫對事務的支持程度和語法略有不同。比如，MySQL 的 InnoDB 引擎支持事務，而 MyISAM 引擎不支持事務；Oracle 和 MySQL 在事務的隔離級別、鎖機制等方面也存在差異。

如果我們在使用@Transactional注解時，沒有考慮到數據庫的差異，可能會導致事務行為不符合預期。比如，在使用 MyISAM 引擎的表上使用@Transactional注解，事務會失效，因為該引擎根本不支持事務。

所以，在開發過程中，我們需要根據實際使用的數據庫來選擇合適的表引擎和事務配置，確保事務能夠正確生效。

（二）DDL 操作與事務

在一些數據庫中，DDL 操作（如創建表、修改表結構等）會自動提交事務，即使在事務塊中執行 DDL 操作，也會導致事務提交，后面的 DML 操作不會回滾。

比如，在 MySQL 中，執行 DDL 操作會隱式提交當前事務，所以如果我們在一個帶有@Transactional注解的方法中先執行 DML 操作，然后執行 DDL 操作，DML 操作會被提交，即使 DDL 操作失敗，DML 操作也不會回滾。

這就需要我們注意，不要在事務方法中混合執行 DDL 和 DML 操作，或者根據數據庫的特性來合理設計事務的范圍。

七、其他細節的坑

（一）@Transactional 注解在類上的作用

如果我們在類上添加@Transactional注解，那么該類中的所有 public 方法都會應用事務管理。但是，如果子類繼承了這個類，并且子類沒有重寫方法，那么子類的方法也會應用父類的事務注解；如果子類重寫了方法，子類的方法可以選擇是否添加自己的事務注解，來覆蓋父類的配置。

需要注意的是，在類上添加注解時，要確保該類是 Spring 容器管理的 bean，否則注解不會生效。

（二）事務超時設置

@Transactional注解可以通過timeout屬性來設置事務的超時時間，如果事務在指定的時間內沒有完成，會自動回滾。如果我們沒有設置超時時間，默認是使用底層事務系統的默認超時時間（比如數據庫的默認超時時間）。

在一些長時間運行的事務中，如果不設置超時時間，可能會導致事務長時間占用數據庫資源，影響系統的性能，甚至導致死鎖。所以，對于需要控制執行時間的事務，一定要設置合適的超時時間。

（三）只讀事務優化

如果我們的方法只是讀取數據，不會對數據進行修改，那么可以將@Transactional注解的readOnly屬性設置為true，這樣可以告訴數據庫使用只讀事務，數據庫可以進行一些優化，提高查詢性能。

這是一個容易被忽視的優化點，合理使用只讀事務可以在一定程度上提升系統的性能。

八、總結

說了這么多坑，相信大家對@Transactional注解有了更深入的理解。雖然@Transactional給我們帶來了很大的便利，但如果不正確使用，就會埋下很多隱患。

在使用@Transactional注解時，我們需要注意以下幾點：

1. 注解只能應用在 public 方法上，類內部方法調用需要通過代理對象來保證事務生效。
2. 正確處理異常，明確需要回滾的異常類型，避免異常被捕獲導致回滾失效。
3. 根據業務場景選擇合適的隔離級別和傳播行為，平衡數據一致性和性能。
4. 考慮數據庫的差異，選擇合適的表引擎和事務配置，避免 DDL 操作對事務的影響。
5. 注意其他細節，如類上注解的作用、事務超時設置、只讀事務優化等。

希望大家在今后的開發中，能夠避開這些坑，正確使用@Transactional注解，讓事務管理為我們的系統保駕護航。