starting from a joke
問：把大象放冰箱里，分幾步？
答：三步啊，第一、把冰箱門打開，第二、把大象放進去，第三、把冰箱門帶上。
問：實現spring事務，分幾步？
答：三步啊，第一、找出需要事務的方法，第二、把事務加進去，第三、執行事務。
you may find it's not a joke, it's serious。
try to find an entrance
當你面對一個完全不熟悉的事物時，一定要想辦法找到一個突破口，然后逐步深入。那spring事物的突破口在哪里呢？很明顯在@enabletransactionmanagement注解里，因為是它啟用了事物功能。
請看下圖：
發現注解還引入了一個類transactionmanagementconfigurationselector。
再來看這個類，如下圖：
發現如果采用代理的方式時，又引入了一個類proxytransactionmanagementconfiguration。
接著看這個類（重點來了），如下圖：
發現這個類往容器中注冊了3個bean，第一個是beanfactorytransactionattributesourceadvisor。它以advisor結尾說明它是spring aop范疇里的東西。
在aop里，advisor = pointcut + advice，pointcut是切入點，表示要攔截的方法，advice是增強，表示要加進去的事物功能。
再看看另外兩個注冊的bean，就是和這兩個相關的。其中transactioninterceptor就是一個advice，因為它實現了advice接口，包含了把事物加進去的邏輯。
transactionattributesource雖然不是一個pointcut，但是它被pointcut所用，用于檢測一個類的方法上是否有@transactional注解，來確定該方法是否需要事物增強。
從下圖中也可以看出這一點：
可以看到這個bean通過下面的set方法被設置進去，然后又用在了pointcut的類里了。
整體來看，此部分的結構和功能劃分還是非常清晰的。下面來逐一研究。
aop切點
transactionattributesourcepointcut類以pointcut結尾，說明它是一個切入點，就是標識要被攔截的方法。類名的前綴部分表明了這個切入點的實現原理。
看下這個前綴是transactionattributesource，它以source結尾，說明它是一個源（即源泉，有向外提供東西的意思）。它的前綴是transactionattribute，即事務屬性。
由此可見，這個源可以向外提供事務屬性，其實就是判斷一個類的方法上是否標有@transactional注解，如果有的話還可以獲取這個注解的屬性（即事務屬性）。
整體來說就是，pointcut攔截住了方法，然后使用這個“源”去方法和類上獲取事務屬性，如果能獲取到，說明此方法需要參與事務，則進行事務增強，反之則不增強。
下面這張圖可以證明我們的想法：
可以看出matches方法的兩個參數就是一個方法（method）和一個類（class<?>）。最后從方法和類上獲取事務屬性，再進行是否為null判斷。
現在這個“源”還是個黑盒子，下面來揭開它的面紗。它的實現類是annotationtransactionattributesource，以annotation開頭，說明是基于注解實現的。
下面圖是它的源碼的一部分：
第一個方法從類上找事務屬性，第二個方法從方法上找事務屬性，它倆都調用了第三個方法來實現。
ps：我們都知道，方法上的注解優先級高于類上的，是因為找注解時先找方法上的，找不到時再去類上找。所以方法上的優先級高。此部分代碼邏輯在父類里寫著呢，這里不再展示了。
第三個方法使用多個事務注解解析器（transactionannotationparser）去解析注解，為啥是多個解析器呢？因為事務注解不僅spring提供了，java后來也提供了，就是javax.transaction.transactional。
spring對自己注解的解析器實現類是springtransactionannotationparser，如下圖：
可以看出使用工具類來讀取注解@transactional的屬性，然后逐個解析出屬性值并進行類型轉換，接著把這些屬性封裝到一個類里，這個類其實就是事務屬性，即transactionattribute。
這個事務屬性繼承了事務定義接口，事務定義接口我們應該都很熟悉，如下圖：
這也證明了以前文章里說過的話，@transactional注解的作用有兩個，一是表明要參與事務，二是表明如何參與事務，這些注解屬性就是來規定如何參與的。
這個事務屬性transactionattribute是個接口，它的實現類在這里就不再詳說了。
aop增強
advice就是aop中的增強，transactioninterceptor實現了advice接口，所以它就是事務增強。
先來看下該接口，如下圖：
發現它只是一個空的標記接口。而且它的包名是org.aopalliance，是一個aop聯盟組織，它制定的aop規范。
先來了解下aop領域的一些相關內容，pointcut是切入點，表示要攔截的方法。它是一個靜態的概念，即程序不運行時它也是存在的。
那么在真正運行時，已經攔截住了，此時該怎么表示這個情況呢？是用joinpoint來表示的，所以joinpoint是一個運行時的概念，只有在運行時才存在。
請看joinpoint接口，如下圖：
第一個方法proceed()是“繼續”的意思，調用它表示去執行被攔截住的方法本身，返回方法本身的返回值。
第二個方法getthis()是獲取this對象，即方法運行時所在的目標對象。如果是靜態方法，則為null，因為靜態方法是屬于類本身的，運行時不需要對象。
第三個方法getstaticpart()，其實就表示了被攔截住的方法，即就是一個method。method其實算是“元數據”，是屬于類型本身的，也有“靜態”的意思。
再看一個接口，invocation，它繼承了joinpoint，如下圖：
方法getarguments()就表示運行時傳遞給被攔截住方法的參數。
再看一個接口，methodinvocation，它繼承了invocation，如下圖：
方法getmethod()返回一個method，它就是當前正在執行的方法，是對本攔截方法的一個友好實現，返回相同的結果。
可見methodinvocation接口已經包含了一個方法調用的全量信息，方法，參數，目標對象。這其實就是運行時被攔截住的東西。
再看下面這個接口，methodinterceptor，方法攔截器，如下圖：
它只有一個方法invoke，方法參數就是上面介紹的methodinvocation。所以攔截器可以使用這個參數來對目標方法進行調用，當然在調用前/后可以加入自己的邏輯。
transactioninterceptor類就實現了這個接口，因此可以在對目標方法的調用前后插入事務邏輯代碼來進行事務增強。
下面是事務攔截器對該方法的實現，如下圖：
它調用的invokewithintransaction方法是在父類里的，看下圖：
這個圖里做的事情較多，逐個來看：
前兩行獲取事務屬性“源”，再用這個“源”來獲取事務屬性。咦，有點奇怪，上面不是已經獲取過了嗎？是的，上面是在pointcut里獲取的，那只是用于判斷那個方法是否要被攔截而已。這里獲取的屬性才是真正用于事務的。
第三行是根據事務屬性，來確定出一個事務管理器來。
接下來是使用事務管理器打開事務。
接下來是對被攔截住的目標方法的調用執行，當然要try/catch住這個執行。
如果拋出了異常，則進行和異常相關的事務處理，然后將這個異常繼續向上拋出。
如果沒有拋出異常，則進行事務提交。
最后的else分支是對編程式事務的調用，事務的打開/提交/回滾是開發人員自己寫代碼控制，所以就不需要事務管理器操心了。
下面請看和異常相關的事務處理，如下圖：
判斷異常類型是否需要回滾，需要的話就回滾事務，不需要的話就繼續提交事務。
這里的整體結構和邏輯流程也是比較清晰的，那是因為一方面得益于aop領域的概念，另一方面是事務管理器屏蔽了事務的所有復雜性。
ps：事務管理器的內容其實還是挺復雜的，下篇文章再詳細解說。
好了，以上是小編給大家介紹的spring事務面試整理，希望對大家有所幫助，如果大家有任何疑問歡迎給我留言，小編會及時回復大家的！
原文鏈接：https://www.cnblogs.com/lixinjie/archive/2019/04/16/a-enough-source-read-of-spring-tx-for-interview.html
