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

一、@Transactional 基本概念回顧

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

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

二、注解生效條件的坑

（一）非 public 方法無(wú)效

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、異常處理的坑

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

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

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

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

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

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

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

比如，我們?cè)诜椒ㄖ惺褂昧?try-catch 塊來(lái)處理異常，但是在 catch 塊中沒(méi)有調(diào)用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()方法，或者沒(méi)有重新拋出異常，那么事務(wù)會(huì)認(rèn)為操作成功，從而提交事務(wù)。

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

（三）自定義異?；貪L問(wèn)題

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

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

五、隔離級(jí)別和傳播行為的坑

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

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

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

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

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

（二）傳播行為理解錯(cuò)誤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果我們?cè)陬惿咸砑覢Transactional注解，那么該類中的所有 public 方法都會(huì)應(yīng)用事務(wù)管理。但是，如果子類繼承了這個(gè)類，并且子類沒(méi)有重寫方法，那么子類的方法也會(huì)應(yīng)用父類的事務(wù)注解；如果子類重寫了方法，子類的方法可以選擇是否添加自己的事務(wù)注解，來(lái)覆蓋父類的配置。

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

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

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

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

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

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

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

八、總結(jié)

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

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

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

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