前陣子接手了一段同事之前的代碼，裏面用到了@Transactional註解，瞭解Spring的小夥伴肯定知道，@Transactional是Spring提供的一種控制事務管理的快捷手段。但是我這段程序在運行的時候，經常出現莫名其妙的問題，連夜研究了好久才搞清楚，在這裏記錄一下， 避免大家入坑。
1. 大家來找茬
在介紹具體問題之前，我把問題代碼簡化了一下，看大家能找到其中的問題嗎？
問題代碼1
下面的這段代碼主要是想利用MySQL裏面的行鎖select for update，來實現簡單的分佈式鎖。但是在實踐過程中，發現這個鎖好像並沒有生效，而且在數據庫的裏面也沒有查找對應transaction連接的信息。
@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
下面代碼分兩個步驟，第一步會檢查相關信息，第二步調用了一個transactional修飾的方法，完成一些基本工作；但在實踐中，發現一個非常詭異的問題，在MainWork中，doSomeCheck執行時會拋出nullPointException，debug發現所有autowired進來的service均爲空，註釋掉doSomeCheck裏面的內容後，繼續往下執行，卻發現doWork能夠正常執行，所有的注入均沒有問題。
@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();
}
}
大夥看看能發現什麼問題嗎？
2. 關於@Transactional註解
Spring支持編程式事務管理和聲明式事務管理兩種方式。
-
編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。
-
聲明式事務管理建立在AOP之上的。其本質是對方法前後進行攔截，然後在目標方法開始之前創建或者加入一個事務，在執行完目標方法之後，根據執行情況提交或者回滾事務。聲明式事務最大的優點就是不需要通過編程的方式管理事務，這樣就不需要在業務邏輯代碼中摻雜事務管理的代碼，只需基於@Transactional註解的方式，便可以將事務規則應用到業務邏輯中。
下圖是調用@Transactional註解的方法時，Spring內部的時序圖。簡單來講就是IOC容器初始化時，會生成@Transactional註解所在類的代理對象，然後實際執行中會通過AOP執行代理對象的方法，TransactionAdvisor會在方法調用前判斷是否開啓事務，在調用結束後，會判斷是否提交或回滾事務。
深入研究代碼，我們會發現TransactionInterceptor （事務攔截器）在目標方法執行前後進行攔截，DynamicAdvisedInterceptor（CglibAopProxy 的內部類）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法會間接調用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，獲取Transactional 註解的事務配置信息。
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解析
下面的代碼中，我們在同一個類裏面調用了@Transactional修飾的方法，其實這樣調用的話並沒有用到Spring AOP生成的代理對象。從上面的時序圖也可以看到，只有當事務方法被當前類以外的代碼調用時，纔會由Spring生成的代理對象來管理。
@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);
...
}
}
那如何解決這種類內調用的問題呢？ 很簡單，可以使用applicationContext直接從IOC容器中將someService類取出來，然後再調用doOtherWork方法即可，這樣就能用上Spring AOP生成的代理對象了。
下面是更改之後的代碼，更改之後發現事務生效了，問題解決！
@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調用doSomeCheck的時候，會出現null的情況，原因是由於該方法不是public方法，會導致@Transactional調用失敗。你可能會說這就是普通方法，跟@Transactional有什麼關係？
需要注意的是，無論transactional註解在類上還是在方法上，IOC容器都會生成對應類的代理對象，然後使用代理對象去訪問對應的方法。在這個例子裏面， 調用doWork時一切正常，事務也會生效；但是調用doSomeCheck時，從之前的分析可以看到，由於方法不是public，此時事務管理器不會起作用，直接導致所有的autowired未完成注入。修改的方法也很簡單，把doSomeCheck改成public就行了。
這個問題隱藏比較深一些，不清楚原理很難發現這個問題。
@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註解使用不當，導致失效的兩種情形；除此之外，以下幾種情況也會導致事務失效：
-
業務代碼中存在異常時，使用
try…catch…語句塊捕獲，而catch語句塊沒有throw new RuntimeExecption異常;（最難被排查到問題且容易忽略） -
註解
@Transactional中Propagation屬性值設置錯誤即Propagation.NOT_SUPPORTED（一般不會設置此種傳播機制） -
mysql關係型數據庫，且存儲引擎是MyISAM而非InnoDB，則事務會不起作用(比較少見)；
-
業務代碼拋出異常類型非
RuntimeException，事務失效；Spring默認拋出未檢查unchecked異常（繼承自RuntimeException的異常）或者Error纔回滾事務；其他異常不會觸發回滾事務。如果在事務中拋出其他類型的異常，但卻期望 Spring 能夠回滾事務，就需要指定 rollbackFor屬性。
事務的傳播行爲
事務的傳播行爲也會影響到事務與事務之間的關係，一定要搞清楚，否則經常會出現很奇怪的問題。
具體來講有以下幾種屬性：
-
propagation 代表事務的傳播行爲，默認值爲 Propagation.REQUIRED，其他的屬性信息如下：
-
Propagation.REQUIRED：如果當前存在事務，則加入該事務，如果當前不存在事務，則創建一個新的事務。( 也就是說如果A方法和B方法都添加了註解，在默認傳播模式下，A方法內部調用B方法，會把兩個方法的事務合併爲一個事務 ）
-
Propagation.SUPPORTS：如果當前存在事務，則加入該事務；如果當前不存在事務，則以非事務的方式繼續運行。
-
Propagation.MANDATORY：如果當前存在事務，則加入該事務；如果當前不存在事務，則拋出異常。
-
Propagation.REQUIRES_NEW：重新創建一個新的事務，如果當前存在事務，暫停當前的事務。( 當類A中的 a 方法用默Propagation.REQUIRED模式，類B中的 b方法加上採用 Propagation.REQUIRES_NEW模式，然後在 a 方法中調用 b方法操作數據庫，然而 a方法拋出異常後，b方法並沒有進行回滾，因爲Propagation.REQUIRES_NEW會暫停 a方法的事務 )
-
Propagation.NOT_SUPPORTED：以非事務的方式運行，如果當前存在事務，暫停當前的事務。
-
Propagation.NEVER：以非事務的方式運行，如果當前存在事務，則拋出異常。
-
Propagation.NESTED ：和 Propagation.REQUIRED 效果一樣。
事務的隔離級別
SQL標準定義了4種事務隔離級別來避免3種數據不一致的問題。事務等級從高到低，分別爲：
1.Serializable（序列化）
系統中所有的事務以串行地方式逐個執行，所以能避免所有數據不一致情況。
但是這種以排他方式來控制併發事務，串行化執行方式會導致事務排隊，系統的併發量大幅下降，使用的時候要絕對慎重。
2.Repeatable read（可重複讀）
一個事務一旦開始，事務過程中所讀取的所有數據不允許被其他事務修改。
一個隔離級別沒有辦法解決“幻影讀”的問題。
因爲它只“保護”了它讀取的數據不被修改，但是其他數據會被修改。如果其他數據被修改後恰好滿足了當前事務的過濾條件（where語句），那麼就會發生“幻影讀”的情況。
其他兩種事務隔離等級爲：
3.Read Committed（已提交讀）
一個事務能讀取到其他事務提交過(Committed)的數據。
一個事務在處理過程中如果重複讀取某一個數據，而且這個數據恰好被其他事務修改並提交了，那麼當前重複讀取數據的事務就會出現同一個數據前後不同的情況。
在這個隔離級別會發生“不可重複讀”的場景。
4.Read Uncommitted（未提交讀）
一個事務能讀取到其他事務修改過，但是還沒有提交的(Uncommitted)的數據。
數據被其他事務修改過，但還沒有提交，就存在着回滾的可能性，這時候讀取這些“未提交”數據的情況就是“髒讀”。
在這個隔離級別會發生“髒讀”場景。
參考：