聊聊Spring事務控制策略以及@Transactional失效問題避坑

大家好，又見面了，

在大部分涉及到資料庫操作的專案里面，事務控制、事務處理都是一個無法回避的問題，比如，需要對SQL執行程序進行事務的控制與處理的時候，其整體的處理流程會是如下的示意：

首先是要開啟事務、然后執行具體SQL，如果執行例外則回滾事務，否則提交事務，最后關閉事務，完成整個處理程序，按照這個流程的邏輯，寫一下對應的實作代碼：

public void testJdbcTransactional(DataSource dataSource) {
    Connection conn = null;
    int result = 0;
    try {
        // 獲取鏈接
        conn = dataSource.getConnection();
        // 禁用自動事務提交，改為手動控制
        conn.setAutoCommit(false);
        // 設定事務隔離級別
        conn.setTransactionIsolation(
            TransactionIoslationLevel.READ_COMMITTED.getLevel()
        );

        // 執行SQL
        PreparedStatement ps = 
            conn.prepareStatement("insert into user (id, name) values (?, ?)");
        ps.setString(1, "123456");
        ps.setString(2, "Tom");
        result = ps.executeUpdate();

        // 執行成功，手動提交事務
        conn.commit();
    } catch (Exception e) {
        // 出現例外，手動回滾事務
        if (conn != null) {
            try {
                conn.rollback();
            } catch (Exception e) {
                // write log...
            }
        }
    } finally {
        // 執行結束，最終不管成功還是失敗，都要釋放資源，斷開連接
        try {
            if (conn != null && !conn.isClosed()) {
                conn.close();
            }
        } catch (Exception e) {
             // write log...
        }
    }
}

不難發現，上面大段的代碼邏輯并不復雜，對于業務而言其實僅僅只是執行了一個insert操作而已，但是雜糅的事務控制代碼，顯然干擾了業務自身的代碼處理邏輯的閱讀與理解，

常規專案的代碼中，涉及到DB處理的場景很多，如果每個地方都有這么一段事務控制的邏輯，那么整體代碼的可維護性將會比較差，想想都令人窒息，

好在，JAVA中很多專案現在都是基于Spring框架進行構建的，得益于 Spring框架的封裝，業務代碼中進行事務控制操作起來也很簡單，直接加個 @Transactional注解即可，大大簡化了對業務代碼的侵入性，那么對 @Transactional事務注解了解的夠全面嗎？知道有哪些場景可能會導致 @Transactional注解并不會如你預期的方式生效嗎？知道應該怎么使用 @Transactional才能保證對性能的影響最小化嗎？

下面我們一起探討下這些問題，

Spring宣告式事務處理機制

為了簡化業務開發場景對事務的處理復雜度，讓開發人員可以更關注于業務自身的處理邏輯，Spring提供了宣告式事務的能力支持，

Spring資料庫事務約定處理邏輯流程如下圖所示，對比前面示例中基于JDBC的事務處理，Spring的事務的處理操作交給了Spring框架處理，開發人員僅需要實作自己的業務邏輯即可，大大簡化了事務方面的處理投入，

基于Spring事務機制，實作上述DB操作事務控制的代碼，我們的代碼會變得非常的簡潔：

@Transactional
public void insertUser() {
    userDao.insertUser();
}

與JDBC事務實作代碼相比，基于Spring的方式只需要添加一個 @Transactional注解即可，代碼中只需要實作業務邏輯即可，實作了事務控制機制對業務代碼的低侵入性，

Spring支持的基于 Spring AOP實作的宣告式事務功能，所謂宣告式事務，即使用@Transactional注解進行宣告標注，告訴Spring框架在什么地方啟用資料庫事務控制能力，@Transactional注解，可以添加在類或者方法上，如果其添加在類上時，表明此類中所有的public非靜態方法都將啟用事務控制能力，

既然@Transactional注解承載了Spring框架對于事務處理的相關能力，那么接下來我們就一起看下該注解的一些可選配置以及具體使用場景，

@Transactional主要可選配置

只讀事務配置

通過readonly引數指定當前事務是否為一個只讀事務，設定為true標識此事務是個只讀事務，默認情況為false，

@Transactional(readOnly = true)
public DomResponse<CiCdItemDetail> queryCicdItemDetail(String appCode) {
    return null;
}

這里涉及一個概念，叫做只讀事務，其含義描述如下：

在多條查詢陳述句一起執行的場景里面會涉及到的概念，表示在事務設定的那一刻開始，到整個事務執行結束的程序中，其他事務所提交的寫操作資料，對該事務都不可見，

舉個例子：

現在有一個復合查詢操作，包含2條SQL查詢操作：先獲取用戶表count數，再獲取用戶表中所有資料，
(1) 先執行完獲取用戶表count數，得到結果10
(2) 在還沒開始執行后一條陳述句的時候，另一個行程操作了DB并往用戶表中插入一條新資料
(3) 復合操作的第二條SQL陳述句，獲取用戶串列的操作被執行，回傳了11條記錄

很明顯，復合操作中的兩條SQL陳述句獲取的資料結果無法匹配上，原因就是非原子性操作導致，即2條查詢操作執行的間隔內，有另一個寫操作修改了目標讀取的資料，導致了此問題的出現，

為了避免此情況的發生，可以給復合查詢操作添加上只讀事務，這樣事務控制范圍內，事務外的寫操作就不可見，這樣就保證了事務內多條查詢陳述句執行結果的一致性，

那為什么要設定為只讀事務、而不是常規的事務呢？主要是從執行效率角度的考慮，因為這個里的操作都是一些只讀操作，所以設定為只讀事務，資料庫會為只讀事務提供一些優化手段，比如不啟動回滾段、不記錄回滾log之類的，

回滾條件設定

@Transactional有提供4個不同屬性，可以支持傳入不同的引數，設定需要回滾的條件：

其中，rollbackFor支持指定單個或者多個例外型別，只要拋出指定型別的例外，事務都將被回滾掉：

// 指定單個例外
@Transactional(rollbackFor = DemoException.class)
public void insertUser() {
    // do something here
}

// 指定多個例外
@Transactional(rollbackFor = {DemoException.class, DemoException2.class})
public void insertUser2() {
    // do something here
}

rollbackFor和rollbackForClassName作用相同，只是提供了2個不同的指定方法，允許執行Class型別或者ClassName字串，

// 指定例外名稱
@Transactional(rollbackForClassName = {"DemoException"})
public void insertUser() {
    // do something here
}

同理，noRollbackFor和noRollbackForClassName的使用與上面示意的相似，只是其含義功能點是相反的，

事務傳播行為

propagation用于指定此事務對應的傳播型別，所謂的事務傳播型別，即當前已經在一個事務的背景關系中時，又需要開始一個事務，這個時候來處理這個將要開啟的新事務的處理策略，

主要有7種型別的事務傳播型別：

事務的傳播行為，將會影響到事務控制的結果，比如最終是在同一事務中，一旦遇到例外，所有操作都會被回滾掉，而如果是在多個事務中，則某一個事務的回滾，不影響已提交的其余事務的回滾，

實際編碼的時候，可以通過@Transactional注解中的 propagation引數來指定具體的傳播型別，取值由 org.springframework.transaction.annotation.Propagation列舉類提供，如果不指定，則默認取值為 Propagation.REQUIRED，也即如果當前存在事務，則加入該事務，如果當前沒有事務，則創建一個新的事務，

/**
 * The transaction propagation type.
 * <p>Defaults to {@link Propagation#REQUIRED}.
 * @see org.springframework.transaction.interceptor.TransactionAttribute#getPropagationBehavior()
 */
Propagation propagation() default Propagation.REQUIRED;
  

事務超時設定

可以使用timeout屬性來設定事務的超時秒數，默認值為-1，表示永不超時，

@Transactional失效場景避坑

同一個類中方法間呼叫

Spring的事務實作原理是AOP，而AOP的原理是動態代理，

在類內部方法之間相互呼叫的時候，本質上是類物件自身的呼叫，而不是使用代理物件去呼叫，也就不會觸發AOP，這樣其實Spring也就無法將事務控制的代碼邏輯織入到呼叫代碼流程中，所以這里的事務控制就無法生效，

public void insertUser() {
    writeDataIntoDb();
}

@Transactional
public void writeDataIntoDb() {
  // ...
}

所以遇到同一個類中多個方法之間相互呼叫，且呼叫的方法需要做事務控制的時候需要特別注意下這個問題，解決方式，可以建2個不同的類，然后將方法放到兩個類中，這樣跨類呼叫，Spring事務機制就可以生效，

添加在非public方法上

如果將@Transactional注解添加在protected、private修飾的方法上，雖然代碼不會有任何的報錯，但是實際上注解是不會生效的，

@Transactional
private void writeDataIntoDb() {
  // ...
}

方法內部Try Catch吞掉相關例外

這個其實很容易理解，業務代碼中將所有的例外給catch并吞掉了，等同于業務代碼認為被捕獲的例外不需要去觸發回滾，對框架而言，因為例外被捕獲了，業務邏輯執行都在正常往下運行，所以也不會觸發例外回滾機制，

// catch了可能的例外，導致DB操作失敗的時候事務不會觸發回滾
@Transactional
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");

        // 直接吞掉了例外，這樣不會觸發事務回滾機制
    }
}

在業務處理邏輯中，如果確實需要知曉并捕獲相關處理的例外進行一些額外的業務邏輯處理，如果要保證事務回滾機制生效，最后需要往外拋出 RuntimeException例外，或者是繼承RuntimeException實作的業務自定義例外，如下：

// catch了可能的例外，對外拋出RuntimeException或者其子類,可觸發事務回滾
@Transactional
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");

        // @Transactional沒有指定rollbackFor，所以拋出RuntimeException或者其子類，可觸發事務回滾機制
        throw new RuntimeException(e);
    }
}

當然，如果@Transactional注解指定了 rollbackFor為某個具體的例外型別，則最終需要保證例外時對外拋出相匹配的例外型別，才可以觸發事務處理邏輯，如下：

// catch了指定例外，對外拋出對應型別的例外,可觸發事務回滾
@Transactional(rollbackFor = DemoException.class)
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");
        // @Transactional有指定rollbackFor，拋出例外要與rollbackFor指定例外型別一致
        throw new DemoException();
    }
}

對應資料庫引擎型別不支持事務

以MySQL資料庫而言，常見的資料庫引擎有 InnoDB和 Myisam等型別，但是MYISAM引擎型別是不支持事務的，所以如果建表時設定的引擎型別設定為 MYISAM的話，即使代碼里面添加了@Transactional最終事務也不會生效的，

@Transactional使用策略

因為事務處理對性能會有一定的影響，所以事務也不是說任何地方都可以隨便添加的，對于一些性能敏感場景，需要注意幾點：

1. 僅在必要的場合添加事務控制

（1）不含有DB操作相關，無需添加事務控制
（2）單條查詢陳述句，沒必要添加事務控制
（3）僅有查詢操作的多條SQL執行場景，可以添加只讀事務控制
（4）單條 insert/update/delete陳述句，其實也不需要添加 @Transactional事務處理，因為單條陳述句執行其實資料庫有隱性事務控制機制，如果執行失敗，是屬于 SQL報錯，資料不會更新成功，自然也無需回滾，

2. 盡可能縮小事務控制的代碼段處理范圍

主要從性能層面考慮，事務機制，類似于并發場景的加鎖處理，范圍越大對性能影響越明顯

3. 事務控制范圍內的業務邏輯盡可能簡單、避免非事務相關耗時處理邏輯

也是從性能層面考慮，盡量將耗時的邏輯放到事務控制之外執行，事務內僅保留與DB操作切實相關的邏輯

總結

好啦，關于Spring中事務控制的相關用法，以及@Transactional使用程序中可能的一些失效場景，就探討到這里了，那么你對事務這塊有哪些自己的理解呢？或者是否有遇到相關的問題呢？歡迎一起交流下咯，

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新，

期待與你一起探討，一起成長為更好的自己，

本文來自博客園，作者：架構悟道，歡迎關注公眾號[架構悟道]持續獲取更多干貨，轉載請注明原文鏈接：https://www.cnblogs.com/softwarearch/p/16561833.html

標籤：Java

上一篇：徹底理解 volatile 關鍵字及應用場景，面試必問，小白都能看懂！

下一篇：流程控制