Spring Boot項(xiàng)目業(yè)務(wù)代碼中使用@Transactional事務(wù)失效踩坑點(diǎn)總結(jié)

作者：Shepherd 2023-09-08 08:52:12

Spring的聲明式事務(wù)使用@Transactional注解在開發(fā)時(shí)確實(shí)很方便，但是稍有不慎使用不當(dāng)就會(huì)導(dǎo)致事務(wù)失效數(shù)據(jù)不一致、甚至是系統(tǒng)數(shù)據(jù)庫性能問題。所以上面滿滿的干貨總結(jié)都是出自日常工作中碰到的，有效幫你避坑。

1.概述

接著之前我們對(duì)Spring AOP以及基于AOP實(shí)現(xiàn)事務(wù)控制的上文，今天我們來看看平時(shí)在項(xiàng)目業(yè)務(wù)開發(fā)中使用聲明式事務(wù)@Transactional的失效場(chǎng)景，并分析其失效原因，從而幫助開發(fā)人員盡量避免踩坑。

我們知道 Spring 聲明式事務(wù)功能提供了極其方便的事務(wù)配置方式，配合 Spring Boot 的自動(dòng)配置，大多數(shù) Spring Boot 項(xiàng)目只需要在方法上標(biāo)記 @Transactional 注解，即可一鍵開啟方法的事務(wù)性配置。當(dāng)然后端開發(fā)人員對(duì)數(shù)據(jù)庫事務(wù)這個(gè)概念并不陌生，也知道如果整體考慮多個(gè)數(shù)據(jù)庫操作要么成功要么失敗時(shí)，需要通過數(shù)據(jù)庫事務(wù)來實(shí)現(xiàn)多個(gè)操作的一致性和原子性。如下所示：

@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());
        }
    }

新增用戶的同時(shí)還添加了用戶角色，這里就是使用@Transactional來控制事務(wù)保證一致性的。但大多數(shù)開發(fā)僅限于為方法標(biāo)記 @Transactional來開啟聲明式事務(wù)，認(rèn)為就可以高枕無憂了，不會(huì)去關(guān)注事務(wù)是否有效、出錯(cuò)后事務(wù)是否正確回滾，也不會(huì)考慮復(fù)雜的業(yè)務(wù)代碼中涉及多個(gè)子業(yè)務(wù)邏輯時(shí)，怎么正確處理事務(wù)。事務(wù)沒有被正確處理，一般來說不會(huì)過于影響正常流程，也不容易在測(cè)試階段被發(fā)現(xiàn)。但當(dāng)系統(tǒng)越來越復(fù)雜、壓力越來越大之后，就會(huì)帶來大量的數(shù)據(jù)不一致問題，隨后就是大量的人工介入查看和修復(fù)數(shù)據(jù)。

正是因?yàn)槁暶魇绞聞?wù)@Transactional使用簡(jiǎn)單，所以很多開發(fā)人員不注重細(xì)節(jié)點(diǎn)，但是@Transactional條條框框還蠻多的，可謂是細(xì)節(jié)點(diǎn)拉滿，如果不注意也不小心就會(huì)掉進(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方法時(shí)，事務(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)建一個(gè)事務(wù)
REQUIRED_NEW	A調(diào)用B，B需要新事務(wù)，如果A有事務(wù)就掛起，B自己創(chuàng)建一個(gè)新的事務(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)建一個(gè)新事務(wù)，A有事務(wù)就作為嵌套事務(wù)存在，A沒事務(wù)就以創(chuàng)建的新事務(wù)執(zhí)行

isolation ：事務(wù)的隔離級(jí)別，默認(rèn)值為 Isolation.DEFAULT。指定事務(wù)的隔離級(jí)別，事務(wù)并發(fā)存在三大問題：臟讀、不可重復(fù)讀、幻讀/虛讀。可以通過設(shè)置事務(wù)的隔離級(jí)別來保證并發(fā)問題的出現(xiàn)，常用的是READ_COMMITTED 和REPEATABLE_READ

isolation屬性	解釋
DEFAULT	默認(rèn)隔離級(jí)別，取決于當(dāng)前數(shù)據(jù)庫隔離級(jí)別，例如MySQL默認(rèn)隔離級(jí)別是REPEATABLE_READ
READ_UNCOMMITTED	A事務(wù)可以讀取到B事務(wù)尚未提交的事務(wù)記錄，不能解決任何并發(fā)問題，安全性最低，性能最高
READ_COMMITTED	A事務(wù)只能讀取到其他事務(wù)已經(jīng)提交的記錄，不能讀取到未提交的記錄。可以解決臟讀問題，但是不能解決不可重復(fù)讀和幻讀
REPEATABLE_READ	A事務(wù)多次從數(shù)據(jù)庫讀取某條記錄結(jié)果一致，可以解決不可重復(fù)讀，不可以解決幻讀
SERIALIZABLE	串行化，可以解決任何并發(fā)問題，安全性最高，但是性能最低

timeout ：事務(wù)的超時(shí)時(shí)間，默認(rèn)值為 -1。如果超過該時(shí)間限制但事務(wù)還沒有完成，則自動(dòng)回滾事務(wù)。

readOnly：指定事務(wù)是否為只讀事務(wù)，默認(rèn)值為 false；為了忽略那些不需要事務(wù)的方法，比如讀取數(shù)據(jù)，可以設(shè)置 read-only 為 true。

rollbackFor：用于指定能夠觸發(fā)事務(wù)回滾的異常類型，可以指定多個(gè)異常類型。

noRollbackFor：拋出指定的異常類型，不回滾事務(wù)，也可以指定多個(gè)異常類型。

項(xiàng)目推薦：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企業(yè)級(jí)系統(tǒng)架構(gòu)底層框架封裝，解決業(yè)務(wù)開發(fā)時(shí)常見的非功能性需求，防止重復(fù)造輪子，方便業(yè)務(wù)快速開發(fā)和企業(yè)技術(shù)棧框架統(tǒng)一管理。引入組件化的思想實(shí)現(xiàn)高內(nèi)聚低耦合并且高度可配置化，做到可插拔。嚴(yán)格控制包依賴和統(tǒng)一版本管理，做到最少化依賴。注重代碼規(guī)范和注釋，非常適合個(gè)人學(xué)習(xí)和企業(yè)使用
Github地址：https://github.com/plasticene/plasticene-boot-starter-parent
Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent
微信公眾號(hào)：Shepherd進(jìn)階筆記
交流探討qun：Shepherd_126

3.@Transactional失效場(chǎng)景、原因及修正方式

3.1 同一個(gè)類中的方法通過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()會(huì)發(fā)現(xiàn)事務(wù)控制失效，發(fā)生異常事務(wù)并沒有回滾，用戶和角色綁定都插入成功了。

這里，我給出@Transactional 生效原則 1，必須通過代理過的類從外部調(diào)用目標(biāo)方法才能生效.

圖片

Spring 是通過 AOP 技術(shù)對(duì)方法進(jìn)行增強(qiáng)實(shí)現(xiàn)事務(wù)控制的，要調(diào)用增強(qiáng)過的方法必然是調(diào)用代理后的對(duì)象，而這里this是原生對(duì)象，并不是代理，自然就沒有事務(wù)控制了。

修正方式：①：將this換成代理的userService, 可以自己注入自己@Resource private UserService userService，當(dāng)然也可以不用注入，直接在Spring容器中獲取userService這個(gè)bean ②將#addUser()方法開啟事務(wù)即加上@Transactional(rollbackFor = Exception.class)，這里本就該開啟，只是為了演示失效情況沒加上，因?yàn)樵?addUser()里面有插入用戶的操作涉及到事務(wù)的所以本要開啟。當(dāng)然如果#addUser()只是做一些判斷、邏輯處理不涉及到數(shù)據(jù)庫事務(wù)操作，那么這樣解決就顯得有點(diǎn)不太合適，而且容易導(dǎo)致另一種事務(wù)失效的情況，即因?yàn)闆]有正確處理異常，導(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ù)控制實(shí)現(xiàn)原理說過在 Spring的 TransactionAspectSupport 里有個(gè) 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)行回滾操作，如果我們?cè)跇I(yè)務(wù)方法已經(jīng)捕獲掉異常，這里就捕獲不到了，自然就不會(huì)回滾了
    completeTransactionAfterThrowing(txInfo, ex);
    throw ex;
   }
   finally {
    cleanupTransactionInfo(txInfo);
   }
    
    ......
        
   return result;
  }
 }

可以看到，只有捕獲到異常時(shí)才進(jìn)行回滾操作，如果我們?cè)跇I(yè)務(wù)方法已經(jīng)捕獲掉異常，這里就捕獲不到了，自然就不會(huì)回滾了。

修正方式：就是對(duì)異常捕獲盡量做到局部針對(duì)操作，不要籠統(tǒng)把整個(gè)方法的代碼邏輯都包括進(jìn)行，這樣異常就拋出去了。

3.3 @Transactional 屬性 rollbackFor 設(shè)置錯(cuò)誤，導(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ù)也失效了，因?yàn)槟J(rèn)情況下，出現(xiàn) RuntimeException（非受檢異常）或 Error 的時(shí)候，Spring才會(huì)回滾事務(wù)

從上面3.2小節(jié)的completeTransactionAfterThrowing(txInfo, ex);進(jìn)去完成回滾操作會(huì)判斷異常類型是否滿足規(guī)定，DefaultTransactionAttribute 類能看到如下代碼塊，可以發(fā)現(xiàn)相關(guān)證據(jù)，通過注釋也能看到 Spring 這么做的原因，大概的意思是受檢異常一般是業(yè)務(wù)異常，或者說是類似另一種方法的返回值，出現(xiàn)這樣的異常可能業(yè)務(wù)還能完成，所以不會(huì)主動(dòng)回滾；而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也會(huì)提示爆紅：

圖片

Spring通過CGLIB動(dòng)態(tài)代理來增強(qiáng)生產(chǎn)代理對(duì)象，CGLIB 通過繼承方式實(shí)現(xiàn)代理類，private 方法在子類不可見，自然也就無法進(jìn)行事務(wù)增強(qiáng)。s在基于AOP事務(wù)控制實(shí)現(xiàn)原理一文中也分析過，會(huì)調(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è)置錯(cuò)誤

如上面我們新增的用戶的同時(shí)要添加用戶角色，但是假如我們希望即使添加角色錯(cuò)誤了，還可以正常新增用戶。

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ā)生異常咯");
  }

你會(huì)發(fā)現(xiàn)只會(huì)同時(shí)插入失敗，無法實(shí)現(xiàn)上面所說的。這時(shí)候你可能會(huì)想到，既然addUserRole()拋出了異常不能插入用戶角色，但是addUser()不想受影響，正常添加用戶，那么何不在addUser()里面對(duì)userRoleService.addUserRole()進(jìn)行異常捕獲，不就可以解決問題了嗎？真是如此嗎，就讓我們來驗(yà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í)行會(huì)發(fā)現(xiàn)，用戶同樣沒有添加成功，看日志報(bào)錯(cuò)：

[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ā)生異常咯是我們?cè)赼ddUser()中捕獲到輸出的，但是緊接著下一行發(fā)現(xiàn)有報(bào)出一個(gè)異常UnexpectedRollbackException。

原因是，主方法添加用戶的邏輯和子方法添加用戶角色的邏輯是同一個(gè)事務(wù)，子邏輯標(biāo)記了事務(wù)需要回滾，主邏輯自然也不能提交了。

修正方式：其實(shí)要想新增用戶角色失敗不影響添加用戶，只需要讓新增用戶角色單獨(dú)開啟一個(gè)新事務(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長(zhǎng)事務(wù)導(dǎo)致生產(chǎn)事故

很多開發(fā)都覺得Spring的聲明式事務(wù)使用非常簡(jiǎn)單，即@Transactional，所以從來不注重細(xì)節(jié)。當(dāng) Spring 遇到該注解時(shí)，會(huì)自動(dòng)從數(shù)據(jù)庫連接池中獲取 connection，并開啟事務(wù)然后綁定到 ThreadLocal 上，對(duì)于@Transactional注解包裹的整個(gè)方法都是使用同一個(gè)connection連接。如果我們出現(xiàn)了耗時(shí)的操作，比如第三方接口調(diào)用、業(yè)務(wù)邏輯復(fù)雜、大批量數(shù)據(jù)處理等就會(huì)導(dǎo)致我們我們占用這個(gè)connection的時(shí)間會(huì)很長(zhǎng)，數(shù)據(jù)庫連接一直被占用不釋放。一旦類似操作過多，就會(huì)導(dǎo)致數(shù)據(jù)庫連接池耗盡。這就是典型的長(zhǎng)事務(wù)問題

長(zhǎng)事務(wù)引發(fā)的常見危害有：

數(shù)據(jù)庫連接池被占滿，應(yīng)用無法獲取連接資源；
容易引發(fā)數(shù)據(jù)庫死鎖；
數(shù)據(jù)庫回滾時(shí)間長(zhǎng)；
在主從架構(gòu)中會(huì)導(dǎo)致主從延時(shí)變大。

服務(wù)系統(tǒng)開始出現(xiàn)故障：數(shù)據(jù)庫監(jiān)控平臺(tái)一直收到告警短信，數(shù)據(jù)庫連接不足，出現(xiàn)大量死鎖；日志顯示調(diào)用流程引擎接口出現(xiàn)大量超時(shí)；同時(shí)一直提示CannotGetJdbcConnectionException，數(shù)據(jù)庫連接池連接占滿。

要想解決這個(gè)問題其實(shí)也不難，只需要對(duì)方法進(jìn)行拆分，將不需要事務(wù)管理的邏輯與事務(wù)操作分開，這樣就可以有效控制事務(wù)的時(shí)長(zhǎng)從而避免長(zhǎng)事務(wù)。當(dāng)然對(duì)一個(gè)方法邏輯拆分成多個(gè)子方法很有可能造成上面敘述的事務(wù)不生效的情況，不過我相信你看到上面的總結(jié)肯定沒問題啦。