引言

今天，我們接上文《面試官:談談你對mysql事務的認識》的內(nèi)容，來講spring中和事務有關(guān)的考題！
因為事務這塊，面試的出現(xiàn)幾率很高。而大家工作中CRUD的比較多，沒有好好總結(jié)過這塊的知識，因此面試容易支支吾吾答不出來，于是乎接下來你就會接到一張好人卡，如"你很優(yōu)秀，不適合我們公司！"

由于《面試官:談談你對mysql事務的認識》篇幅所限，因此略過了spring事務相關(guān)常見面試題，今天給大家補上！主要題目如下:

• (1)spring事務的原理?

• (2)spring什么情況下進行事務回滾？

• (3)spring事務什么時候失效?

• (4)Spring的事務和數(shù)據(jù)庫的事務隔離是一個概念么？

• (5)spring事務控制放在service層，在service方法中一個方法調(diào)用service中的另一個方法，默認開啟幾個事務？

• (6)怎么保證spring事務內(nèi)的連接唯一性?

正文

1、spring事務的原理?
首先，我們先明白spring事務的本質(zhì)其實就是數(shù)據(jù)庫對事務的支持，沒有數(shù)據(jù)庫的事務支持，spring是無法提供事務功能的。
那么，我們一般使用JDBC操作事務的時候，代碼如下

• (1)獲取連接 Connection con = DriverManager.getConnection()

• (2)開啟事務con.setAutoCommit(true/false);

• (3)執(zhí)行CRUD

• (4)提交事務/回滾事務 con.commit() / con.rollback();

• (5)關(guān)閉連接 conn.close();

  
  

  
  

使用spring事務管理后，我們可以省略步驟(2)和步驟(4)，就是讓AOP幫你去做這些工作。關(guān)鍵類在TransactionAspectSupport這個切面里，大家有興趣自己去翻。我就不列舉了，因為公眾號類型的文章，實在不適合寫一些源碼解析！

2、spring 什么情況下進行事務回滾？
首先，我們要明白Spring事務回滾機制是這樣的：當所攔截的方法有指定異常拋出，事務才會自動進行回滾！
因此，如果你默默的吞掉異常，像下面這樣

@Service
public?class?UserService{
????@Transactional
????public?void?updateUser(User?user)?{
????????try?{
????????????System.out.println("孤獨煙真帥");
????????????//do?something
????????}?catch?{
??????????//do?something
????????}
????}

}

那切面捕捉不到異常，肯定是不會回滾的。
還有就是，默認配置下，事務只會對Error與RuntimeException及其子類這些異常，做出回滾。一般的Exception這些Checked異常不會發(fā)生回滾（如果一般Exception想回滾要做出配置），如下所示

@Transactional(rollbackFor?=?Exception.class)

但是在實際開發(fā)中，我們會遇到這么一種情況！就是并沒有異常發(fā)生，但是由于事務結(jié)果未滿足具體業(yè)務需求，所以我們需要手動回滾事務，于是乎方法也很簡單

• (1)自己在代碼里拋出一個自定義異常(常用)

• (2)通過編程代碼回滾(不常用)

TransactionAspectSupport.currentTransactionStatus()
.setRollbackOnly();

3、spring事務什么時候失效?
ps:經(jīng)典老題?。?！4年前我畢業(yè)那會在問，我都工作4年了，現(xiàn)在還問這道！其出現(xiàn)頻率，不下于HashMap的出現(xiàn)頻率！該問題有很多問法，例如spring事務有哪些坑?你用spring事務的時候，有遇到過什么問題么？其實答案都一樣的，OK，不羅嗦了，開始答案！

我們知道spring事務的原理是AOP，進行了切面增強，那么失效的根本原因是這個AOP不起作用了！常見情況有如下幾種
(1)發(fā)生自調(diào)用
例如代碼如下

@Service
public?class?UserService{
???public?void?update(User?user)?{
????????updateUser(user);
????}

????@Transactional
????public?void?updateUser(User?user)?{
????????System.out.println("孤獨煙真帥");
????????//do?something
????}

}

此時是無效的，因此上面的代碼等同于

@Service
public?class?UserService{
???public?void?update(User?user)?{
????????this.updateUser(user);
????}

????@Transactional
????public?void?updateUser(User?user)?{
????????System.out.println("孤獨煙真帥");
????????//do?something
????}

}

此時這個this對象不是代理類，而是UserService對象本身！
解決方法很簡單，讓那個this變成UserService的代理類即可，就不展開說明了！

(2)方法不是public的
OK，我這里不想舉源碼。大家想一個邏輯就行！
@Transactional注解的方法都是被外部其他類調(diào)用才有效！
如果方法修飾符是private的，這個方法能被外部其他類調(diào)到么？
既然調(diào)不到，事務生效有意義么？
想通這套邏輯就行了~~

記住:@Transactional 注解只能應用到 public 可見度的方法上。如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不會報錯， 但是這個被注解的方法將不會有事務行為。

ps:先這么理解就好了，因為真的去翻原因，就要貼代碼了，這文章可讀性就很差了。

(3)發(fā)生了錯誤異常
這個問題在第二問講過了，因為默認回滾的是：RuntimeException。如果是其他異常想要回滾，需要在@Transactional注解上加rollbackFor屬性。
又或者是異常被吞了，事務也會失效，不贅述！

(4)數(shù)據(jù)庫不支持事務
畢竟spring事務用的是數(shù)據(jù)庫的事務，如果數(shù)據(jù)庫不支持事務，那spring事務肯定是無法生效滴！

OK，答到這里就夠了！

可能有的讀者會說了

煙哥啊，其他文章里說什么數(shù)據(jù)源沒有配置事務管理器也會導致事務失效，你怎么沒提？

OK，我為什么不提，因為這種情況屬于你配置的不對！隨便少一個配置都會導致事務不生效，例如我們在Springboot中的Application類上不加注解@EnableTransactionManagement，也會使事務不生效，難道您能將每種情況下的配置背下來？這種配置的東西，臨時查詢即可！再比如，你把隔離級別配置成

@Transactional(propagation?=?Propagation.NOT_SUPPORTED)

該隔離級別表示不以事務運行，當前若存在事務則掛起，事務肯定不生效??！這種屬于自己配錯的情況，如果真要舉例，面試官也不愛聽的！在面試中，一句"配置錯誤也會導致事務不生效，例如xxx配置，舉一兩個即可！"

4、Spring的事務隔離和數(shù)據(jù)庫的事務隔離是一個概念么？
OK，是一回事！
我們先明確一點，數(shù)據(jù)庫一般有四種隔離級別
數(shù)據(jù)庫有四種隔離級別分別為

• read uncommitted（未提交讀）

• read committed（提交讀、不可重復讀）

• repeatable read（可重復讀）

• serializable（可串行化）

而spring只是在此基礎(chǔ)上抽象出一種隔離級別為default，表示以數(shù)據(jù)庫默認配置的為主。例如，mysql默認的事務隔離級別為repeatable-read。而Oracle 默認隔離級別為讀已提交。

于是乎，有一個經(jīng)典問題是這么問的

我數(shù)據(jù)庫的配置隔離級別是Read Commited,而Spring配置的隔離級別是Repeatable Read，請問這時隔離級別是以哪一個為準？

OK，以Spring配置的為準。JDBC有一個接口是這樣的

void?setTransactionIsolation(int?level)?throws?SQLException;

該接口用來設(shè)置事務的隔離級別。
那么在DataSourceUtils中，有一段代碼是這樣的

5、spring事務控制放在service層，在service方法中一個方法調(diào)用service中的另一個方法，默認開啟幾個事務？
此題考查的是spring的事務傳播行為
我們都知道，默認的傳播行為是PROPAGATION_REQUIRED，如果外層有事務，則當前事務加入到外層事務，一塊提交，一塊回滾。如果外層沒有事務，新建一個事務執(zhí)行！
也就是說，默認情況下只有一個事務！

當然這種時候如果面試官繼續(xù)追問其他傳播行為的情形，如何回答？

那我們應該？我們應該？把每種傳播機制都拿出來講一遍？沒必要，這種時候直接掀桌子走人。因為你就算背下來了，過幾天還是忘記。用到的時候，再去查詢即可。

6、怎么保證spring事務內(nèi)的連接唯一性？
這道題很多種問法，例如Spring 是如何保證事務獲取同一個Connection的?

OK,開始我們的講解！其實答案只有一句話，因為那個Connection在事務開始時封裝在了ThreadLocal里，后面事務執(zhí)行過程中，都是從ThreadLocal中取的，肯定能保證唯一，因為都是在一個線程中執(zhí)行的!

至于代碼。。。以JDBCTemplate的execute方法為例，看看下面那張圖就懂了。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝