Spring Boot項目業務代碼中使用@Transactional事務失效踩坑點總結

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

Spring的聲明式事務使用@Transactional注解在開發時確實很方便，但是稍有不慎使用不當就會導致事務失效數據不一致、甚至是系統數據庫性能問題。所以上面滿滿的干貨總結都是出自日常工作中碰到的，有效幫你避坑。

1.概述

接著之前我們對Spring AOP以及基于AOP實現事務控制的上文，今天我們來看看平時在項目業務開發中使用聲明式事務@Transactional的失效場景，并分析其失效原因，從而幫助開發人員盡量避免踩坑。

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

@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來控制事務保證一致性的。但大多數開發僅限于為方法標記 @Transactional來開啟聲明式事務，認為就可以高枕無憂了，不會去關注事務是否有效、出錯后事務是否正確回滾，也不會考慮復雜的業務代碼中涉及多個子業務邏輯時，怎么正確處理事務。事務沒有被正確處理，一般來說不會過于影響正常流程，也不容易在測試階段被發現。但當系統越來越復雜、壓力越來越大之后，就會帶來大量的數據不一致問題，隨后就是大量的人工介入查看和修復數據。

正是因為聲明式事務@Transactional使用簡單，所以很多開發人員不注重細節點，但是@Transactional條條框框還蠻多的，可謂是細節點拉滿，如果不注意也不小心就會掉進坑里，今天就讓我們一起來了解使用細節，把坑填平咯。

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**方法都配置相同的事務屬性信息。接下來再看看其屬性：

propagation：設置事務的傳播行為，主要解決是A方法調用B方法時，事務的傳播方式問題的，默認值為 **Propagation.REQUIRED**，其他屬性值信息如下：

事務傳播行為	解釋
REQUIRED（默認值）	A調用B，B需要事務，如果A有事務B就加入A的事務中，如果A沒有事務，B就自己創建一個事務
REQUIRED_NEW	A調用B，B需要新事務，如果A有事務就掛起，B自己創建一個新的事務
SUPPORTS	A調用B，B有無事務無所謂，A有事務就加入到A事務中，A無事務B就以非事務方式執行
NOT_SUPPORTS	A調用B，B以無事務方式執行，A如有事務則掛起
NEVER	A調用B，B以無事務方式執行，A如有事務則拋出異常
MANDATORY	A調用B，B要加入A的事務中，如果A無事務就拋出異常
NESTED	A調用B，B創建一個新事務，A有事務就作為嵌套事務存在，A沒事務就以創建的新事務執行

isolation ：事務的隔離級別，默認值為 Isolation.DEFAULT。指定事務的隔離級別，事務并發存在三大問題：臟讀、不可重復讀、幻讀/虛讀。可以通過設置事務的隔離級別來保證并發問題的出現，常用的是READ_COMMITTED 和REPEATABLE_READ

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

timeout ：事務的超時時間，默認值為 -1。如果超過該時間限制但事務還沒有完成，則自動回滾事務。

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

rollbackFor：用于指定能夠觸發事務回滾的異常類型，可以指定多個異常類型。

noRollbackFor：拋出指定的異常類型，不回滾事務，也可以指定多個異常類型。

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

3.@Transactional失效場景、原因及修正方式

3.1 同一個類中的方法通過this調用導致失效

public void addUser(UserParam param) {
        User user = PtcBeanUtils.copy(param, User.class);
        // 新增用戶
        userDAO.insert(user);
        // 添加用戶角色
        this.addUserRole(user.getId(), param.getRoleIds());
        log.info("執行結束了");
    }

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

執行#addUser()會發現事務控制失效，發生異常事務并沒有回滾，用戶和角色綁定都插入成功了。

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

圖片

Spring 是通過 AOP 技術對方法進行增強實現事務控制的，要調用增強過的方法必然是調用代理后的對象，而這里this是原生對象，并不是代理，自然就沒有事務控制了。

修正方式：①：將this換成代理的userService, 可以自己注入自己@Resource private UserService userService，當然也可以不用注入，直接在Spring容器中獲取userService這個bean ②將#addUser()方法開啟事務即加上@Transactional(rollbackFor = Exception.class)，這里本就該開啟，只是為了演示失效情況沒加上，因為在#addUser()里面有插入用戶的操作涉及到事務的所以本要開啟。當然如果#addUser()只是做一些判斷、邏輯處理不涉及到數據庫事務操作，那么這樣解決就顯得有點不太合適，而且容易導致另一種事務失效的情況，即因為沒有正確處理異常，導致事務即便生效也不一定能回滾。

3.2 異常被catch“吃掉了”導致@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("執行結束了");
        } 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("發生異常咯");
    }

@Transactional生效原則2：只有異常傳播出了標記了 @Transactional 注解的方法，事務才能回滾。之前我們總結過基于AOP事務控制實現原理說過在 Spring的 TransactionAspectSupport 里有個 invokeWithinTransaction 方法，里面就是處理事務的邏輯。可以看到，只有捕獲到異常才能進行后續事務處理：

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
        // 捕獲到異常，進行回滾操作，如果我們在業務方法已經捕獲掉異常，這里就捕獲不到了，自然就不會回滾了
    completeTransactionAfterThrowing(txInfo, ex);
    throw ex;
   }
   finally {
    cleanupTransactionInfo(txInfo);
   }
    
    ......
        
   return result;
  }
 }

可以看到，只有捕獲到異常時才進行回滾操作，如果我們在業務方法已經捕獲掉異常，這里就捕獲不到了，自然就不會回滾了。

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

3.3 @Transactional 屬性 rollbackFor 設置錯誤，導致異常不滿足回滾條件

直接看代碼：

@Transactional
  public void addUser(UserParam param) {
      User user = PtcBeanUtils.copy(param, User.class);
       
      .......
        
      // 添加用戶角色
      this.addUserRole(user.getId(), param.getRoleIds());
      log.info("執行結束了");
    }

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

這里#addUser()使用@transactional，但沒有設置rollbackFor屬性，且#addUserRole()拋出的異常是exception，不是RuntimeException，這樣事務也失效了，因為默認情況下，出現 RuntimeException（非受檢異常）或 Error 的時候，Spring才會回滾事務

從上面3.2小節的completeTransactionAfterThrowing(txInfo, ex);進去完成回滾操作會判斷異常類型是否滿足規定，DefaultTransactionAttribute 類能看到如下代碼塊，可以發現相關證據，通過注釋也能看到 Spring 這么做的原因，大概的意思是受檢異常一般是業務異常，或者說是類似另一種方法的返回值，出現這樣的異常可能業務還能完成，所以不會主動回滾；而Error 或 RuntimeException 代表了非預期的結果，應該回滾：

public boolean rollbackOn(Throwable ex) {
  return (ex instanceof RuntimeException || ex instanceof Error);
 }

修正方法：設置rollbackFor：@Transactional(rollbackFor = Exception.class)

3.4 @Transactional 應用在非 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("發生異常咯");
    }

idea也會提示爆紅：

圖片

Spring通過CGLIB動態代理來增強生產代理對象，CGLIB 通過繼承方式實現代理類，private 方法在子類不可見，自然也就無法進行事務增強。s在基于AOP事務控制實現原理一文中也分析過，會調用到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 設置錯誤

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

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

你會發現只會同時插入失敗，無法實現上面所說的。這時候你可能會想到，既然addUserRole()拋出了異常不能插入用戶角色，但是addUser()不想受影響，正常添加用戶，那么何不在addUser()里面對userRoleService.addUserRole()進行異常捕獲，不就可以解決問題了嗎？真是如此嗎，就讓我們來驗證一下：

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

執行會發現，用戶同樣沒有添加成功，看日志報錯：

[1689568520410750976] [ERROR] [2023-08-10 17:25:02.023] [http-nio-18888-exec-1@56682]  com.plasticene.fast.service.impl.UserServiceImpl addUser : 發生異常咯
[1689568520410750976] [ERROR] [2023-08-10 17:25:02.097] [http-nio-18888-exec-1@56682]  com.plasticene.boot.web.core.global.GlobalExceptionHandler exceptionHandler : 【系統異常】
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)

可以看到發生異常咯是我們在addUser()中捕獲到輸出的，但是緊接著下一行發現有報出一個異常UnexpectedRollbackException。

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

修正方式：其實要想新增用戶角色失敗不影響添加用戶，只需要讓新增用戶角色單獨開啟一個新事務即可。

@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("發生異常啦！");
    }

3.6 @Transactional長事務導致生產事故

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

長事務引發的常見危害有：

數據庫連接池被占滿，應用無法獲取連接資源；
容易引發數據庫死鎖；
數據庫回滾時間長；
在主從架構中會導致主從延時變大。

服務系統開始出現故障：數據庫監控平臺一直收到告警短信，數據庫連接不足，出現大量死鎖；日志顯示調用流程引擎接口出現大量超時；同時一直提示CannotGetJdbcConnectionException，數據庫連接池連接占滿。

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

4.總結

本文轉載自微信公眾號「Shepherd進階筆記」，可以通過以下二維碼關注。轉載本文請聯系公眾號。

責任編輯：武曉燕來源： Shepherd進階筆記

Spring 注解事務