引言

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

由于《面試官:談?wù)勀銓?duì)mysql事務(wù)的認(rèn)識(shí)》篇幅所限，因此略過了spring事務(wù)相關(guān)常見面試題，今天給大家補(bǔ)上！主要題目如下:

• (1)spring事務(wù)的原理?

• (2)spring什么情況下進(jìn)行事務(wù)回滾？

• (3)spring事務(wù)什么時(shí)候失效?

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

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

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

正文

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

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

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

• (3)執(zhí)行CRUD

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

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

  
  

  
  

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

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

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

}

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

@Transactional(rollbackFor?=?Exception.class)

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

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

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

TransactionAspectSupport.currentTransactionStatus()
.setRollbackOnly();

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

我們知道spring事務(wù)的原理是AOP，進(jìn)行了切面增強(qiáng)，那么失效的根本原因是這個(gè)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("孤獨(dú)煙真帥");
????????//do?something
????}

}

此時(shí)是無效的，因此上面的代碼等同于

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

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

}

此時(shí)這個(gè)this對(duì)象不是代理類，而是UserService對(duì)象本身！
解決方法很簡(jiǎn)單，讓那個(gè)this變成UserService的代理類即可，就不展開說明了！

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

記住:@Transactional 注解只能應(yīng)用到 public 可見度的方法上。如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不會(huì)報(bào)錯(cuò)， 但是這個(gè)被注解的方法將不會(huì)有事務(wù)行為。

ps:先這么理解就好了，因?yàn)檎娴娜シ颍鸵N代碼了，這文章可讀性就很差了。

(3)發(fā)生了錯(cuò)誤異常
這個(gè)問題在第二問講過了，因?yàn)槟J(rèn)回滾的是：RuntimeException。如果是其他異常想要回滾，需要在@Transactional注解上加rollbackFor屬性。
又或者是異常被吞了，事務(wù)也會(huì)失效，不贅述！

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

OK，答到這里就夠了！

可能有的讀者會(huì)說了

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

OK，我為什么不提，因?yàn)檫@種情況屬于你配置的不對(duì)！隨便少一個(gè)配置都會(huì)導(dǎo)致事務(wù)不生效，例如我們?cè)赟pringboot中的Application類上不加注解@EnableTransactionManagement，也會(huì)使事務(wù)不生效，難道您能將每種情況下的配置背下來？這種配置的東西，臨時(shí)查詢即可！再比如，你把隔離級(jí)別配置成

@Transactional(propagation?=?Propagation.NOT_SUPPORTED)

該隔離級(jí)別表示不以事務(wù)運(yùn)行，當(dāng)前若存在事務(wù)則掛起，事務(wù)肯定不生效??！這種屬于自己配錯(cuò)的情況，如果真要舉例，面試官也不愛聽的！在面試中，一句"配置錯(cuò)誤也會(huì)導(dǎo)致事務(wù)不生效，例如xxx配置，舉一兩個(gè)即可！"

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

• read uncommitted（未提交讀）

• read committed（提交讀、不可重復(fù)讀）

• repeatable read（可重復(fù)讀）

• serializable（可串行化）

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

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

我數(shù)據(jù)庫的配置隔離級(jí)別是Read Commited,而Spring配置的隔離級(jí)別是Repeatable Read，請(qǐng)問這時(shí)隔離級(jí)別是以哪一個(gè)為準(zhǔn)？

OK，以Spring配置的為準(zhǔn)。JDBC有一個(gè)接口是這樣的

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

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

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

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

那我們應(yīng)該？我們應(yīng)該？把每種傳播機(jī)制都拿出來講一遍？沒必要，這種時(shí)候直接掀桌子走人。因?yàn)槟憔退惚诚聛砹?，過幾天還是忘記。用到的時(shí)候，再去查詢即可。

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

OK,開始我們的講解！其實(shí)答案只有一句話，因?yàn)槟莻€(gè)Connection在事務(wù)開始時(shí)封裝在了ThreadLocal里，后面事務(wù)執(zhí)行過程中，都是從ThreadLocal中取的，肯定能保證唯一，因?yàn)槎际窃谝粋€(gè)線程中執(zhí)行的!

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

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

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝