[[422057]]

本文轉(zhuǎn)載自微信公眾號「Java課代表」，作者Java課代表。轉(zhuǎn)載本文請聯(lián)系Java課代表公眾號。

1、引言

Spring 的聲明式事務(wù)極大地方便了日常的事務(wù)相關(guān)代碼編寫，它的設(shè)計(jì)如此巧妙，以至于在使用中幾乎感覺不到它的存在，只需要優(yōu)雅地加一個 @Transactional 注解，一切就都順理成章地完成了!

毫不夸張地講，Spring 的聲明式事務(wù)實(shí)在是太好用了，以至于大多數(shù)人都忘記了編程式事務(wù)應(yīng)該怎么寫。

不過，越是你認(rèn)為理所應(yīng)當(dāng)?shù)氖虑椋绻隽藛栴}，就越難排查。不知道你和身邊的小伙伴有沒有遇到過 @Transactional 失效的場景，這不但是日常開發(fā)中常踩的坑，也是面試中的高頻問題。

其實(shí)這些失效場景不用死記硬背，如果搞明白了它的工作原理，再結(jié)合源碼，需要用到的時候 Debug 一下就能自己分析出來。畢竟，源碼才是最好的說明書。

還是那句話，授人以魚不如授人以漁，課代表就算總結(jié) 100 種失效場景，也不一定能覆蓋到你可能踩到的坑。所以本文中，課代表將結(jié)合幾個常見失效情況，從源碼層面解釋其失效原因。認(rèn)真讀完本文，相信你會對聲明式事務(wù)有更深刻的認(rèn)識。

文中所有代碼已上傳至課代表的 github，為了方便快速部署并運(yùn)行，示例代碼采用了內(nèi)存數(shù)據(jù)庫H2，不需要額外部署數(shù)據(jù)庫環(huán)境。

2、回顧手寫事務(wù)

數(shù)據(jù)庫層面的事務(wù)，有 ACID 四個特性，他們共同保證了數(shù)據(jù)庫中數(shù)據(jù)的準(zhǔn)確性。事務(wù)的原理并不是本文的重點(diǎn)，我們只需要知道樣例中用的 H2 數(shù)據(jù)庫完全實(shí)現(xiàn)了對事務(wù)的支持(read committed)。

編寫 Java 代碼時，我們使用 JDBC 接口與數(shù)據(jù)庫交互，完成事務(wù)的相關(guān)指令，偽代碼如下：

//獲取用于和數(shù)據(jù)庫交互的連接 
Connection conn = DriverManager.getConnection(); 
try { 
    // 關(guān)閉自動提交: 
    conn.setAutoCommit(false); 
    // 執(zhí)行多條SQL語句: 
    insert();  
    update();  
    delete(); 
    // 提交事務(wù): 
    conn.commit(); 
} catch (SQLException e) { 
    // 如果出現(xiàn)異常，回滾事務(wù): 
    conn.rollback(); 
} finally { 
    //釋放資源 
    conn.close(); 
} 

這是典型的編程式事務(wù)代碼流程：開始前先關(guān)閉自動提交，因?yàn)槟J(rèn)情況下，自動提交是開啟的，每條語句都會開啟新事務(wù)，執(zhí)行完畢后自動提交。

關(guān)閉事務(wù)的自動提交，是為了讓多個 SQL 語句在同一個事務(wù)中。代碼正常運(yùn)行，就提交事務(wù)，出現(xiàn)異常，就整體回滾，以此保證多條 SQL 語句的整體性。

除了事務(wù)提交，數(shù)據(jù)庫還支持保存點(diǎn)的概念，在一個物理事務(wù)中，可以設(shè)置多個保存點(diǎn)，方便回滾到指定保存點(diǎn)(其類似玩單機(jī)游戲時的存檔，你可以在角色掛掉后隨時回到上次的存檔)設(shè)置和回滾到保存點(diǎn)的代碼如下：

//設(shè)置保存點(diǎn)     
Savepoint savepoint = connection.setSavepoint(); 
//回滾到指定的保存點(diǎn) 
connection.rollback(savepoint); 
//回滾到保存點(diǎn)后按需提交/回滾前面的事務(wù) 
conn.commit();//conn.rollback(); 

Spring 聲明式事務(wù)所做的工作，就是圍繞著 提交/回滾 事務(wù)，設(shè)置/回滾到保存點(diǎn) 這兩對命令進(jìn)行的。為了讓我們盡可能地少寫代碼，Spring 定義了幾種傳播屬性將事務(wù)做了進(jìn)一步的抽象。注意哦，Spring 的事務(wù)傳播(Propagation) 只是 Spring 定義的一層抽象而已，和數(shù)據(jù)庫沒啥關(guān)系，不要和數(shù)據(jù)庫的事務(wù)隔離級別混淆。

3、Spring 的事務(wù)傳播(Transaction Propagation)

觀察傳統(tǒng)事務(wù)代碼：

conn.setAutoCommit(false); 
   // 執(zhí)行多條SQL語句: 
   insert();  
   update();  
   delete(); 
   // 提交事務(wù): 
   conn.commit(); 

這段代碼表達(dá)的是三個 SQL 語句在同一個事務(wù)里。

他們可能是同一個類中的不同方法，也可能是不同類中的不同方法。如何來表達(dá)諸如事務(wù)方法加入別的事務(wù)、新建自己的事務(wù)、嵌套事務(wù)等等概念呢?這就要靠 Spring 的事務(wù)傳播機(jī)制了。

事務(wù)傳播(Transaction Propagation)就是字面意思：事務(wù)的傳播/傳遞 方式。

在 Spring 源碼的TransactionDefinition接口中，定義了 7 種傳播屬性，官網(wǎng)對其中的 3 個做了說明，我們只要搞懂了這 3 個，剩下的 4 個就是舉一反三的事了。

1)PROPAGATION_REQUIRED

字面意思：傳播-必須

PROPAGATION_REQUIRED是其默認(rèn)傳播屬性，強(qiáng)制開啟事務(wù)，如果之前的方法已經(jīng)開啟了事務(wù)，則加入前一個事務(wù)，二者在物理上屬于同一個事務(wù)。

一圖勝千言，下圖表示它倆物理上是在同一個事務(wù)內(nèi)：

上圖翻譯成偽代碼是這樣的：

try { 
    conn.setAutoCommit(false); 
    transactionalMethod1();  
    transactionalMethod2(); 
    conn.commit(); 
} catch (SQLException e) { 
    conn.rollback(); 
} finally { 
    conn.close(); 
} 

既然在同一個物理事務(wù)中，那如果transactionalMethod2()發(fā)生了異常，導(dǎo)致需要回滾，那么請問transactionalMethod1()是否也要回滾呢?

得益于上面的圖解和偽代碼，我們可以很容易地得出答案，transactionalMethod1()肯定回滾了。

這里拋一個問題：

事務(wù)方法里面的異常被 try catch 吃了，事務(wù)還能回滾嗎?

先別著急出結(jié)論， 看下面兩段代碼示例。

示例一：不會回滾的情況(事務(wù)失效)

觀察下面的代碼，methodThrowsException()什么也沒干，就拋了個異常，調(diào)用方將其拋出的異常try catch 住了，該場景下是不會觸發(fā)回滾的

@Transactional(rollbackFor = Exception.class) 
public void tryCatchRollBackFail(String name) { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    try { 
        methodThrowsException(); 
    } catch (RollBackException e) { 
        //do nothing 
    } 
} 
 
public void methodThrowsException() throws RollBackException { 
    throw new RollBackException(ROLL_BACK_MESSAGE); 
} 

示例二：會回滾的情況(事務(wù)生效)

再看這個例子，同樣是 try catch 了異常，結(jié)果卻截然相反

@Transactional(rollbackFor = Throwable.class) 
public void tryCatchRollBackSuccess(String name, String anotherName) { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    try { 
        // 帶事務(wù)，拋異?；貪L 
        userService.insertWithTxThrowException(anotherName); 
    } catch (RollBackException e) { 
        // do nothing 
    } 
} 
 
@Transactional(rollbackFor = Throwable.class) 
public void insertWithTxThrowException(String name) throws RollBackException { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    throw new RollBackException(ROLL_BACK_MESSAGE); 
} 

本例中，兩個方法的事務(wù)都沒有設(shè)置propagation屬性，默認(rèn)都是PROPAGATION_REQUIRED。即前者開啟事務(wù)，后者加入前面開啟的事務(wù)，二者同屬于一個物理事務(wù)。insertWithTxThrowException()方法拋出異常，將事務(wù)標(biāo)記為回滾。既然大家是在一條船上，那么后者打翻了船，前者肯定也不能幸免。

所以tryCatchRollBackSuccess()所執(zhí)行的SQL也必將回滾，執(zhí)行此用例可以查看結(jié)果

訪問 http://localhost:8080/h2-console/ ，連接信息如下：

點(diǎn)擊Connect進(jìn)入控制臺即可查看表中數(shù)據(jù)：

USER 表確實(shí)沒有插入數(shù)據(jù)，證明了我們的結(jié)論，并且可以看到日志報錯：

Transaction rolled back because it has been marked as rollback-only事務(wù)已經(jīng)回滾，因?yàn)樗粯?biāo)記為必須回滾。

也就是后面方法觸發(fā)的事務(wù)回滾，讓前面方法的插入也回滾了。

看到這里，你應(yīng)該能把默認(rèn)的傳播類型PROPAGATION_REQUIRED理解透徹了，本例中是因兩個方法在同一個物理事務(wù)下，相互影響從而回滾。

你可能會問，那我如果想讓前后兩個開啟了事務(wù)的方法互不影響該怎么辦呢?

這就要用到下面要說的傳播類型了。

2)、PROPAGATION_REQUIRES_NEW

字面意思：傳播- 必須-新的

PROPAGATION_REQUIRES_NEW與PROPAGATION_REQUIRED不同的是，其總是開啟獨(dú)立的事務(wù)，不會參與到已存在的事務(wù)中，這就保證了兩個事務(wù)的狀態(tài)相互獨(dú)立，互不影響，不會因?yàn)橐环降幕貪L而干擾到另一方。

一圖勝千言，下圖表示他倆物理上不在同一個事務(wù)內(nèi)：

上圖翻譯成偽代碼是這樣的：

//Transaction1 
try { 
    conn.setAutoCommit(false); 
    transactionalMethod1();  
    conn.commit(); 
} catch (SQLException e) { 
    conn.rollback(); 
} finally { 
    conn.close(); 
} 
//Transaction2 
try { 
    conn.setAutoCommit(false);  
    transactionalMethod2(); 
    conn.commit(); 
} catch (SQLException e) { 
    conn.rollback(); 
} finally { 
    conn.close(); 
} 

TransactionalMethod1 開啟新事務(wù)，當(dāng)他調(diào)用同樣需要事務(wù)的TransactionalMethod2時，由于后者的傳播屬性設(shè)置了PROPAGATION_REQUIRES_NEW，所以掛起前面的事務(wù)(至于如何掛起，后面我們會從源碼中窺見)，并開啟一個物理上獨(dú)立于前者的新事務(wù)，這樣二者的事務(wù)回滾就不會相互干擾了。

還是前面的例子，只需要把insertWithTxThrowException()方法的事務(wù)傳播屬性設(shè)置為Propagation.REQUIRES_NEW就可以互不影響了：

@Transactional(rollbackFor = Throwable.class) 
public void tryCatchRollBackSuccess(String name, String anotherName) { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    try { 
        // 帶事務(wù)，拋異常回滾 
        userService.insertWithTxThrowException(anotherName); 
    } catch (RollBackException e) { 
        // do nothing 
    } 
} 
 
@Transactional(rollbackFor = Throwable.class, propagation = Propagation.REQUIRES_NEW) 
public void insertWithTxThrowException(String name) throws RollBackException { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    throw new RollBackException(ROLL_BACK_MESSAGE); 
} 

PROPAGATION_REQUIRED和Propagation.REQUIRES_NEW已經(jīng)足以應(yīng)對大部分應(yīng)用場景了，這也是開發(fā)中常用的事務(wù)傳播類型。前者要求基于同一個物理事務(wù)，要回滾一起回滾，后者是大家使用獨(dú)立事務(wù)互不干涉。還有一個場景就是：外部方法和內(nèi)部方法共享一個事務(wù)，但是內(nèi)部事務(wù)的回滾不影響外部事務(wù)，外部事務(wù)的回滾可以影響內(nèi)部事務(wù)。這就是嵌套這種傳播類型的使用場景。

3)、PROPAGATION_NESTED

字面意思：傳播-嵌套

PROPAGATION_NESTED可以在一個已存在的物理事務(wù)上設(shè)置多個供回滾使用的保存點(diǎn)。這種部分回滾可以讓內(nèi)部事務(wù)在其自己的作用域內(nèi)回滾，與此同時，外部事務(wù)可以在某些操作回滾后繼續(xù)執(zhí)行。其底層實(shí)現(xiàn)就是數(shù)據(jù)庫的savepoint。

這種傳播機(jī)制比前面兩種都要靈活，看下面的代碼：

@Transactional(rollbackFor = Throwable.class) 
public void invokeNestedTx(String name,String otherName) { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    try { 
        userService.insertWithTxNested(otherName); 
    } catch (RollBackException e) { 
        // do nothing 
    } 
    // 如果這里拋出異常，將導(dǎo)致兩個方法都回滾 
    // throw new RollBackException(ROLL_BACK_MESSAGE); 
} 
 
@Transactional(rollbackFor = Throwable.class,propagation = Propagation.NESTED) 
public void insertWithTxNested(String name) throws RollBackException { 
    jdbcTemplate.execute("INSERT INTO USER (NAME) VALUES ('" + name + "')"); 
    throw new RollBackException(ROLL_BACK_MESSAGE); 
} 

外部事務(wù)方法invokeNestedTx()開啟事務(wù)，內(nèi)部事務(wù)方法insertWithTxNested標(biāo)記為嵌套事務(wù)，內(nèi)部事務(wù)的回滾通過保存點(diǎn)完成，不會影響外部事務(wù)。而外部方法的回滾，則會連帶內(nèi)部方法一塊回滾。

小結(jié)：本小節(jié)介紹了 3 種常見的Spring 聲明式事務(wù)傳播屬性，結(jié)合樣例代碼，相信你也對其有所了解了，接下來我們從源碼層面看一看，Spring 是如何幫我們簡化事務(wù)樣板代碼，解放生產(chǎn)力的。

4、源碼窺探

在閱讀源碼前，先分析一個問題：我要給一個方法添加事務(wù)，需要做哪些工作呢?

就算我們自己手寫，也至少得需要這么四步：

• 開啟事務(wù)
• 執(zhí)行方法
• 遇到異常就回滾事務(wù)
• 正常執(zhí)行后提交事務(wù)

這不就是典型的AOP嘛~

沒錯，Spring 就是通過 AOP，將我們的事務(wù)方法增強(qiáng)，從而完成了事務(wù)的相關(guān)操作。下面給出幾個關(guān)鍵類及其關(guān)鍵方法的源碼走讀。

既然是 AOP 那肯定要給事務(wù)寫一個切面來做這個事，這個類就是 TransactionAspectSupport，從命名可以看出，這就是“事務(wù)切面支持類”，他的主要工作就是實(shí)現(xiàn)事務(wù)的執(zhí)行流程，其主要實(shí)現(xiàn)方法為invokeWithinTransaction：

protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass, 
      final InvocationCallback invocation) throws Throwable { 
     
 // 省略代碼... 
    // Standard transaction demarcation with getTransaction and commit/rollback calls. 
 // 1、開啟事務(wù) 
    TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, joinpointIdentification); 
    try { 
  // This is an around advice: Invoke the next interceptor in the chain. 
  // This will normally result in a target object being invoked. 
  //2、執(zhí)行方法 
  retVal = invocation.proceedWithInvocation(); 
 } 
 catch (Throwable ex) { 
  // target invocation exception 
  // 3、捕獲異常時的處理 
  completeTransactionAfterThrowing(txInfo, ex); 
  throw ex; 
 } 
 finally { 
  cleanupTransactionInfo(txInfo); 
 } 
 
 if (retVal != null && vavrPresent && VavrDelegate.isVavrTry(retVal)) { 
  // Set rollback-only in case of Vavr failure matching our rollback rules... 
  TransactionStatus status = txInfo.getTransactionStatus(); 
  if (status != null && txAttr != null) { 
   retVal = VavrDelegate.evaluateTryFailure(retVal, txAttr, status); 
  } 
 } 
 //4、執(zhí)行成功，提交事務(wù) 
 commitTransactionAfterReturning(txInfo); 
 return retVal; 
 // 省略代碼... 

結(jié)合課代表增加的這四步注釋，相信你很容易就能看明白。

搞懂了事務(wù)的主要流程，它的傳播機(jī)制又是怎么實(shí)現(xiàn)的呢?這就要看AbstractPlatformTransactionManager這個類了，從命名就能看出， 它負(fù)責(zé)事務(wù)管理，其中的handleExistingTransaction方法實(shí)現(xiàn)了事務(wù)傳播邏輯，這里挑PROPAGATION_REQUIRES_NEW的實(shí)現(xiàn)跟一下代碼：

protected Object doSuspend(Object transaction) { 
  DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction; 
  txObject.setConnectionHolder(null); 
  return TransactionSynchronizationManager.unbindResource(obtainDataSource()); 
 } 

前文我們知道PROPAGATION_REQUIRES_NEW會將前一個事務(wù)掛起，并開啟獨(dú)立的新事務(wù)，而數(shù)據(jù)庫是不支持事務(wù)的掛起的，Spring 是如何實(shí)現(xiàn)這一特性的呢?

通過源碼可以看到，這里調(diào)用了返回值為SuspendedResourcesHolder的suspend(transaction)方法，它的實(shí)際邏輯由其內(nèi)部的doSuspend(transaction)抽象方法實(shí)現(xiàn)。這里我們使用的是JDBC連接數(shù)據(jù)庫，自然要選擇DataSourceTransactionManager這個子類去查看其實(shí)現(xiàn)，代碼如下：

protected Object doSuspend(Object transaction) { 
  DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction; 
  txObject.setConnectionHolder(null); 
  return TransactionSynchronizationManager.unbindResource(obtainDataSource()); 
 } 

這里是把已有事務(wù)的connection解除，并返回被掛起的資源。在接下來開啟事務(wù)時，會將該掛起資源一并傳入，這樣當(dāng)內(nèi)層事務(wù)執(zhí)行完成后，可以繼續(xù)執(zhí)行外層被掛起的事務(wù)。

那么，什么時候來繼續(xù)執(zhí)行被掛起的事務(wù)呢?

事務(wù)的流程，雖然是由TransactionAspectSupport實(shí)現(xiàn)的，但是真正的提交，回滾，是由AbstractPlatformTransactionManager來完成，在其processCommit(DefaultTransactionStatus status)方法最后的finally塊中，執(zhí)行了cleanupAfterCompletion(status):

private void cleanupAfterCompletion(DefaultTransactionStatus status) { 
  status.setCompleted(); 
  if (status.isNewSynchronization()) { 
   TransactionSynchronizationManager.clear(); 
  } 
  if (status.isNewTransaction()) { 
   doCleanupAfterCompletion(status.getTransaction()); 
  } 
   // 有掛起事務(wù)則獲取掛起的資源，繼續(xù)執(zhí)行 
  if (status.getSuspendedResources() != null) { 
   if (status.isDebug()) { 
    logger.debug("Resuming suspended transaction after completion of inner transaction"); 
   } 
   Object transaction = (status.hasTransaction() ? status.getTransaction() : null); 
            
   resume(transaction, (SuspendedResourcesHolder) status.getSuspendedResources()); 
  } 
 } 

這里判斷有掛起的資源將會恢復(fù)執(zhí)行，至此完成掛起和恢復(fù)事務(wù)的邏輯。

對于其他事務(wù)傳播屬性的實(shí)現(xiàn)，感興趣的同學(xué)使用課代表的樣例工程，打斷點(diǎn)自己去跟一下源碼。限于篇幅，這里只給出了大概處理流程，源碼里有大量細(xì)節(jié)，需要同學(xué)們自己去體驗(yàn)，有了上文介紹的主邏輯框架基礎(chǔ)，跟蹤源碼查看其他實(shí)現(xiàn)應(yīng)該不怎么費(fèi)勁了。

5、常見失效場景

很多人(包括課代表本人)一開始使用聲明式事務(wù)，都會覺得這玩意兒真坑，使用起來那么多條條框框，一不小心就不生效了。為什么會有這種感覺呢?

爬了多次坑之后，課代表總結(jié)了兩條經(jīng)驗(yàn)：

1. 沒看官方文檔
2. 不會讀源碼

下面簡單列舉幾個失效場景：

1)非 public 方法不生效

官網(wǎng)有說明：

Method visibility and @Transactional

When you use transactional proxies with Spring’s standard configuration, you should apply the @Transactional annotation only to methods with public visibility.

2)Spring 不支持 redis 集群中的事務(wù)

redis事務(wù)開啟命令是multi，但是 Spring Data Redis 不支持 redis 集群中的 multi 命令，如果使用了聲明式事務(wù)，將會報錯：MULTI is currently not supported in cluster mode.

3)多數(shù)據(jù)源情況下需要為每個數(shù)據(jù)源配置TransactionManager，并指定transactionManager參數(shù)

第四部分源碼窺探中已經(jīng)看到實(shí)際執(zhí)行事務(wù)操作的是AbstractPlatformTransactionManager，其為TransactionManager的實(shí)現(xiàn)類，每個事務(wù)的connection連接都受其管理，如果沒有配置，無法完成事務(wù)操作。單數(shù)據(jù)源的情況下正常運(yùn)行，是因?yàn)? SpringBoot 的DataSourceTransactionManagerAutoConfiguration為我們自動配置了。

4)rollbackFor 設(shè)置錯誤

默認(rèn)情況下只回滾非受檢異常(也就是，java.lang.RuntimeException的子類)和java.lang.Error，如果明確知道拋異常就要回滾，建議設(shè)置為@Transactional(rollbackFor = Throwable.class)

5)AOP不生效問題

其他諸如 MyISAM 不支持，es 不支持等等就不一一列舉了。

如果感興趣，以上這些在源碼中都能找到解答。

6、結(jié)束語

關(guān)于 Spring 的聲明式事務(wù)，如果想用好，還真得多 Debug 幾遍源碼，由于 Spring 的源碼細(xì)節(jié)過于豐富，實(shí)在不適合全部貼到文章里，建議自己去跟一下源碼。熟悉之后就不怕再遇到失效情況了。

以下資料證明我不是在胡扯

1、文中測試用例代碼：https://github.com/zhengxl5566/springboot-demo/tree/master/transactional

2、Spring 官網(wǎng)事務(wù)文檔：https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#tx-propagation

3、Oracle官網(wǎng)JDBC文檔：https://docs.oracle.com/javase/tutorial/jdbc/basics/index.html

4、Spring Data Redis 源碼：https://github.com/spring-projects/spring-data-redis