一文帶你深入理解 Spring 事務(wù)原理

一文帶你深入理解Spring事務(wù)原理Spring事務(wù)的基本原理Spring事務(wù)的本質(zhì)其實(shí)就是數(shù)據(jù)庫對(duì)事務(wù)的支持，沒有數(shù)據(jù)庫的事務(wù)支持，spring是無法提供事務(wù)功能的。對(duì)于純JDBC操作數(shù)據(jù)庫，想要用到事務(wù)，可以按照以下步驟進(jìn)行：獲取連接Connectioncon=DriverManager.getConnection()開啟事務(wù)con.setAutoCommit(true/false);執(zhí)行CRUD提交事務(wù)/回滾事務(wù)mit()/con.rollback();關(guān)閉連接conn.close();使用Spring的事務(wù)管理功能后，我們可以不再寫步驟2和4的代碼，而是由Spirng自動(dòng)完成。那么Spring是如何在我們書寫的CRUD之前和之后開啟事務(wù)和關(guān)閉事務(wù)的呢？解決這個(gè)問題，也就可以從整體上理解Spring的事務(wù)管理實(shí)現(xiàn)原理了。下面簡單地介紹下，注解方式為例子配置文件開啟注解驅(qū)動(dòng)，在相關(guān)的類和方法上通過注解@Transactional標(biāo)識(shí)。spring在啟動(dòng)的時(shí)候會(huì)去解析生成相關(guān)的bean，這時(shí)候會(huì)查看擁有相關(guān)注解的類和方法，并且為這些類和方法生成代理，并根據(jù)@Transaction的相關(guān)參數(shù)進(jìn)行相關(guān)配置注入，這樣就在代理中為我們把相關(guān)的事務(wù)處理掉了（開啟正常提交事務(wù)，異常回滾事務(wù)）。真正的數(shù)據(jù)庫層的事務(wù)提交和回滾是通過binlog或者redolog實(shí)現(xiàn)的。Spring的事務(wù)機(jī)制所有的數(shù)據(jù)訪問技術(shù)都有事務(wù)處理機(jī)制，這些技術(shù)提供了API用來開啟事務(wù)、提交事務(wù)來完成數(shù)據(jù)操作，或者在發(fā)生錯(cuò)誤的時(shí)候回滾數(shù)據(jù)。而Spring的事務(wù)機(jī)制是用統(tǒng)一的機(jī)制來處理不同數(shù)據(jù)訪問技術(shù)的事務(wù)處理。Spring的事務(wù)機(jī)制提供了一個(gè)PlatformTransactionManager接口，不同的數(shù)據(jù)訪問技術(shù)的事務(wù)使用不同的接口實(shí)現(xiàn)，如表所示。數(shù)據(jù)訪問技術(shù)及實(shí)現(xiàn)在程序中定義事務(wù)管理器的代碼如下：@Bean

public

PlatformTransactionManager

transactionManager()

{

JpaTransactionManager

transactionManager

=

new

JpaTransactionManager();

transactionManager.setDataSource(dataSource());

return

transactionManager;

}聲明式事務(wù)Spring支持聲明式事務(wù)，即使用注解來選擇需要使用事務(wù)的方法，它使用@Transactional注解在方法上表明該方法需要事務(wù)支持。這是一個(gè)基于AOP的實(shí)現(xiàn)操作。@Transactional

public

void

saveSomething(Long

id,

String

name)

{

//數(shù)據(jù)庫操作

}在此處需要特別注意的是，此@Transactional注解來自org.springframework.transaction.annotation包，而不是javax.transaction。在公眾號(hào)頂級(jí)架構(gòu)師回復(fù)“架構(gòu)整潔”，獲取驚喜禮包。AOP代理的兩種實(shí)現(xiàn)：jdk是代理接口，私有方法必然不會(huì)存在在接口里，所以就不會(huì)被攔截到；cglib是子類，private的方法照樣不會(huì)出現(xiàn)在子類里，也不能被攔截。Java動(dòng)態(tài)代理。具體有如下四步驟：通過實(shí)現(xiàn)InvocationHandler接口創(chuàng)建自己的調(diào)用處理器；通過為Proxy類指定ClassLoader對(duì)象和一組interface來創(chuàng)建動(dòng)態(tài)代理類；通過反射機(jī)制獲得動(dòng)態(tài)代理類的構(gòu)造函數(shù)，其唯一參數(shù)類型是調(diào)用處理器接口類型；通過構(gòu)造函數(shù)創(chuàng)建動(dòng)態(tài)代理類實(shí)例，構(gòu)造時(shí)調(diào)用處理器對(duì)象作為參數(shù)被傳入。GCLIB代理cglib（CodeGenerationLibrary）是一個(gè)強(qiáng)大的,高性能,高質(zhì)量的Code生成類庫。它可以在運(yùn)行期擴(kuò)展Java類與實(shí)現(xiàn)Java接口。cglib封裝了asm，可以在運(yùn)行期動(dòng)態(tài)生成新的class（子類）。cglib用于AOP，jdk中的proxy必須基于接口，cglib卻沒有這個(gè)限制。原理區(qū)別：java動(dòng)態(tài)代理是利用反射機(jī)制生成一個(gè)實(shí)現(xiàn)代理接口的匿名類，在調(diào)用具體方法前調(diào)用InvokeHandler來處理。而cglib動(dòng)態(tài)代理是利用asm開源包，對(duì)代理對(duì)象類的class文件加載進(jìn)來，通過修改其字節(jié)碼生成子類來處理。如果目標(biāo)對(duì)象實(shí)現(xiàn)了接口，默認(rèn)情況下會(huì)采用JDK的動(dòng)態(tài)代理實(shí)現(xiàn)AOP如果目標(biāo)對(duì)象實(shí)現(xiàn)了接口，可以強(qiáng)制使用CGLIB實(shí)現(xiàn)AOP如果目標(biāo)對(duì)象沒有實(shí)現(xiàn)了接口，必須采用CGLIB庫，spring會(huì)自動(dòng)在JDK動(dòng)態(tài)代理和CGLIB之間轉(zhuǎn)換如果是類內(nèi)部方法直接不是走代理，這個(gè)時(shí)候可以通過維護(hù)一個(gè)自身實(shí)例的代理。@Service

public

class

PersonServiceImpl

implements

PersonService

{

@Autowired

PersonRepository

personRepository;

//

注入自身代理對(duì)象，在本類內(nèi)部方法調(diào)用事務(wù)的傳遞性才會(huì)生效

@Autowired

PersonService

selfProxyPersonService;

/**

*

測(cè)試事務(wù)的傳遞性

*

*

@param

person

*

@return

*/

@Transactional

public

Person

save(Person

person)

{

Person

p

=

personRepository.save(person);

try

{

//

新開事務(wù)

獨(dú)立回滾

selfProxyPersonService.delete();

}

catch

(Exception

e)

{

e.printStackTrace();

}

try

{

//

使用當(dāng)前事務(wù)

全部回滾

selfProxyPersonService.save2(person);

}

catch

(Exception

e)

{

e.printStackTrace();

}

personRepository.save(person);

return

p;

}

@Transactional

public

void

save2(Person

person)

{

personRepository.save(person);

throw

new

RuntimeException();

}

@Transactional(propagation

=

Propagation.REQUIRES_NEW)

public

void

delete()

{

personRepository.delete(1L);

throw

new

RuntimeException();

}

}Spring事務(wù)的傳播屬性所謂spring事務(wù)的傳播屬性，就是定義在存在多個(gè)事務(wù)同時(shí)存在的時(shí)候，spring應(yīng)該如何處理這些事務(wù)的行為。這些屬性在TransactionDefinition中定義，具體常量的解釋見下表：數(shù)據(jù)庫隔離級(jí)別臟讀：一事務(wù)對(duì)數(shù)據(jù)進(jìn)行了增刪改，但未提交，另一事務(wù)可以讀取到未提交的數(shù)據(jù)。如果第一個(gè)事務(wù)這時(shí)候回滾了，那么第二個(gè)事務(wù)就讀到了臟數(shù)據(jù)。不可重復(fù)讀：一個(gè)事務(wù)中發(fā)生了兩次讀操作，第一次讀操作和第二次操作之間，另外一個(gè)事務(wù)對(duì)數(shù)據(jù)進(jìn)行了修改，這時(shí)候兩次讀取的數(shù)據(jù)是不一致的?；米x：第一個(gè)事務(wù)對(duì)一定范圍的數(shù)據(jù)進(jìn)行批量修改，第二個(gè)事務(wù)在這個(gè)范圍增加一條數(shù)據(jù)，這時(shí)候第一個(gè)事務(wù)就會(huì)丟失對(duì)新增數(shù)據(jù)的修改?？偨Y(jié)：隔離級(jí)別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對(duì)并發(fā)性能的影響也越大。大多數(shù)的數(shù)據(jù)庫默認(rèn)隔離級(jí)別為ReadCommited，比如SqlServer、Oracle少數(shù)數(shù)據(jù)庫默認(rèn)隔離級(jí)別為：RepeatableRead比如：MySQLInnoDBSpring中的隔離級(jí)別事務(wù)的嵌套通過上面的理論知識(shí)的鋪墊，我們大致知道了數(shù)據(jù)庫事務(wù)和spring事務(wù)的一些屬性和特點(diǎn)，接下來我們通過分析一些嵌套事務(wù)的場(chǎng)景，來深入理解spring事務(wù)傳播的機(jī)制。搜索公眾號(hào)后端架構(gòu)師后臺(tái)回復(fù)“面試”，獲取一份驚喜禮包。假設(shè)外層事務(wù)ServiceA的MethodA()調(diào)用內(nèi)層ServiceB的MethodB()PROPAGATION_REQUIRED(spring默認(rèn))如果ServiceB.methodB()的事務(wù)級(jí)別定義為PROPAGATION_REQUIRED，那么執(zhí)行ServiceA.methodA()的時(shí)候spring已經(jīng)起了事務(wù)，這時(shí)調(diào)用ServiceB.methodB()，ServiceB.methodB()看到自己已經(jīng)運(yùn)行在ServiceA.methodA()的事務(wù)內(nèi)部，就不再起新的事務(wù)。假如ServiceB.methodB()運(yùn)行的時(shí)候發(fā)現(xiàn)自己沒有在事務(wù)中，他就會(huì)為自己分配一個(gè)事務(wù)。這樣，在ServiceA.methodA()或者在ServiceB.methodB()內(nèi)的任何地方出現(xiàn)異常，事務(wù)都會(huì)被回滾。PROPAGATION_REQUIRES_NEW比如我們?cè)O(shè)計(jì)ServiceA.methodA()的事務(wù)級(jí)別為PROPAGATION_REQUIRED，ServiceB.methodB()的事務(wù)級(jí)別為PROPAGATION_REQUIRES_NEW。那么當(dāng)執(zhí)行到ServiceB.methodB()的時(shí)候，ServiceA.methodA()所在的事務(wù)就會(huì)掛起，ServiceB.methodB()會(huì)起一個(gè)新的事務(wù)，等待ServiceB.methodB()的事務(wù)完成以后，它才繼續(xù)執(zhí)行。他與PROPAGATION_REQUIRED的事務(wù)區(qū)別在于事務(wù)的回滾程度了。因?yàn)镾erviceB.methodB()是新起一個(gè)事務(wù)，那么就是存在兩個(gè)不同的事務(wù)。如果ServiceB.methodB()已經(jīng)提交，那么ServiceA.methodA()失敗回滾，ServiceB.methodB()是不會(huì)回滾的。如果ServiceB.methodB()失敗回滾，如果他拋出的異常被ServiceA.methodA()捕獲，ServiceA.methodA()事務(wù)仍然可能提交(主要看B拋出的異常是不是A會(huì)回滾的異常)。PROPAGATION_SUPPORTS假設(shè)ServiceB.methodB()的事務(wù)級(jí)別為PROPAGATION_SUPPORTS，那么當(dāng)執(zhí)行到ServiceB.methodB()時(shí)，如果發(fā)現(xiàn)ServiceA.methodA()已經(jīng)開啟了一個(gè)事務(wù)，則加入當(dāng)前的事務(wù)，如果發(fā)現(xiàn)ServiceA.methodA()沒有開啟事務(wù)，則自己也不開啟事務(wù)。這種時(shí)候，內(nèi)部方法的事務(wù)性完全依賴于最外層的事務(wù)。PROPAGATION_NESTED現(xiàn)在的情況就變得比較復(fù)雜了,ServiceB.methodB()的事務(wù)屬性被配置為PROPAGATION_NESTED,此時(shí)兩者之間又將如何協(xié)作呢?ServiceB#methodB如果rollback,那么內(nèi)部事務(wù)(即ServiceB#methodB)將回滾到它執(zhí)行前的SavePoint而外部事務(wù)(即ServiceA#methodA)可以有以下兩種處理方式:a、捕獲異常，執(zhí)行異常分支邏輯void

methodA()

{

try

{

ServiceB.methodB();

}

catch

(SomeException)

{

//

執(zhí)行其他業(yè)務(wù),

如

ServiceC.methodC();

}

}這種方式也是嵌套事務(wù)最有價(jià)值的地方,它起到了分支執(zhí)行的效果,如果ServiceB.methodB失敗,那么執(zhí)行ServiceC.methodC(),而ServiceB.methodB已經(jīng)回滾到它執(zhí)行之前的SavePoint,所以不會(huì)產(chǎn)生臟數(shù)據(jù)(相當(dāng)于此方法從未執(zhí)行過),這種特性可以用在某些特殊的業(yè)務(wù)中,而PROPAGATION_REQUIRED和PROPAGATION_REQUIRES_NEW都沒有辦法做到這一點(diǎn)。b、外部事務(wù)回滾/提交代碼不做任何修改，那么如果內(nèi)部事務(wù)(ServiceB#methodB)rollback,那么首先ServiceB.methodB回滾到它執(zhí)行之前的SavePoint(在任何情況下都會(huì)如此),外部事務(wù)(即ServiceA#methodA)將根據(jù)具體的配置決定自己是commit還是rollback另外三種事務(wù)傳播屬性基本用不到，在此不做分析?？偨Y(jié)對(duì)于項(xiàng)目中需要使用到事務(wù)的地方，我建議開發(fā)者還是使用spring的TransactionCallback接口來實(shí)現(xiàn)事務(wù)，不要盲目使用spring事務(wù)注解，如果一定要使用注解，那么一定要對(duì)spring事務(wù)的傳播機(jī)制和隔離級(jí)別有個(gè)詳細(xì)的了解，否則很可能發(fā)生意想不到的效果。SpringBoot對(duì)事務(wù)的支持通過org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration類。我們可以看出SpringBoot自動(dòng)開啟了對(duì)注解事務(wù)的支持Spring只讀事務(wù)（@Transactional(readOnly=true)）的一些概念概念：從這一點(diǎn)設(shè)置的時(shí)間點(diǎn)開始（時(shí)間點(diǎn)a）到這個(gè)事務(wù)結(jié)束的過程中，其他事務(wù)所提交的數(shù)