消失的事務
端午節前，組內在討論一個問題：
一個沒有加@Transactional注解的方法，去調用一個加了@Transactional的方法，會不會產生事務？
文字蒼白，還是用代碼說話。
先寫一個@Transactional的方法（本文的所有代碼，可到Github上下載）：
@Transactional
public void deleteAllAndAddOneTransactional(Customer customer) {
customerRepository.deleteAll();
if ("Yang".equals(customer.getFirstName())) {
throw new RuntimeException();
}
customerRepository.save(customer);
}
方法內先去執行deleteAll()，刪除表中全部數據；然后執行save()保存數據。
這兩個方法中間，會判斷傳進來的firstName是不是等于“Yang”，是，則拋異常，用于模擬兩個數據庫操作之間可能發生的異常場景。
如果沒有加@Transactional注解，那么這兩個操作就不在一個事務里面，不具有原子性。如果deleteAll之后拋異常，那么就會導致只刪除不新增。
而加了@Transactional之后，這兩個動作在一個事務里頭，具有原子性，要么全部成功，要么全部失敗。如果deleteAll之后拋異常，則事務回滾，恢復原先被刪除的數據。
測試一下，啟動Spring Boot工程，首先調用findAll接口，看看數據庫中都有哪些數據：
接著調用deleteAndSave接口，故意傳入firstName="Yang"，果然返回失敗：
然后，在回過頭去調用findAll接口，看看數據是不是還在：
數據都在，說明產生事務了。
上面都沒啥，都跟符合我們的直覺。
問題來了，如果我的接口是去調用一個沒有加@Transactional的方法，然后這個方法再去調用加了@Transactional的方法呢？
public void deleteAllAndAddOne(Customer customer) {
System.out.println("go into deleteAllAndAddOne");
deleteAllAndAddOneTransactional(customer);
}
@Transactional
public void deleteAllAndAddOneTransactional(Customer customer) {
customerRepository.deleteAll();
if ("Yang".equals(customer.getFirstName())) {
throw new RuntimeException();
}
customerRepository.save(customer);
}
直覺告訴我，會的。
重新編譯，啟動，調用新的接口，繼續故意讓它拋異常：
然后再去findAll，看看數據還在不在：
WTF! 空空如也！數據都沒了！
看來我又一次被直覺欺騙了。
還是得老老實實看代碼，弄懂原理。
看了一晚上代碼，恍然大悟。咱們先畫個圖解釋一下，再來看看代碼。
圖解@Transactional
首先，我們得先弄懂@Transactional的原理。
為什么第一種情況，也就是直接調用@Transactional方法，會產生事務？
其實Spring的@Transactional，跟Spring AOP一樣，都是利用了動態代理。
我們寫了一個類，里面寫了一個加了@Transactional注解的方法，這原本平淡無奇，什么用也沒有，就像這樣：
關鍵在于，Spring在檢查到@Transactional注解之后，給這個對象生成了一個代理對象proxy：
代理對象的methodB，會先開啟事務（beginTransaction），然后再去執行原先對象target的methodB，如果拋異常，則回滾（rollBack），如果一切順利，則提交（commit）。
而最后注入Spring容器的，也正是這個帶有事務邏輯的代理對象。所以我們調用methodB時會產生事務。
現在，我們寫了一個新方法，methodA，里頭去調用methodB：
從上面的分析，可以知道，我們最終拿到的，是代理對象。
那么代理對象的methodA是長什么樣子的呢？長這樣：
由于methodA沒有加@Transactional注解，所以代理對象里面，直接就是target.methodA()，直接調用了原來對象的methodA。
這下就很清晰了，代理對象的methodA，去調用原來對象的methodA，原來對象的methodA，再去調用原來對象的methodB，而原來對象的methodB，是不具有事務的。事務只存在于代理對象的methodB. 所以整個方法也就沒有事務了。
看看代碼
最后再來看看代碼。
只需要在deleteAllAndAddOneTransactional方法內，打一個斷點，一切了然。
分別調用兩個接口，比較調用堆棧：
明顯可以看出，直接調用@Transactional方法，堆棧更長，而且會經過一個叫TransactionInterceptor的攔截器。
跟著堆棧往上走，會發現關鍵就在于這個if-else的邏輯，CglibAopProxy：
CglibAopProxy會去檢查要調用的方法，有沒有AOP調用鏈：
- 沒有，則走if里面的邏輯，直接調用target對象的方法，也就是上面間接調用@Transactional方法的情形；
- 有，則走else邏輯，也就是直接調用@Transactional方法的情形。
當然，如果deleteAllAndAddOne方法被別的切面攔截，那么調用鏈chain也不會為空，也會走if邏輯，這時候是否會有事務呢？思考題。
上面貼的代碼是Cglib代理的情形，JDK Proxy的，大家自行欣賞。
總結
這篇文章主要講了一個有點違反直覺的現象。
通過這樣一個例子，希望能夠加深大家對Spring動態代理的理解。
現在想想，面試時，為什么那么喜歡問源碼？
其實道理很簡單，你用了這項技術、這個框架，卻不知道它是怎么實現的，那就有可能造成錯誤的使用。
參考
- 《Spring揭秘》
