Spring Boot項目業(yè)務(wù)代碼中使用@Transactional事務(wù)失效踩坑點總結(jié)
1.概述
接著之前我們對Spring AOP以及基于AOP實現(xiàn)事務(wù)控制的上文，今天我們來看看平時在項目業(yè)務(wù)開發(fā)中使用聲明式事務(wù)@Transactional的失效場景，并分析其失效原因，從而幫助開發(fā)人員盡量避免踩坑。
我們知道 Spring 聲明式事務(wù)功能提供了極其方便的事務(wù)配置方式，配合 Spring Boot 的自動配置，大多數(shù) Spring Boot 項目只需要在方法上標(biāo)記 @Transactional 注解，即可一鍵開啟方法的事務(wù)性配置。當(dāng)然后端開發(fā)人員對數(shù)據(jù)庫事務(wù)這個概念并不陌生，也知道如果整體考慮多個數(shù)據(jù)庫操作要么成功要么失敗時，需要通過數(shù)據(jù)庫事務(wù)來實現(xiàn)多個操作的一致性和原子性。如下所示：
@Override
@Transactional(rollbackFor = Exception.class)
public void addUser(UserParam param) {
User user = PtcBeanUtils.copy(param, User.class);
userDAO.insert(user);
if (!CollectionUtils.isEmpty(param.getRoleIds())) {
userRoleService.addUserRole(user.getId(), param.getRoleIds());
}
}新增用戶的同時還添加了用戶角色，這里就是使用@Transactional來控制事務(wù)保證一致性的。但大多數(shù)開發(fā)僅限于為方法標(biāo)記 @Transactional來開啟聲明式事務(wù)，認(rèn)為就可以高枕無憂了，不會去關(guān)注事務(wù)是否有效、出錯后事務(wù)是否正確回滾，也不會考慮復(fù)雜的業(yè)務(wù)代碼中涉及多個子業(yè)務(wù)邏輯時，怎么正確處理事務(wù)。事務(wù)沒有被正確處理，一般來說不會過于影響正常流程，也不容易在測試階段被發(fā)現(xiàn)。但當(dāng)系統(tǒng)越來越復(fù)雜、壓力越來越大之后，就會帶來大量的數(shù)據(jù)不一致問題，隨后就是大量的人工介入查看和修復(fù)數(shù)據(jù)。
正是因為聲明式事務(wù)@Transactional使用簡單，所以很多開發(fā)人員不注重細(xì)節(jié)點，但是@Transactional條條框框還蠻多的，可謂是細(xì)節(jié)點拉滿，如果不注意也不小心就會掉進(jìn)坑里，今天就讓我們一起來了解使用細(xì)節(jié)，把坑填平咯。
2.@Transactional
話不多說，先看看該注解定義
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
@AliasFor("transactionManager")
String value() default "";
@AliasFor("value")
String transactionManager() default "";
Propagation propagation() default Propagation.REQUIRED;
Isolation isolation() default Isolation.DEFAULT;
int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
boolean readOnly() default false;
Class<? extends Throwable>[] rollbackFor() default {};
String[] rollbackForClassName() default {};
Class<? extends Throwable>[] noRollbackFor() default {};
String[] noRollbackForClassName() default {};
}從上面看出@Transactional既可以作用于類上，也可以作用于方法上，作用于類：表示所有該類的**public**方法都配置相同的事務(wù)屬性信息。接下來再看看其屬性：
propagation： 設(shè)置事務(wù)的傳播行為，主要解決是A方法調(diào)用B方法時，事務(wù)的傳播方式問題的，默認(rèn)值為 **Propagation.REQUIRED**，其他屬性值信息如下：
事務(wù)傳播行為 | 解釋 |
REQUIRED（默認(rèn)值） | A調(diào)用B，B需要事務(wù)，如果A有事務(wù)B就加入A的事務(wù)中，如果A沒有事務(wù)，B就自己創(chuàng)建一個事務(wù) |
REQUIRED_NEW | A調(diào)用B，B需要新事務(wù)，如果A有事務(wù)就掛起，B自己創(chuàng)建一個新的事務(wù) |
SUPPORTS | A調(diào)用B，B有無事務(wù)無所謂，A有事務(wù)就加入到A事務(wù)中，A無事務(wù)B就以非事務(wù)方式執(zhí)行 |
NOT_SUPPORTS | A調(diào)用B，B以無事務(wù)方式執(zhí)行，A如有事務(wù)則掛起 |
NEVER | A調(diào)用B，B以無事務(wù)方式執(zhí)行，A如有事務(wù)則拋出異常 |
MANDATORY | A調(diào)用B，B要加入A的事務(wù)中，如果A無事務(wù)就拋出異常 |
NESTED | A調(diào)用B，B創(chuàng)建一個新事務(wù)，A有事務(wù)就作為嵌套事務(wù)存在，A沒事務(wù)就以創(chuàng)建的新事務(wù)執(zhí)行 |
isolation ：事務(wù)的隔離級別，默認(rèn)值為 Isolation.DEFAULT。指定事務(wù)的隔離級別，事務(wù)并發(fā)存在三大問題：臟讀、不可重復(fù)讀、幻讀/虛讀。可以通過設(shè)置事務(wù)的隔離級別來保證并發(fā)問題的出現(xiàn)，常用的是READ_COMMITTED 和REPEATABLE_READ
isolation屬性 | 解釋 |
DEFAULT | 默認(rèn)隔離級別，取決于當(dāng)前數(shù)據(jù)庫隔離級別，例如MySQL默認(rèn)隔離級別是REPEATABLE_READ |
READ_UNCOMMITTED | A事務(wù)可以讀取到B事務(wù)尚未提交的事務(wù)記錄，不能解決任何并發(fā)問題，安全性最低，性能最高 |
READ_COMMITTED | A事務(wù)只能讀取到其他事務(wù)已經(jīng)提交的記錄，不能讀取到未提交的記錄?？梢越鉀Q臟讀問題，但是不能解決不可重復(fù)讀和幻讀 |
REPEATABLE_READ | A事務(wù)多次從數(shù)據(jù)庫讀取某條記錄結(jié)果一致，可以解決不可重復(fù)讀，不可以解決幻讀 |
SERIALIZABLE | 串行化，可以解決任何并發(fā)問題，安全性最高，但是性能最低 |
timeout ：事務(wù)的超時時間，默認(rèn)值為 -1。如果超過該時間限制但事務(wù)還沒有完成，則自動回滾事務(wù)。
readOnly：指定事務(wù)是否為只讀事務(wù)，默認(rèn)值為 false；為了忽略那些不需要事務(wù)的方法，比如讀取數(shù)據(jù)，可以設(shè)置 read-only 為 true。
rollbackFor：用于指定能夠觸發(fā)事務(wù)回滾的異常類型，可以指定多個異常類型。
noRollbackFor：拋出指定的異常類型，不回滾事務(wù)，也可以指定多個異常類型。
項目推薦：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企業(yè)級系統(tǒng)架構(gòu)底層框架封裝，解決業(yè)務(wù)開發(fā)時常見的非功能性需求，防止重復(fù)造輪子，方便業(yè)務(wù)快速開發(fā)和企業(yè)技術(shù)?？蚣芙y(tǒng)一管理。引入組件化的思想實現(xiàn)高內(nèi)聚低耦合并且高度可配置化，做到可插拔。嚴(yán)格控制包依賴和統(tǒng)一版本管理，做到最少化依賴。注重代碼規(guī)范和注釋，非常適合個人學(xué)習(xí)和企業(yè)使用
Github地址：https://github.com/plasticene/plasticene-boot-starter-parent
Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent
微信公眾號：Shepherd進(jìn)階筆記
交流探討qun：Shepherd_126
3.@Transactional失效場景、原因及修正方式
3.1 同一個類中的方法通過this調(diào)用導(dǎo)致失效
public void addUser(UserParam param) {
User user = PtcBeanUtils.copy(param, User.class);
// 新增用戶
userDAO.insert(user);
// 添加用戶角色
this.addUserRole(user.getId(), param.getRoleIds());
log.info("執(zhí)行結(jié)束了");
}
@Transactional(rollbackFor = Exception.class)
public void addUserRole(Long userId, List<Long> roleIds) {
if (CollectionUtils.isEmpty(roleIds)) {
return;
}
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new RuntimeException("發(fā)生異?？?);
}執(zhí)行#addUser()會發(fā)現(xiàn)事務(wù)控制失效，發(fā)生異常事務(wù)并沒有回滾，用戶和角色綁定都插入成功了。
這里，我給出@Transactional 生效原則 1，必須通過代理過的類從外部調(diào)用目標(biāo)方法才能生效.
圖片
Spring 是通過 AOP 技術(shù)對方法進(jìn)行增強實現(xiàn)事務(wù)控制的，要調(diào)用增強過的方法必然是調(diào)用代理后的對象，而這里this是原生對象，并不是代理，自然就沒有事務(wù)控制了。
修正方式：①：將this換成代理的userService, 可以自己注入自己@Resource private UserService userService，當(dāng)然也可以不用注入，直接在Spring容器中獲取userService這個bean ②將#addUser()方法開啟事務(wù)即加上@Transactional(rollbackFor = Exception.class)，這里本就該開啟，只是為了演示失效情況沒加上，因為在#addUser()里面有插入用戶的操作涉及到事務(wù)的所以本要開啟。當(dāng)然如果#addUser()只是做一些判斷、邏輯處理不涉及到數(shù)據(jù)庫事務(wù)操作，那么這樣解決就顯得有點不太合適，而且容易導(dǎo)致另一種事務(wù)失效的情況，即因為沒有正確處理異常，導(dǎo)致事務(wù)即便生效也不一定能回滾。
3.2 異常被catch“吃掉了”導(dǎo)致@Transactional失效
如下所示：
@Transactional(rollbackFor = Exception.class)
public void addUser(UserParam param) {
try {
User user = PtcBeanUtils.copy(param, User.class);
// 完成一些邏輯處理
.......
// 添加用戶角色
this.addUserRole(user.getId(), param.getRoleIds());
log.info("執(zhí)行結(jié)束了");
} catch (Exception e) {
log.error(e.getMessage());
}
}
@Transactional(rollbackFor = Exception.class)
public void addUserRole(Long userId, List<Long> roleIds) {
if (CollectionUtils.isEmpty(roleIds)) {
return;
}
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new RuntimeException("發(fā)生異?？?);
}@Transactional生效原則2：只有異常傳播出了標(biāo)記了 @Transactional 注解的方法，事務(wù)才能回滾。之前我們總結(jié)過 基于AOP事務(wù)控制實現(xiàn)原理說過在 Spring的 TransactionAspectSupport 里有個 invokeWithinTransaction 方法，里面就是處理事務(wù)的邏輯?？梢钥吹?，只有捕獲到異常才能進(jìn)行后續(xù)事務(wù)處理：
protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
final InvocationCallback invocation) throws Throwable {
......
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) {
// target invocation exception
// 捕獲到異常，進(jìn)行回滾操作，如果我們在業(yè)務(wù)方法已經(jīng)捕獲掉異常，這里就捕獲不到了，自然就不會回滾了
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
cleanupTransactionInfo(txInfo);
}
......
return result;
}
}可以看到，只有捕獲到異常時才進(jìn)行回滾操作，如果我們在業(yè)務(wù)方法已經(jīng)捕獲掉異常，這里就捕獲不到了，自然就不會回滾了。
修正方式：就是對異常捕獲盡量做到局部針對操作，不要籠統(tǒng)把整個方法的代碼邏輯都包括進(jìn)行，這樣異常就拋出去了。
3.3 @Transactional 屬性 rollbackFor 設(shè)置錯誤，導(dǎo)致異常不滿足回滾條件
直接看代碼：
@Transactional
public void addUser(UserParam param) {
User user = PtcBeanUtils.copy(param, User.class);
.......
// 添加用戶角色
this.addUserRole(user.getId(), param.getRoleIds());
log.info("執(zhí)行結(jié)束了");
}
public void addUserRole(Long userId, List<Long> roleIds) throws Exception {
if (CollectionUtils.isEmpty(roleIds)) {
return;
}
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new Exception("發(fā)生異常咯");
}這里#addUser()使用@transactional，但沒有設(shè)置rollbackFor屬性，且#addUserRole()拋出的異常是exception，不是RuntimeException，這樣事務(wù)也失效了，因為默認(rèn)情況下，出現(xiàn) RuntimeException（非受檢異常）或 Error 的時候，Spring才會回滾事務(wù)
從上面3.2小節(jié)的completeTransactionAfterThrowing(txInfo, ex);進(jìn)去完成回滾操作會判斷異常類型是否滿足規(guī)定，DefaultTransactionAttribute 類能看到如下代碼塊，可以發(fā)現(xiàn)相關(guān)證據(jù)，通過注釋也能看到 Spring 這么做的原因，大概的意思是受檢異常一般是業(yè)務(wù)異常，或者說是類似另一種方法的返回值，出現(xiàn)這樣的異?？赡軜I(yè)務(wù)還能完成，所以不會主動回滾；而Error 或 RuntimeException 代表了非預(yù)期的結(jié)果，應(yīng)該回滾：
public boolean rollbackOn(Throwable ex) {
return (ex instanceof RuntimeException || ex instanceof Error);
}修正方法：設(shè)置rollbackFor：@Transactional(rollbackFor = Exception.class)
3.4 @Transactional 應(yīng)用在非 public 修飾的方法上
@Transactional(rollbackFor = Exception.class)
private void addUserRole(Long userId, List<Long> roleIds) {
if (CollectionUtils.isEmpty(roleIds)) {
return;
}
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new RuntimeException("發(fā)生異常咯");
}idea也會提示爆紅：
圖片
Spring通過CGLIB動態(tài)代理來增強生產(chǎn)代理對象，CGLIB 通過繼承方式實現(xiàn)代理類，private 方法在子類不可見，自然也就無法進(jìn)行事務(wù)增強。s在基于AOP事務(wù)控制實現(xiàn)原理一文中也分析過，會調(diào)用到AbstractFallbackTransactionAttributeSource的computeTransactionAttribute()方法
@Nullable
protected TransactionAttribute computeTransactionAttribute(Method method, @Nullable Class<?> targetClass) {
// Don't allow no-public methods as required.
if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
return null;
}
......
}修正方式：自然是改成public
3.5 @Transactional 注解傳播屬性 propagation 設(shè)置錯誤
如上面我們新增的用戶的同時要添加用戶角色，但是假如我們希望即使添加角色錯誤了，還可以正常新增用戶。
public void addUser(UserParam param) {
String username = param.getUsername();
checkUsernameUnique(username);
User user = PtcBeanUtils.copy(param, User.class);
// 添加用戶
userDAO.insert(user);
// 添加用戶角色
userRoleService.addUserRole(user.getId(), param.getRoleIds());
}#userRoleService.addUserRole()
@Transactional(rollbackFor = Exception.class)
private void addUserRole(Long userId, List<Long> roleIds) {
if (CollectionUtils.isEmpty(roleIds)) {
return;
}
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new RuntimeException("發(fā)生異?？?);
}你會發(fā)現(xiàn)只會同時插入失敗，無法實現(xiàn)上面所說的。這時候你可能會想到，既然addUserRole()拋出了異常不能插入用戶角色，但是addUser()不想受影響，正常添加用戶，那么何不在addUser()里面對userRoleService.addUserRole()進(jìn)行異常捕獲，不就可以解決問題了嗎？真是如此嗎，就讓我們來驗證一下：
@Transactional(rollbackFor = Exception.class)
public void addUser(UserParam param) {
User user = PtcBeanUtils.copy(param, User.class);
// 添加用戶
userDAO.insert(user);
// 添加用戶角色
try {
userRoleService.addUserRole(user.getId(), param.getRoleIds());
} catch (Exception e) {
log.error(e.getMessage());
}
}執(zhí)行會發(fā)現(xiàn)，用戶同樣沒有添加成功，看日志報錯：
[1689568520410750976] [ERROR] [2023-08-10 17:25:02.023] [http-nio-18888-exec-1@56682] com.plasticene.fast.service.impl.UserServiceImpl addUser : 發(fā)生異?？?[1689568520410750976] [ERROR] [2023-08-10 17:25:02.097] [http-nio-18888-exec-1@56682] com.plasticene.boot.web.core.global.GlobalExceptionHandler exceptionHandler : 【系統(tǒng)異?！?org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:870)可以看到發(fā)生異常咯是我們在addUser()中捕獲到輸出的，但是緊接著下一行發(fā)現(xiàn)有報出一個異常UnexpectedRollbackException。
原因是，主方法添加用戶的邏輯和子方法添加用戶角色的邏輯是同一個事務(wù)，子邏輯標(biāo)記了事務(wù)需要回滾，主邏輯自然也不能提交了。
修正方式：其實要想新增用戶角色失敗不影響添加用戶，只需要讓新增用戶角色單獨開啟一個新事務(wù)即可。
@Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)
public void addUserRole(Long userId, List<Long> roleIds) {
List<UserRole> userRoles = new ArrayList<>();
roleIds.forEach(roleId -> {
UserRole userRole = new UserRole();
userRole.setUserId(userId);
userRole.setRoleId(roleId);
userRoles.add(userRole);
});
userRoleDAO.insertBatch(userRoles);
throw new RuntimeException("發(fā)生異常啦！");
}3.6 @Transactional長事務(wù)導(dǎo)致生產(chǎn)事故
很多開發(fā)都覺得Spring的聲明式事務(wù)使用非常簡單，即@Transactional，所以從來不注重細(xì)節(jié)。當(dāng) Spring 遇到該注解時，會自動從數(shù)據(jù)庫連接池中獲取 connection，并開啟事務(wù)然后綁定到 ThreadLocal 上，對于@Transactional注解包裹的整個方法都是使用同一個connection連接。如果我們出現(xiàn)了耗時的操作，比如第三方接口調(diào)用、業(yè)務(wù)邏輯復(fù)雜、大批量數(shù)據(jù)處理等就會導(dǎo)致我們我們占用這個connection的時間會很長，數(shù)據(jù)庫連接一直被占用不釋放。一旦類似操作過多，就會導(dǎo)致數(shù)據(jù)庫連接池耗盡。這就是典型的長事務(wù)問題
長事務(wù)引發(fā)的常見危害有：
- 數(shù)據(jù)庫連接池被占滿，應(yīng)用無法獲取連接資源；
- 容易引發(fā)數(shù)據(jù)庫死鎖；
- 數(shù)據(jù)庫回滾時間長；
- 在主從架構(gòu)中會導(dǎo)致主從延時變大。
服務(wù)系統(tǒng)開始出現(xiàn)故障：數(shù)據(jù)庫監(jiān)控平臺一直收到告警短信，數(shù)據(jù)庫連接不足，出現(xiàn)大量死鎖；日志顯示調(diào)用流程引擎接口出現(xiàn)大量超時；同時一直提示CannotGetJdbcConnectionException，數(shù)據(jù)庫連接池連接占滿。
要想解決這個問題其實也不難，只需要對方法進(jìn)行拆分，將不需要事務(wù)管理的邏輯與事務(wù)操作分開，這樣就可以有效控制事務(wù)的時長從而避免長事務(wù)。當(dāng)然對一個方法邏輯拆分成多個子方法很有可能造成上面敘述的事務(wù)不生效的情況，不過我相信你看到上面的總結(jié)肯定沒問題啦。
4.總結(jié)
Spring的聲明式事務(wù)使用@Transactional注解在開發(fā)時確實很方便，但是稍有不慎使用不當(dāng)就會導(dǎo)致事務(wù)失效數(shù)據(jù)不一致、甚至是系統(tǒng)數(shù)據(jù)庫性能問題。所以上面滿滿的干貨總結(jié)都是出自日常工作中碰到的，有效幫你避坑。
本文轉(zhuǎn)載自微信公眾號「Shepherd進(jìn)階筆記」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系公眾號。
