共計 6121 個字符，預計需要花費 16 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關 Spring 事務的原理分析是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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 的相關參數進行相關配置注入，這樣就在代理中為我們把相關的事務處理掉了（開啟正常提交事務，異常回滾事務）。

    3.  真正的數據庫層的事務提交和回滾是通過 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 動態代理。

具體有如下四步驟：

鴻蒙官方戰略合作共建——HarmonyOS 技術社區

  通過實現 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 文件加載進來，通過修改其字節碼生成子類來處理。

鴻蒙官方戰略合作共建——HarmonyOS 技術社區

  如果目標對象實現了接口，默認情況下會采用 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 查詢之前，數據被其他用戶改變，則該次整體的統計查詢將會出現讀數據不一致的狀態，此時，應該啟用事務支持。 

上述就是丸趣 TV 小編為大家分享的 Spring 事務的原理分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。