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

一、@Transactional 基本概念回顧

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

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

二、注解生效條件的坑

（一）非 public 方法無效

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

我就曾經(jīng)犯過這樣的錯誤，在一個工具類里寫了一個 private 方法，加上了@Transactional注解，結(jié)果發(fā)現(xiàn)事務(wù)根本沒有生效，數(shù)據(jù)出現(xiàn)了不一致的情況。當(dāng)時(shí)找了好久的原因，最后才發(fā)現(xiàn)是方法訪問修飾符的問題。

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

（二）類內(nèi)部方法調(diào)用失效

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

當(dāng)我們在同一個類內(nèi)部調(diào)用方法時(shí)，Spring 的事務(wù)代理機(jī)制不會起作用，因?yàn)榇藭r(shí)調(diào)用的是目標(biāo)對象本身，而不是代理對象。所以，updateUser方法中的操作不會被納入到事務(wù)管理中，如果在updateUser方法中出現(xiàn)異常，不會觸發(fā)事務(wù)的回滾。

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

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

三、方法調(diào)用方式的坑

（一）異步調(diào)用事務(wù)失效

在實(shí)際開發(fā)中，我們可能會使用異步方法來提高系統(tǒng)的性能，比如使用@Async注解來標(biāo)記異步方法。這時(shí)候，如果在異步方法上使用了@Transactional注解，需要注意事務(wù)可能會失效。

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

我之前在處理一個發(fā)送短信的業(yè)務(wù)時(shí)，為了不阻塞主線程，將發(fā)送短信的方法標(biāo)記為異步方法，并且加上了@Transactional注解，希望在發(fā)送短信失敗時(shí)回滾相關(guān)的業(yè)務(wù)操作。結(jié)果發(fā)現(xiàn)，即使發(fā)送短信拋出了異常，相關(guān)的業(yè)務(wù)操作也沒有回滾，就是因?yàn)楫惒秸{(diào)用導(dǎo)致事務(wù)失效了。

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

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

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

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

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

四、異常處理的坑

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

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

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

我曾經(jīng)在處理一個文件上傳的業(yè)務(wù)時(shí)，需要同時(shí)將文件信息保存到數(shù)據(jù)庫中。在保存數(shù)據(jù)庫時(shí)，可能會因?yàn)槲ㄒ患s束沖突拋出 SQLException，而我沒有在方法上添加rollbackFor = SQLException.class，結(jié)果導(dǎo)致文件上傳成功了，但數(shù)據(jù)庫中的文件信息沒有回滾，出現(xiàn)了數(shù)據(jù)不一致的情況。

所以，當(dāng)我們的方法可能拋出 Checked 異常時(shí)，一定要在@Transactional注解中指定需要回滾的異常類型，或者在方法內(nèi)部捕獲異常并轉(zhuǎn)換為 RuntimeException，這樣才能讓事務(wù)回滾。

（二）異常被捕獲導(dǎo)致回滾失效

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

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

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

（三）自定義異?；貪L問題

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

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

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

（一）隔離級別設(shè)置不當(dāng)

@Transactional注解可以通過isolation屬性來設(shè)置事務(wù)的隔離級別，不同的隔離級別會影響事務(wù)之間的可見性和數(shù)據(jù)一致性。如果隔離級別設(shè)置不當(dāng)，可能會導(dǎo)致臟讀、不可重復(fù)讀、幻讀等問題。

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

我曾經(jīng)在一個庫存管理的業(yè)務(wù)中，沒有正確設(shè)置隔離級別，導(dǎo)致出現(xiàn)了超賣的問題。后來分析發(fā)現(xiàn)，是因?yàn)樵诟卟l(fā)情況下，沒有使用合適的隔離級別，導(dǎo)致幻讀的發(fā)生，庫存數(shù)量被錯誤地修改。

所以，我們需要根據(jù)具體的業(yè)務(wù)場景來選擇合適的隔離級別，在數(shù)據(jù)一致性和性能之間找到平衡點(diǎn)。

（二）傳播行為理解錯誤

@Transactional注解的propagation屬性用于指定事務(wù)的傳播行為，即當(dāng)一個事務(wù)方法被另一個事務(wù)方法調(diào)用時(shí)，如何處理事務(wù)的開啟和提交。如果對傳播行為理解錯誤，可能會導(dǎo)致事務(wù)范圍不正確，出現(xiàn)數(shù)據(jù)不一致的問題。

常見的傳播行為有REQUIRED（默認(rèn)值，支持當(dāng)前事務(wù)，如果沒有則新建一個）、SUPPORTS（支持當(dāng)前事務(wù)，如果沒有則以非事務(wù)方式執(zhí)行）、REQUIRES_NEW（新建一個事務(wù)，掛起當(dāng)前事務(wù)）、NOT_SUPPORTED（以非事務(wù)方式執(zhí)行，掛起當(dāng)前事務(wù)）等。

比如，當(dāng)我們在方法 A（使用REQUIRED傳播行為）中調(diào)用方法 B（使用REQUIRES_NEW傳播行為）時(shí)，方法 B 會新建一個事務(wù)，與方法 A 的事務(wù)無關(guān)。如果方法 B 執(zhí)行失敗，只會回滾方法 B 的事務(wù)，不會影響方法 A 的事務(wù)；而如果方法 A 執(zhí)行失敗，即使方法 B 已經(jīng)提交，方法 A 的事務(wù)回滾也不會影響方法 B 的結(jié)果，因?yàn)樗鼈兪莾蓚€不同的事務(wù)。

我之前在一個轉(zhuǎn)賬業(yè)務(wù)中，錯誤地使用了SUPPORTS傳播行為，導(dǎo)致在沒有外部事務(wù)的情況下，轉(zhuǎn)賬操作以非事務(wù)方式執(zhí)行，當(dāng)出現(xiàn)異常時(shí)，沒有回滾數(shù)據(jù)，造成了資金的損失。這真是一個深刻的教訓(xùn)，所以大家一定要正確理解和使用事務(wù)的傳播行為。

六、數(shù)據(jù)庫方言的坑

（一）不同數(shù)據(jù)庫對事務(wù)的支持差異

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

如果我們在使用@Transactional注解時(shí)，沒有考慮到數(shù)據(jù)庫的差異，可能會導(dǎo)致事務(wù)行為不符合預(yù)期。比如，在使用 MyISAM 引擎的表上使用@Transactional注解，事務(wù)會失效，因?yàn)樵撘娓静恢С质聞?wù)。

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

（二）DDL 操作與事務(wù)

在一些數(shù)據(jù)庫中，DDL 操作（如創(chuàng)建表、修改表結(jié)構(gòu)等）會自動提交事務(wù)，即使在事務(wù)塊中執(zhí)行 DDL 操作，也會導(dǎo)致事務(wù)提交，后面的 DML 操作不會回滾。

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

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

七、其他細(xì)節(jié)的坑

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

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

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

（二）事務(wù)超時(shí)設(shè)置

@Transactional注解可以通過timeout屬性來設(shè)置事務(wù)的超時(shí)時(shí)間，如果事務(wù)在指定的時(shí)間內(nèi)沒有完成，會自動回滾。如果我們沒有設(shè)置超時(shí)時(shí)間，默認(rèn)是使用底層事務(wù)系統(tǒng)的默認(rèn)超時(shí)時(shí)間（比如數(shù)據(jù)庫的默認(rèn)超時(shí)時(shí)間）。

在一些長時(shí)間運(yùn)行的事務(wù)中，如果不設(shè)置超時(shí)時(shí)間，可能會導(dǎo)致事務(wù)長時(shí)間占用數(shù)據(jù)庫資源，影響系統(tǒng)的性能，甚至導(dǎo)致死鎖。所以，對于需要控制執(zhí)行時(shí)間的事務(wù)，一定要設(shè)置合適的超時(shí)時(shí)間。

（三）只讀事務(wù)優(yōu)化

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

這是一個容易被忽視的優(yōu)化點(diǎn)，合理使用只讀事務(wù)可以在一定程度上提升系統(tǒng)的性能。

八、總結(jié)

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

在使用@Transactional注解時(shí)，我們需要注意以下幾點(diǎn)：

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

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