一、 核心思想：代理模式 + AOP

想象一下，你是一位非常重要的業(yè)務專家（你的 Service 層代碼），你的工作是處理核心業(yè)務邏輯（比如轉賬、更新用戶信息）。但每次處理業(yè)務前，你都需要做一些準備工作（開啟事務），結束后還要做一些收尾工作（提交或回滾事務）。這些準備和收尾工作繁瑣、重復，而且和你的核心業(yè)務關系不大。

聲明式事務管理的目標就是：讓你這位專家只專注于核心業(yè)務，把所有繁瑣的事務管理工作交給一個“管家”來處理。

這個“管家”就是 Spring AOP 創(chuàng)建的代理對象 (Proxy)。

AOP (Aspect-Oriented Programming, 面向切面編程) 在這里扮演的角色就是：

• 定義“切面” (Aspect)：將事務管理（開啟、提交、回滾）這個“橫切關注點”從業(yè)務代碼中抽離出來，形成一個獨立的模塊。
• 定義“切點” (Pointcut)：精確地定義這個“管家”應該在哪些方法執(zhí)行前后介入。在 Spring 中，這通常是通過 @Transactional 注解來指定的。
• 創(chuàng)建“代理” (Proxy)：Spring 不會直接返回你的原始業(yè)務對象，而是會創(chuàng)建一個該對象的代理。所有對業(yè)務對象的調用都會先經(jīng)過這個代理。

二、 詳細工作流程（一步步拆解）

讓我們跟蹤一個對 @Transactional 方法的調用，看看 Spring 內(nèi)部到底發(fā)生了什么。

場景：一個 UserController 調用一個 UserService 的 updateUser() 方法，該方法被 @Transactional 注解。

// 業(yè)務接口
public interface UserService {
    void updateUser(User user);
}

// 業(yè)務實現(xiàn)類
@Service
public class UserServiceImpl implements UserService {

    @Autowired
    private UserRepository userRepository;

    @Override
    @Transactional // <--- 關鍵注解
    public void updateUser(User user) {
        // 核心業(yè)務邏輯
        userRepository.update(user);
        // 假設這里如果出錯了，需要回滾
        if (user.getName() == null) {
            throw new IllegalArgumentException("Username cannot be null");
        }
    }
}

// 調用方
@RestController
public class UserController {
    @Autowired
    private UserService userService; // <--- 注意：這里注入的其實是代理對象

    @PostMapping("/user/update")
    public void updateUser(@RequestBody User user) {
        userService.updateUser(user);
    }
}

階段一：應用啟動時 - 創(chuàng)建代理

1.Bean 掃描：Spring 容器在啟動時，會掃描所有的 Bean。

2.識別 @Transactional：當 Spring 掃描到 UserServiceImpl 時，它會發(fā)現(xiàn)這個類或其方法上存在 @Transactional 注解。

3.創(chuàng)建代理對象：Spring 認識到這個 Bean 需要被事務“增強”(Advised)。它不會直接創(chuàng)建 UserServiceImpl 的實例并放入容器，而是會通過 AOP 框架為它創(chuàng)建一個代理對象。

• 如果 UserServiceImpl 實現(xiàn)了接口（如本例中的 UserService），Spring 默認會使用 JDK 動態(tài)代理來創(chuàng)建一個實現(xiàn)了 UserService 接口的代理類。
• 如果 UserServiceImpl 沒有實現(xiàn)任何接口，Spring 會使用 CGLIB 來創(chuàng)建一個 UserServiceImpl 的子類作為代理。

4.注入代理：當 UserController 通過 @Autowired 請求注入 UserService 時，Spring 容器會將上一步創(chuàng)建的那個代理對象注入給它，而不是原始的 UserServiceImpl 對象。UserController 對此毫不知情，它以為自己拿到的就是普通的 UserService。

階段二：方法調用時 - 事務攔截

1.調用入口：UserController 調用 userService.updateUser(user)。

2.命中代理：這個調用首先命中的是代理對象的 updateUser 方法，而不是原始對象的。

3.事務攔截器 (TransactionInterceptor) 生效：代理對象的這個方法中包含了 AOP 的“通知”(Advice)。對于事務來說，這個通知的具體實現(xiàn)就是 TransactionInterceptor。這個攔截器就像一個警衛(wèi)，攔住了這次調用。

4.開啟事務：

• TransactionInterceptor 首先會解析 updateUser 方法上 @Transactional 注解的屬性（如傳播行為 propagation、隔離級別 isolation、是否只讀 readOnly 等）。
• 它向事務管理器 (PlatformTransactionManager) 請求一個事務。
• 事務管理器（例如 DataSourceTransactionManager）會從數(shù)據(jù)庫連接池中獲取一個連接 (Connection)，然后執(zhí)行 connection.setAutoCommit(false)，這標志著事務的正式開始。

5.調用原始方法：事務成功開啟后，TransactionInterceptor 會通過反射調用原始 UserServiceImpl 對象的 updateUser 方法。

6.執(zhí)行業(yè)務邏輯：此時，才真正開始執(zhí)行你編寫的核心業(yè)務代碼，比如 userRepository.update(user)。所有這些數(shù)據(jù)庫操作都將在上一步獲取的那個被 Spring 管理的 Connection 上執(zhí)行。

階段三：方法執(zhí)行后 - 提交或回滾

當原始的 updateUser 方法執(zhí)行完畢后，控制權返回到 TransactionInterceptor。

1.正常執(zhí)行完畢 (沒有拋出異常)：

• 攔截器捕獲到方法正常返回。
• 它會通知事務管理器提交 (commit) 事務。
• 事務管理器調用 connection.commit()，將本次事務中的所有數(shù)據(jù)庫操作永久保存。

2.拋出異常：

• updateUser 方法內(nèi)部拋出了一個異常（默認是 RuntimeException 或 Error）。
• 攔截器在其 try-catch 塊中捕獲到這個異常。
• 它會通知事務管理器回滾 (rollback) 事務。
• 事務管理器調用 connection.rollback()，撤銷本次事務中的所有數(shù)據(jù)庫操作。
• 最后，攔截器會將捕獲到的異常繼續(xù)向上拋出，以便上層調用者（如 UserController 或全局異常處理器）能夠感知到。

階段四：收尾

無論事務是提交還是回滾，事務管理器最終都會將數(shù)據(jù)庫連接釋放回連接池。

三、 核心組件總結

@Transactional：元數(shù)據(jù)，告訴 AOP 在哪里以及如何應用事務。它本身不包含任何邏輯。

AOP 代理 (Proxy)：由 Spring 動態(tài)創(chuàng)建的“管家”對象，是事務邏輯的實際入口。它包裝了原始的業(yè)務對象。

事務攔截器 (TransactionInterceptor)：AOP 通知(Advice)的具體實現(xiàn)，是代理對象中的核心邏輯。它負責在目標方法調用前后開啟、提交或回滾事務。

事務管理器 (PlatformTransactionManager)：一個統(tǒng)一的事務管理接口。Spring 通過它來適配不同的數(shù)據(jù)源技術（如 JDBC, JPA/Hibernate, JTA）。它負責執(zhí)行真正的事務操作（begin, commit, rollback）。

四、 為什么 @Transactional 在某些情況下會失效？

理解了以上原理，就很容易明白為什么 @Transactional 會在以下情況失效：

1.方法不是 public 的：CGLIB 代理是通過繼承來實現(xiàn)的，而 private 或 protected 方法無法被子類重寫(override)，所以 AOP 無法攔截。JDK 動態(tài)代理基于接口，更不存在非 public 方法。

2.同一個類中的方法調用（this 調用）：

@Service
public class UserServiceImpl implements UserService {
    public void entryMethod() {
        this.updateUser(user); // <--- 失效！
    }

    @Transactional
    public void updateUser(User user) {
        // ...
    }
}

當外部調用 entryMethod() 時，進入的是 UserServiceImpl 的原始對象（如果 entryMethod 沒有被代理）。然后 this.updateUser() 是一個對象內(nèi)部的直接調用，它繞過了代理對象，直接調用了原始對象的 updateUser 方法，因此事務攔截器根本沒有機會介入。

3.異常被 catch 掉了：

@Transactional
public void updateUser(User user) {
    try {
        // ... 拋出 RuntimeException 的代碼
    } catch (Exception e) {
        // 異常被吞了，沒有繼續(xù)拋出
    }
}

事務攔截器是通過捕獲異常來決定是否回滾的。如果異常被你的 try-catch 塊“消化”了，攔截器就認為方法是正常執(zhí)行完畢的，于是它會提交事務，而不是回滾。
通過這個機制，Spring 完美地將業(yè)務邏輯和非功能性的事務管理代碼解耦，讓開發(fā)者能更專注于業(yè)務價值的實現(xiàn)，代碼也變得更加清晰和易于維護。

到此這篇關于Spring如何使用AOP實現(xiàn)聲明式事務管理的文章就介紹到這了,更多相關Spring AOP聲明式事務管理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論