一文帶你深入理解 Spring 事務原理
作者:xiaolyuh
來源:my.oschina.net/xiaolyuh/blog/3109049
Spring 事務的基本原理
Spring 事務的本質其實就是數據庫對事務的支持,沒有數據庫的事務支持,spring 是無法提供事務功能的。對於純 JDBC 操作數據庫,想要用到事務,可以按照以下步驟進行:
-
獲取連接 Connection con = DriverManager.getConnection()
-
開啓事務 con.setAutoCommit(true/false);
-
執行 CRUD
-
提交事務 / 回滾事務 con.commit() / con.rollback();
-
關閉連接 conn.close();
使用 Spring 的事務管理功能後,我們可以不再寫步驟 2 和 4 的代碼,而是由 Spirng 自動完成。那麼 Spring 是如何在我們書寫的 CRUD 之前和之後開啓事務和關閉事務的呢?解決這個問題,也就可以從整體上理解 Spring 的事務管理實現原理了。
下面簡單地介紹下,註解方式爲例子
-
配置文件開啓註解驅動,在相關的類和方法上通過註解 @Transactional 標識。
-
spring 在啓動的時候會去解析生成相關的 bean,這時候會查看擁有相關注解的類和方法,並且爲這些類和方法生成代理,並根據 @Transaction 的相關參數進行相關配置注入,這樣就在代理中爲我們把相關的事務處理掉了(開啓正常提交事務,異常回滾事務)。
-
真正的數據庫層的事務提交和回滾是通過 binlog 或者 redo log 實現的。
Spring 的事務機制
所有的數據訪問技術都有事務處理機制,這些技術提供了 API 用來開啓事務、提交事務來完成數據操作,或者在發生錯誤的時候回滾數據。
而 Spring 的事務機制是用統一的機制來處理不同數據訪問技術的事務處理。Spring 的事務機制提供了一個 PlatformTransactionManager 接口,不同的數據訪問技術的事務使用不同的接口實現,如表所示。
數據訪問技術及實現
在程序中定義事務管理器的代碼如下:
@Bean
public PlatformTransactionManager transactionManager() {
JpaTransactionManager transactionManager = new JpaTransactionManager();
transactionManager.setDataSource(dataSource());
return transactionManager;
}
聲明式事務
Spring 支持聲明式事務,即使用註解來選擇需要使用事務的方法,它使用 @Transactional 註解在方法上表明該方法需要事務支持。這是一個基於 AOP 的實現操作。
@Transactional
public void saveSomething(Long id, String name) {
//數據庫操作
}
在此處需要特別注意的是,此 @Transactional 註解來自 org.springframework.transaction.annotation 包,而不是 javax.transaction。
在公衆號頂級架構師回覆 “架構整潔”,獲取驚喜禮包。
AOP 代理的兩種實現:
-
jdk 是代理接口,私有方法必然不會存在在接口裏,所以就不會被攔截到;
-
cglib 是子類,private 的方法照樣不會出現在子類裏,也不能被攔截。
Java 動態代理。
具體有如下四步驟:
-
通過實現 InvocationHandler 接口創建自己的調用處理器;
-
通過爲 Proxy 類指定 ClassLoader 對象和一組 interface 來創建動態代理類;
-
通過反射機制獲得動態代理類的構造函數,其唯一參數類型是調用處理器接口類型;
-
通過構造函數創建動態代理類實例,構造時調用處理器對象作爲參數被傳入。
GCLIB 代理
cglib(Code Generation Library)是一個強大的, 高性能, 高質量的 Code 生成類庫。它可以在運行期擴展 Java 類與實現 Java 接口。
-
cglib 封裝了 asm,可以在運行期動態生成新的 class(子類)。
-
cglib 用於 AOP,jdk 中的 proxy 必須基於接口,cglib 卻沒有這個限制。
原理區別:
java 動態代理是利用反射機制生成一個實現代理接口的匿名類,在調用具體方法前調用 InvokeHandler 來處理。而 cglib 動態代理是利用 asm 開源包,對代理對象類的 class 文件加載進來,通過修改其字節碼生成子類來處理。
-
如果目標對象實現了接口,默認情況下會採用 JDK 的動態代理實現 AOP
-
如果目標對象實現了接口,可以強制使用 CGLIB 實現 AOP
-
如果目標對象沒有實現了接口,必須採用 CGLIB 庫,spring 會自動在 JDK 動態代理和 CGLIB 之間轉換
如果是類內部方法直接不是走代理,這個時候可以通過維護一個自身實例的代理。
@Service
public class PersonServiceImpl implements PersonService {
@Autowired
PersonRepository personRepository;
// 注入自身代理對象,在本類內部方法調用事務的傳遞性纔會生效
@Autowired
PersonService selfProxyPersonService;
/**
* 測試事務的傳遞性
*
* @param person
* @return
*/
@Transactional
public Person save(Person person) {
Person p = personRepository.save(person);
try {
// 新開事務 獨立回滾
selfProxyPersonService.delete();
} catch (Exception e) {
e.printStackTrace();
}
try {
// 使用當前事務 全部回滾
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 事務的傳播屬性
所謂 spring 事務的傳播屬性,就是定義在存在多個事務同時存在的時候,spring 應該如何處理這些事務的行爲。這些屬性在 TransactionDefinition 中定義,具體常量的解釋見下表:
數據庫隔離級別
**髒讀:**一事務對數據進行了增刪改,但未提交,另一事務可以讀取到未提交的數據。如果第一個事務這時候回滾了,那麼第二個事務就讀到了髒數據。
**不可重複讀:**一個事務中發生了兩次讀操作,第一次讀操作和第二次操作之間,另外一個事務對數據進行了修改,這時候兩次讀取的數據是不一致的。
**幻讀:**第一個事務對一定範圍的數據進行批量修改,第二個事務在這個範圍增加一條數據,這時候第一個事務就會丟失對新增數據的修改。
總結:
隔離級別越高,越能保證數據的完整性和一致性,但是對併發性能的影響也越大。
大多數的數據庫默認隔離級別爲 Read Commited,比如 SqlServer、Oracle
少數數據庫默認隔離級別爲:Repeatable Read 比如:MySQL InnoDB
Spring 中的隔離級別
事務的嵌套
通過上面的理論知識的鋪墊,我們大致知道了數據庫事務和 spring 事務的一些屬性和特點,接下來我們通過分析一些嵌套事務的場景,來深入理解 spring 事務傳播的機制。
搜索公衆號後端架構師後臺回覆 “面試”,獲取一份驚喜禮包。
假設外層事務 Service A 的 Method A() 調用 內層 Service B 的 Method B()
PROPAGATION_REQUIRED(spring 默認)
如果 ServiceB.methodB() 的事務級別定義爲 PROPAGATION_REQUIRED,那麼執行 ServiceA.methodA() 的時候 spring 已經起了事務,這時調用 ServiceB.methodB(),ServiceB.methodB() 看到自己已經運行在 ServiceA.methodA() 的事務內部,就不再起新的事務。
假如 ServiceB.methodB() 運行的時候發現自己沒有在事務中,他就會爲自己分配一個事務。
這樣,在 ServiceA.methodA() 或者在 ServiceB.methodB() 內的任何地方出現異常,事務都會被回滾。
PROPAGATION_REQUIRES_NEW
比如我們設計 ServiceA.methodA() 的事務級別爲 PROPAGATION_REQUIRED,ServiceB.methodB() 的事務級別爲 PROPAGATION_REQUIRES_NEW。
那麼當執行到 ServiceB.methodB() 的時候,ServiceA.methodA() 所在的事務就會掛起,ServiceB.methodB() 會起一個新的事務,等待 ServiceB.methodB() 的事務完成以後,它才繼續執行。
他與 PROPAGATION_REQUIRED 的事務區別在於事務的回滾程度了。因爲 ServiceB.methodB() 是新起一個事務,那麼就是存在兩個不同的事務。如果 ServiceB.methodB() 已經提交,那麼 ServiceA.methodA() 失敗回滾,ServiceB.methodB() 是不會回滾的。如果 ServiceB.methodB() 失敗回滾,如果他拋出的異常被 ServiceA.methodA() 捕獲,ServiceA.methodA() 事務仍然可能提交 (主要看 B 拋出的異常是不是 A 會回滾的異常)。
PROPAGATION_SUPPORTS
假設 ServiceB.methodB() 的事務級別爲 PROPAGATION_SUPPORTS,那麼當執行到 ServiceB.methodB() 時,如果發現 ServiceA.methodA() 已經開啓了一個事務,則加入當前的事務,如果發現 ServiceA.methodA() 沒有開啓事務,則自己也不開啓事務。這種時候,內部方法的事務性完全依賴於最外層的事務。
PROPAGATION_NESTED
現在的情況就變得比較複雜了, ServiceB.methodB() 的事務屬性被配置爲 PROPAGATION_NESTED, 此時兩者之間又將如何協作呢? ServiceB#methodB 如果 rollback, 那麼內部事務 (即 ServiceB#methodB) 將回滾到它執行前的 SavePoint 而外部事務 (即 ServiceA#methodA) 可以有以下兩種處理方式:
a、捕獲異常,執行異常分支邏輯
void methodA() {
try {
ServiceB.methodB();
} catch (SomeException) {
// 執行其他業務, 如 ServiceC.methodC();
}
}
這種方式也是嵌套事務最有價值的地方, 它起到了分支執行的效果, 如果 ServiceB.methodB 失敗, 那麼執行 ServiceC.methodC(), 而 ServiceB.methodB 已經回滾到它執行之前的 SavePoint, 所以不會產生髒數據 (相當於此方法從未執行過), 這種特性可以用在某些特殊的業務中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都沒有辦法做到這一點。
b、 外部事務回滾 / 提交 代碼不做任何修改, 那麼如果內部事務 (ServiceB#methodB) rollback, 那麼首先 ServiceB.methodB 回滾到它執行之前的 SavePoint(在任何情況下都會如此), 外部事務 (即 ServiceA#methodA) 將根據具體的配置決定自己是 commit 還是 rollback
另外三種事務傳播屬性基本用不到,在此不做分析。
總結
對於項目中需要使用到事務的地方,我建議開發者還是使用 spring 的 TransactionCallback 接口來實現事務,不要盲目使用 spring 事務註解,如果一定要使用註解,那麼一定要對 spring 事務的傳播機制和隔離級別有個詳細的瞭解,否則很可能發生意想不到的效果。
Spring Boot 對事務的支持
通過org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
類。我們可以看出 Spring Boot 自動開啓了對註解事務的支持 Spring
只讀事務(@Transactional(readOnly = true))的一些概念
概念:
從這一點設置的時間點開始(時間點 a)到這個事務結束的過程中,其他事務所提交的數據,該事務將看不見!(查詢中不會出現別人在時間點 a 之後提交的數據)。
@Transcational(readOnly=true) 這個註解一般會寫在業務類上,或者其方法上,用來對其添加事務控制。當括號中添加 readOnly=true, 則會告訴底層數據源,這個是一個只讀事務,對於 JDBC 而言,只讀事務會有一定的速度優化。
而這樣寫的話,事務控制的其他配置則採用默認值,事務的隔離級別 (isolation) 爲 DEFAULT, 也就是跟隨底層數據源的隔離級別,事務的傳播行爲(propagation) 則是 REQUIRED,所以還是會有事務存在,一代在代碼中拋出 RuntimeException,依然會導致事務回滾。
應用場合:
-
如果你一次執行單條查詢語句,則沒有必要啓用事務支持,數據庫默認支持 SQL 執行期間的讀一致性;
-
如果你一次執行多條查詢語句,例如統計查詢,報表查詢,在這種場景下,多條查詢 SQL 必須保證整體的讀一致性,否則,在前條 SQL 查詢之後,後條 SQL 查詢之前,數據被其他用戶改變,則該次整體的統計查詢將會出現讀數據不一致的狀態,此時,應該啓用事務支持。
【注意是一次執行多次查詢來統計某些信息,這時爲了保證數據整體的一致性,要用只讀事務】
參考:
http://www.codeceo.com/article/spring-transactions.html
http://www.cnblogs.com/fenglie/articles/4097759.html
https://www.zhihu.com/question/39074428/answer/88581202
http://blog.csdn.net/andyzhaojianhui/article/details/51984157
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/4upfOMWYEuLc3wUQm8XvBg