前陣子接手了一段同事之前的代碼，里面用到了@transaction注解，了解Spring的小伙伴肯定知道，@Transactional是Spring提供的一種控制事務管理的快捷手段。但是我這段程序在運行的時候，經(jīng)常出現(xiàn)莫名其妙的問題，連夜研究了好久才搞清楚，在這里記錄一下， 避免大家入坑。

1. 大家來找茬

在介紹具體問題之前，我把問題代碼簡化了一下，看大家能找到其中的問題嗎？

問題代碼1

下面的這段代碼主要是想利用MySQL里面的行鎖select for update，來實現(xiàn)簡單的分布式鎖。但是在實踐過程中，發(fā)現(xiàn)這個鎖好像并沒有生效，而且在數(shù)據(jù)庫的里面也沒有查找對應transaction連接的信息。

java復制代碼@Component @EnableScheduling public class someService { ?? ??@Scheduled(...) ??public doSomeWork() { ?? ?// find some id by logic ?? ? ?? ?// process the related info ?? ?doOtherWork(id); ??} ?? ??@Transactional(isolation = Isolation.READ_COMMITTED) ??public void doOtherWork(id) { ?? ?Info info = requestMapper.selectByPrimaryKeyForUpdate(id); ?? ?doSomeFollowingProcess(info); ?? ?... ??} }

問題代碼2

下面代碼分兩個步驟，第一步會檢查相關信息，第二步調(diào)用了一個transactional修飾的方法，完成一些基本工作；但在實踐中，發(fā)現(xiàn)一個非常詭異的問題，在MainWork中，doSomeCheck執(zhí)行時會拋出nullPointException，debug發(fā)現(xiàn)所有autowired進來的service均為空，注釋掉doSomeCheck里面的內(nèi)容后，繼續(xù)往下執(zhí)行，卻發(fā)現(xiàn)doWork能夠正常執(zhí)行，所有的注入均沒有問題。

typescript復制代碼@Component public class MainWork { ??@AutoWired ??DetailWork detailWork ?? ? ??public void workflow() { ?? ?detailWork.doSomeCheck(); ?? ?detailWork.doWork(); ??} } ?@Component public class DetailWork { ?? ?? ?@AutoWired ?? ?UsefulService usefulService; ?? ?? ?@AutoWired ?? ?InfoService infoService; ?? ?? ?@Transactional(isolation = Isolation.READ_COMMITTED) ?? ?public void doWork() { ?? ? ?usefulService.doSomeWork(); ?? ?} ?? ?? ?void doSomeCheck() { ?? ? ?infoService.getInfo(); ?? ?} }

大伙看看能發(fā)現(xiàn)什么問題嗎？

2. 關于@Transactional注解

Spring支持編程式事務管理和聲明式事務管理兩種方式。

• 編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。

• 聲明式事務管理建立在AOP之上的。其本質(zhì)是對方法前后進行攔截，然后在目標方法開始之前創(chuàng)建或者加入一個事務，在執(zhí)行完目標方法之后，根據(jù)執(zhí)行情況提交或者回滾事務。聲明式事務最大的優(yōu)點就是不需要通過編程的方式管理事務，這樣就不需要在業(yè)務邏輯代碼中摻雜事務管理的代碼，只需基于@Transactional注解的方式，便可以將事務規(guī)則應用到業(yè)務邏輯中。

下圖是調(diào)用@Transactional注解的方法時，Spring內(nèi)部的時序圖。簡單來講就是IOC容器初始化時，會生成@Transactional注解所在類的代理對象，然后實際執(zhí)行中會通過AOP執(zhí)行代理對象的方法，TransactionAdvisor會在方法調(diào)用前判斷是否開啟事務，在調(diào)用結束后，會判斷是否提交或回滾事務。

深入研究代碼，我們會發(fā)現(xiàn)TransactionInterceptor （事務攔截器）在目標方法執(zhí)行前后進行攔截，DynamicAdvisedInterceptor（CglibAopProxy 的內(nèi)部類）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法會間接調(diào)用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，獲取Transactional 注解的事務配置信息。

typescript復制代碼protected TransactionAttribute computeTransactionAttribute(Method method, ?? ?Class<?> targetClass) { ?? ? ? ?// Don't allow no-public methods as required. ?? ? ? ?if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) { ?? ? ? ?return null; }

此方法會檢查目標方法的修飾符是否為 public，不是 public則不會獲取@Transactional 的屬性配置信息。也就是說protected、private 修飾的方法上使用 @Transactional 注解會導致事務無效。

了解了@Transactional的原理之后，我們在回頭看看之前的問題，會不會是使用方法不對導致的呢？

3. 撥云見日

問題代碼1解析

下面的代碼中，我們在同一個類里面調(diào)用了@Transactional修飾的方法，其實這樣調(diào)用的話并沒有用到Spring AOP生成的代理對象。從上面的時序圖也可以看到，只有當事務方法被當前類以外的代碼調(diào)用時，才會由Spring生成的代理對象來管理。

java復制代碼@Component @EnableScheduling public class someService { ?? ??@Scheduled(...) ??public doSomeWork() { ?? ?// find some id by logic ?? ? ?? ?// process the related info ?? ?doOtherWork(id); ??} ?? ??@Transactional(isolation = Isolation.READ_COMMITTED) ??public void doOtherWork(id) { ?? ?Info info = requestMapper.selectByPrimaryKeyForUpdate(id); ?? ?doSomeFollowingProcess(info); ?? ?... ??} }

那如何解決這種類內(nèi)調(diào)用的問題呢？ 很簡單，可以使用applicationContext直接從IOC容器中將someService類取出來，然后再調(diào)用doOtherWork方法即可，這樣就能用上Spring AOP生成的代理對象了。

下面是更改之后的代碼，更改之后發(fā)現(xiàn)事務生效了，問題解決！

java復制代碼@Component @EnableScheduling public class someService { ?? ??@Autowired ??private ApplicationContext applicationContext; ?? ??@Scheduled(...) ??public doSomeWork() { ?? ?// find some id by logic ?? ? ?? ?// process the related info ?? ?SomeService someService = applicationContext.getBean(someService.class); ?? ?someService.doOtherWork(id); ??} ?? ??@Transactional(isolation = Isolation.READ_COMMITTED) ??public void doOtherWork(id) { ?? ?Info info = requestMapper.selectByPrimaryKeyForUpdate(id); ?? ?doSomeFollowingProcess(info); ?? ?... ??} }

問題代碼2解析

下面的代碼中，MainWork調(diào)用doSomeCheck的時候，會出現(xiàn)null的情況，原因是由于該方法不是public方法，會導致@Transactional調(diào)用失敗。你可能會說這就是普通方法，跟@Transactional有什么關系？

需要注意的是，無論transactional注解在類上還是在方法上，IOC容器都會生成對應類的代理對象，然后使用代理對象去訪問對應的方法。在這個例子里面， 調(diào)用doWork時一切正常，事務也會生效；但是調(diào)用doSomeCheck時，從之前的分析可以看到，由于方法不是public，此時事務管理器不會起作用，直接導致所有的autowired未完成注入。修改的方法也很簡單，把doSomeCheck改成public就行了。

這個問題隱藏比較深一些，不清楚原理很難發(fā)現(xiàn)這個問題。

typescript復制代碼@Component public class MainWork { ??@AutoWired ??DetailWork detailWork ?? ? ??public void workflow() { ?? ?detailWork.doSomeCheck(); ?? ?detailWork.doWork(); ??} } ?@Component public class DetailWork { ?? ?? ?@AutoWired ?? ?UsefulService usefulService; ?? ?? ?@AutoWired ?? ?InfoService infoService; ?? ?? ?@Transactional(isolation = Isolation.READ_COMMITTED) ?? ?public void doWork() { ?? ? ?usefulService.doSomeWork(); ?? ?} ?? ?? ?public void doSomeCheck() { ?? ? ?infoService.getInfo(); ?? ?} }

4. 相關拓展

幾種事務失效的場景

上面說到的兩個問題，其實就是@Transactional注解使用不當，導致失效的兩種情形；除此之外，以下幾種情況也會導致事務失效：

• 業(yè)務代碼中存在異常時，使用try…catch…語句塊捕獲，而catch語句塊沒有throw new RuntimeExecption異常;（最難被排查到問題且容易忽略）

• 注解@Transactional中Propagation屬性值設置錯誤即Propagation.NOT_SUPPORTED（一般不會設置此種傳播機制）

• mysql關系型數(shù)據(jù)庫，且存儲引擎是MyISAM而非InnoDB，則事務會不起作用(比較少見)；

• 業(yè)務代碼拋出異常類型非RuntimeException，事務失效；Spring默認拋出未檢查unchecked異常（繼承自 RuntimeException 的異常）或者 Error才回滾事務；其他異常不會觸發(fā)回滾事務。如果在事務中拋出其他類型的異常，但卻期望 Spring 能夠回滾事務，就需要指定 rollbackFor屬性。

事務的傳播行為

事務的傳播行為也會影響到事務與事務之間的關系，一定要搞清楚，否則經(jīng)常會出現(xiàn)很奇怪的問題。

具體來講有以下幾種屬性：

• propagation 代表事務的傳播行為，默認值為 Propagation.REQUIRED，其他的屬性信息如下：

• Propagation.REQUIRED：如果當前存在事務，則加入該事務，如果當前不存在事務，則創(chuàng)建一個新的事務。( 也就是說如果A方法和B方法都添加了注解，在默認傳播模式下，A方法內(nèi)部調(diào)用B方法，會把兩個方法的事務合并為一個事務 ）

• Propagation.SUPPORTS：如果當前存在事務，則加入該事務；如果當前不存在事務，則以非事務的方式繼續(xù)運行。

• Propagation.MANDATORY：如果當前存在事務，則加入該事務；如果當前不存在事務，則拋出異常。

• Propagation.REQUIRES_NEW：重新創(chuàng)建一個新的事務，如果當前存在事務，暫停當前的事務。( 當類A中的 a 方法用默Propagation.REQUIRED模式，類B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中調(diào)用 b方法操作數(shù)據(jù)庫，然而 a方法拋出異常后，b方法并沒有進行回滾，因為Propagation.REQUIRES_NEW會暫停 a方法的事務 )

• Propagation.NOT_SUPPORTED：以非事務的方式運行，如果當前存在事務，暫停當前的事務。

• Propagation.NEVER：以非事務的方式運行，如果當前存在事務，則拋出異常。

• Propagation.NESTED ：和 Propagation.REQUIRED 效果一樣。

事務的隔離級別

SQL標準定義了4種事務隔離級別來避免3種數(shù)據(jù)不一致的問題。事務等級從高到低，分別為：

1.Serializable（序列化）

系統(tǒng)中所有的事務以串行地方式逐個執(zhí)行，所以能避免所有數(shù)據(jù)不一致情況。

但是這種以排他方式來控制并發(fā)事務，串行化執(zhí)行方式會導致事務排隊，系統(tǒng)的并發(fā)量大幅下降，使用的時候要絕對慎重。

2.Repeatable read（可重復讀）

一個事務一旦開始，事務過程中所讀取的所有數(shù)據(jù)不允許被其他事務修改。

一個隔離級別沒有辦法解決“幻影讀”的問題。

因為它只“保護”了它讀取的數(shù)據(jù)不被修改，但是其他數(shù)據(jù)會被修改。如果其他數(shù)據(jù)被修改后恰好滿足了當前事務的過濾條件（where語句），那么就會發(fā)生“幻影讀”的情況。

其他兩種事務隔離等級為：

3.Read Committed（已提交讀）

一個事務能讀取到其他事務提交過(Committed)的數(shù)據(jù)。

一個事務在處理過程中如果重復讀取某一個數(shù)據(jù)，而且這個數(shù)據(jù)恰好被其他事務修改并提交了，那么當前重復讀取數(shù)據(jù)的事務就會出現(xiàn)同一個數(shù)據(jù)前后不同的情況。

在這個隔離級別會發(fā)生“不可重復讀”的場景。

4.Read Uncommitted（未提交讀）

一個事務能讀取到其他事務修改過，但是還沒有提交的(Uncommitted)的數(shù)據(jù)。

數(shù)據(jù)被其他事務修改過，但還沒有提交，就存在著回滾的可能性，這時候讀取這些“未提交”數(shù)據(jù)的情況就是“臟讀”。

在這個隔離級別會發(fā)生“臟讀”場景。