Spring有5種隔離級(jí)別，7種傳播行為。這是面試常問(wèn)的內(nèi)容，也是代碼中經(jīng)常碰到的知識(shí)點(diǎn)。這些知識(shí)枯燥而且乏味，其中有些非常的繞。如果栽在這上面，就實(shí)在是太可惜了。

@Transactional(isloation=,propagation=,readOnly=,timeout=,rollbackFor=,noRollbackFor=,)

• isloation的值：
  

• propagation的值：
  

在一些事務(wù)的基礎(chǔ)上，再探討幾個(gè)容易淡忘的概念，從源碼層面找原因，加深我們的理解，問(wèn)題大概包括：

1.Spring的事務(wù)和數(shù)據(jù)庫(kù)的事務(wù)隔離是一個(gè)概念么？
2.Spring是如何實(shí)現(xiàn)事務(wù)的？
3.事務(wù)隔離機(jī)制都有哪些？
4.事務(wù)傳播機(jī)制都有哪些？
5.查詢語(yǔ)句需要開(kāi)事務(wù)么？
6.private方法加事務(wù)注解有用么？

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

先來(lái)第一個(gè)問(wèn)題，Spring的事務(wù)隔離級(jí)別和數(shù)據(jù)的事務(wù)隔離級(jí)別，是一回事么？
其實(shí)，數(shù)據(jù)庫(kù)一般只有4種隔離機(jī)制，Spring抽象出一種default，根據(jù)數(shù)據(jù)設(shè)置來(lái)變動(dòng)。

1.read uncommitted（未提交讀） 2.read committed（提交讀、不可重復(fù)讀） 3.repeatable read（可重復(fù)讀） 4.serializable（可串行化） 5.default （PlatformTransactionManager默認(rèn)的隔離級(jí)別，使用的就是數(shù)據(jù)庫(kù)默認(rèn)的）

這是因?yàn)?#xff0c;Spring只提供統(tǒng)一事務(wù)管理接口，具體實(shí)現(xiàn)都是由各數(shù)據(jù)庫(kù)自己實(shí)現(xiàn)（如MySQL）。Spring會(huì)在事務(wù)開(kāi)始時(shí)，根據(jù)當(dāng)前環(huán)境中設(shè)置的隔離級(jí)別，調(diào)整數(shù)據(jù)庫(kù)隔離級(jí)別，由此保持一致。在DataSourceUtils文件中，代碼詳細(xì)的輸出了這個(gè)過(guò)程。

// Apply specific isolation level, if any. Integer previousIsolationLevel = null; if (definition != null && definition.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT) {if (logger.isDebugEnabled()) {logger.debug("Changing isolation level of JDBC Connection [" + con + "] to " +definition.getIsolationLevel());}int currentIsolation = con.getTransactionIsolation();if (currentIsolation != definition.getIsolationLevel()) {previousIsolationLevel = currentIsolation;con.setTransactionIsolation(definition.getIsolationLevel());} }

結(jié)論：三種情況:

如果Spring沒(méi)有指定事務(wù)隔離級(jí)別，則會(huì)采用數(shù)據(jù)庫(kù)默認(rèn)的事務(wù)隔離級(jí)別；

當(dāng)Spring指定了事務(wù)隔離級(jí)別，則會(huì)在代碼里將事務(wù)隔離級(jí)別修改為指定值；

當(dāng)數(shù)據(jù)庫(kù)不支持這種隔離級(jí)別，效果則以數(shù)據(jù)庫(kù)的為準(zhǔn)（比如采用了MyISAM引擎）

我們會(huì)使用如下的方式進(jìn)行聲明。如果不是有性能和需求問(wèn)題，就不要瞎改。事務(wù)處理弄不好是會(huì)鎖表的，而鎖表在大并發(fā)的情況下是會(huì)死人的。

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

2、Spring事務(wù)的7種傳播機(jī)制

只要寫代碼，代碼總會(huì)存在嵌套，或者循環(huán)，造成了事務(wù)的嵌套或者循環(huán)。那么事務(wù)在這些情況下，根據(jù)配置會(huì)有不同的反應(yīng)。

REQUIRED
這是默認(rèn)的。表示當(dāng)前方法必須在一個(gè)具有事務(wù)的上下文中運(yùn)行，如有客戶端有事務(wù)在進(jìn)行，那么被調(diào)用端將在該事務(wù)中運(yùn)行，否則的話重新開(kāi)啟一個(gè)事務(wù)。（如果被調(diào)用端發(fā)生異常，那么調(diào)用端和被調(diào)用端事務(wù)都將回滾）

REQUIRE_NEW
表示當(dāng)前方法必須運(yùn)行在它自己的事務(wù)中。如果存在當(dāng)前事務(wù)，在該方法執(zhí)行期間，當(dāng)前事務(wù)會(huì)被掛起

NESTED
如果當(dāng)前方法正有一個(gè)事務(wù)在運(yùn)行中，則該方法應(yīng)該運(yùn)行在一個(gè)嵌套事務(wù)中，被嵌套的事務(wù)可以獨(dú)立于被封裝的事務(wù)中進(jìn)行提交或者回滾。如果封裝事務(wù)存在，并且外層事務(wù)拋出異常回滾，那么內(nèi)層事務(wù)必須回滾，反之，內(nèi)層事務(wù)并不影響外層事務(wù)。如果封裝事務(wù)不存在，則同required的一樣

SUPPORTS
表示當(dāng)前方法不必需要具有一個(gè)事務(wù)上下文，但是如果有一個(gè)事務(wù)的話，它也可以在這個(gè)事務(wù)中運(yùn)行

NOT_SUPPORTED
表示該方法不應(yīng)該在一個(gè)事務(wù)中運(yùn)行。如果有一個(gè)事務(wù)正在運(yùn)行，他將在運(yùn)行期被掛起，直到這個(gè)事務(wù)提交或者回滾才恢復(fù)執(zhí)行

MANDATORY
表示當(dāng)前方法必須在一個(gè)事務(wù)中運(yùn)行，如果沒(méi)有事務(wù)，將拋出異常

NEVER
表示當(dāng)方法務(wù)不應(yīng)該在一個(gè)事務(wù)中運(yùn)行，如果存在一個(gè)事務(wù)，則拋出異常

一般用得比較多的是REQUIRED ， REQUIRES_NEW，用到其他的，你就要小心了，搞懂再用。
最怕如果這倆字了，它會(huì)將事情搞的很復(fù)雜，尤其是代碼量大的時(shí)候，你永遠(yuǎn)不知道你寫的service會(huì)被誰(shuí)用到。這就很尷尬了。
我們會(huì)采用下面的方式進(jìn)行聲明。鑒于Spring的事務(wù)傳播非常的繞，如果功能滿足需求，那么就用默認(rèn)的就好，否則會(huì)引起不必要的麻煩。

@Transactional(propagation=Propagation.REQUIRED)

3、事務(wù)傳播機(jī)制是怎么實(shí)現(xiàn)的？

事務(wù)傳播機(jī)制看似神奇，實(shí)際上是使用簡(jiǎn)單的ThreadLocal的機(jī)制實(shí)現(xiàn)的。所以，如果調(diào)用的方法是在新線程調(diào)用的，事務(wù)傳播實(shí)際上是會(huì)失效的。這不同于我們以前講到的透?jìng)?#xff0c;Spring并沒(méi)有做這樣的處理。
所以事務(wù)傳播機(jī)制，只有翻一遍源代碼，才能印象深刻。僅靠文字去傳播，很多東西會(huì)變得不可描述。

如圖，PlatformTransactionManager只有簡(jiǎn)單的三個(gè)抽象接口，定義了包含JDBC在內(nèi)的Spring所有的事務(wù)操作。

我們平常說(shuō)的JDBC，只是占到其中一部分。
實(shí)現(xiàn)的方式，依然是使用AOP來(lái)實(shí)現(xiàn)的，具體的實(shí)現(xiàn)類是由TransactionAspectSupport來(lái)實(shí)現(xiàn)的。可以看到，代碼定義了一個(gè)叫做transactionInfoHolder的ThreadLocal變量，當(dāng)用到它的時(shí)候，就能夠確保在同一個(gè)線程下，獲取的變量是一致的。

/*** Holder to support the {@code currentTransactionStatus()} method,* and to support communication between different cooperating advices* (e.g. before and after advice) if the aspect involves more than a* single method (as will be the case for around advice). */ private static final ThreadLocal<TransactionInfo> transactionInfoHolder =new NamedThreadLocal<>("Current aspect-driven transaction");

具體的業(yè)務(wù)邏輯，是在invokeWithinTransaction中實(shí)現(xiàn)的。如果你繼續(xù)向下跟蹤的話，會(huì)找到AbstractPlatformTransactionManager類中的getTransaction方法。

@Override public final TransactionStatus getTransaction(@Nullable TransactionDefinition definition)throws TransactionException {// Use defaults if no transaction definition given.TransactionDefinition def = (definition != null ? definition : TransactionDefinition.withDefaults());Object transaction = doGetTransaction();boolean debugEnabled = logger.isDebugEnabled();if (isExistingTransaction(transaction)) {// Existing transaction found -> check propagation behavior to find out how to behave.return handleExistingTransaction(def, transaction, debugEnabled);}// Check definition settings for new transaction.if (def.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) {throw new InvalidTimeoutException("Invalid transaction timeout", def.getTimeout());}// No existing transaction found -> check propagation behavior to find out how to proceed.if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) {throw new IllegalTransactionStateException("No existing transaction found for transaction marked with propagation 'mandatory'");}else if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {SuspendedResourcesHolder suspendedResources = suspend(null);if (debugEnabled) {logger.debug("Creating new transaction with name [" + def.getName() + "]: " + def);}try {return startTransaction(def, transaction, debugEnabled, suspendedResources);}catch (RuntimeException | Error ex) {resume(null, suspendedResources);throw ex;}}else {// Create "empty" transaction: no actual transaction, but potentially synchronization.if (def.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT && logger.isWarnEnabled()) {logger.warn("Custom isolation level specified but no actual transaction initiated; " +"isolation level will effectively be ignored: " + def);}boolean newSynchronization = (getTransactionSynchronization() == SYNCHRONIZATION_ALWAYS);return prepareTransactionStatus(def, null, true, newSynchronization, debugEnabled, null);} }

不用我做過(guò)多解釋了吧，一切明顯的邏輯，都在代碼里。事務(wù)就是在這里創(chuàng)建的。

4、查詢方法可以不開(kāi)啟事務(wù)么？

事務(wù)有個(gè)readonly，控制了事務(wù)的只讀屬性，和事務(wù)是否開(kāi)啟沒(méi)半毛錢關(guān)系。
在以前的一篇文章中，談到通過(guò)設(shè)置readonly屬性來(lái)控制語(yǔ)句的路由：”MySQL官方驅(qū)動(dòng)“主從分離的神秘面紗（掃盲篇），這其中就用到了事務(wù)的其中一個(gè)屬性readonly，它最終是體現(xiàn)在數(shù)據(jù)庫(kù)連接層面的。

connection.setReadOnly(true);

在Spring中的使用方式如下：

@Transactional(readOnly=true)

值得注意的是，這個(gè)屬性設(shè)置之后，并不是每個(gè)底層的數(shù)據(jù)庫(kù)都支持。中間層的ORM或者驅(qū)動(dòng)，也可能會(huì)拿這個(gè)屬性做一些文章，所以與其說(shuō)這個(gè)readonly是功能性的，不如說(shuō)是一種暗示。
拿MySQL來(lái)說(shuō)，有兩種提交模式：

SET AUTOCOMMIT=0 禁止自動(dòng)提交 SET AUTOCOMMIT=1 開(kāi)啟自動(dòng)提交

這都是實(shí)打?qū)嵉腟QL語(yǔ)句，所以如果開(kāi)啟了事務(wù)，AUTOCOMMIT要為false。我們可以看到Spring做了以下幾個(gè)操作。

con.setAutoCommit(false);

如果是只讀事務(wù)，還不忘手動(dòng)設(shè)置一下。

if (isEnforceReadOnly() && definition.isReadOnly()) {try (Statement stmt = con.createStatement()) {stmt.executeUpdate("SET TRANSACTION READ ONLY");} }

這種操作是很昂貴的，如果不加Transaction注解，默認(rèn)是不開(kāi)啟事務(wù)的。單條的查詢語(yǔ)句也是沒(méi)有必要開(kāi)啟事務(wù)的，數(shù)據(jù)庫(kù)默認(rèn)的配置就能滿足需求。
但如果你一次執(zhí)行多條查詢語(yǔ)句，例如統(tǒng)計(jì)查詢，報(bào)表查詢，在這種場(chǎng)景下，多條查詢SQL必須保證整體的讀一致性，否則，在前條SQL查詢之后，后條SQL查詢之前，數(shù)據(jù)被其他用戶改變，就會(huì)造成數(shù)據(jù)的前后不一。也僅有在這種情況下，要開(kāi)啟讀事務(wù)。

5、private方法加事務(wù)注解有用么？

@Transaction注解加在private上，并沒(méi)有什么卵用。
這倒不是事務(wù)處理的代碼去寫的特性。由于事務(wù)的這些功能，是通過(guò)AOP方式強(qiáng)加進(jìn)去的，所以受收到動(dòng)態(tài)代理的控制。
private和final修飾的方法，不會(huì)被代理。
但是，你卻可以把private方法放在帶有事務(wù)功能的public方法里。這樣，它看起來(lái)也有了事務(wù)的一些功能特性，但它并沒(méi)有。

本文轉(zhuǎn)自

總結(jié)

以上是生活随笔為你收集整理的Spring事务传播机制和隔离级别的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。