Spring AOP 與 @Transactional 為什麼靜默失效

這一張卡是整章的地基。Spring AOP 的所有陷阱都是它的推論。

代理不是「改寫你的類別」

很多人以為 @Transactional 是把交易邏輯「織入」你的方法裡。Spring AOP 不是這樣做的（那是 AspectJ 的編譯期織入）。Spring 做的是：

你的類別                     Spring 生成的代理
┌──────────────┐          ┌────────────────────────┐
│ OrderService │          │ OrderService$$Proxy    │
│              │  ←────── │   ┌──────────────────┐ │
│ save()       │  持有    │   │ save() {         │ │
│              │          │   │   開啟交易        │ │
└──────────────┘          │   │   target.save()  │ │
                          │   │   提交／回滾      │ │
                          │   └──────────────────┘ │
                          └────────────────────────┘

容器裡放的是「代理」，你的原始物件被代理「包在裡面」

推論一：只有「從外面進來」的呼叫才會經過代理

推論二：代理只能攔截「可以被覆寫」的方法

代理的本質是「產生一個新類別，覆寫方法後在前後加東西」。所以：

• private 方法 → 不能被覆寫，代理不到
• final 方法／類別 → 不能被覆寫，代理不到
• static 方法 → 不屬於實例，代理不到

而且這些情況都不會報錯，註解就是靜靜地沒有作用。

推論三：代理物件的類型不是你的類別

@Autowired OrderService orderService;

orderService.getClass()
// → class com.example.OrderService$$SpringCGLIB$$0
// 不是 class com.example.OrderService

所以 getClass() == OrderService.class 是 false，用 getClass().getAnnotation(...) 也可能拿不到你以為會有的註解。需要拿到原始物件時用 AopProxyUtils.ultimateTargetObject()。

@Service
public class OrderService {

    public void createOrder(Order order) {
        validate(order);
        this.saveWithTransaction(order);   // ← 內部呼叫
    }

    @Transactional
    public void saveWithTransaction(Order order) {
        orderRepo.save(order);
        throw new RuntimeException("boom");   // 不會回滾！
    }
}

為什麼

外部呼叫 createOrder()
  → 經過代理 → 代理發現 createOrder 沒有 @Transactional → 直接轉給原始物件
    → 原始物件執行 this.saveWithTransaction()
      → this ＝ 原始物件，不是代理
      → 完全沒有經過那層交易邏輯 ★

三種修法，各有代價

① 拆成兩個 Service（最推薦）

@Service
public class OrderService {
    private final OrderTxService txService;   // 注入的是「代理」

    public void createOrder(Order order) {
        validate(order);
        txService.saveWithTransaction(order);   // ✅ 跨 Bean → 經過代理
    }
}

優點：交易邊界變成明確可見的類別邊界。而且通常會發現這個拆分本來就該做——交易方法和非交易的協調邏輯本來就是兩件事。

② 自我注入

@Service
public class OrderService {
    @Autowired @Lazy
    private OrderService self;   // 注入自己的代理

    public void createOrder(Order order) {
        self.saveWithTransaction(order);   // ✅ 經過代理
    }
}

@Lazy 是必要的——否則會變成 ch06 講的循環依賴（自己依賴自己）。缺點：能跑，但讀程式碼的人會困惑「為什麼要注入自己」，而且它掩蓋了設計問題。

③ AopContext（不推薦）

// 需要 @EnableAspectJAutoProxy(exposeProxy = true)
((OrderService) AopContext.currentProxy()).saveWithTransaction(order);

要額外開設定、程式碼醜、而且把 Spring 的實作細節寫進業務邏輯裡。

同樣的陷阱也會發生在

@Cacheable、@Async、@Retryable——所有基於代理的註解都一樣。@Async 的自我呼叫特別隱蔽：方法會變成同步執行，但你完全不會發現。

JDK 動態代理：基於介面

利用反射，動態生成一個「實作了目標介面」的類別。

interface OrderService { void save(); }
class OrderServiceImpl implements OrderService { ... }

代理長這樣：
class $Proxy123 implements OrderService {
    void save() { 前置邏輯; target.save(); 後置邏輯; }
}

• 限制：目標類別必須實作介面
• 只能攔截介面上宣告的方法——類別上多出來的 public 方法攔截不到
• 代理物件不能轉型成實作類別（(OrderServiceImpl) proxy 會 ClassCastException）

CGLIB：基於繼承

利用 ASM 產生「目標類別的子類別」，覆寫方法。

class OrderService$$SpringCGLIB$$0 extends OrderService {
    @Override
    void save() { 前置邏輯; super.save(); 後置邏輯; }
}

• 不需要介面
• 限制：無法代理 final 類別或 final 方法（不能繼承／覆寫）
• private 方法也代理不到（子類別看不到）

Spring Boot 的選擇

由此推導出的實務規則

• 不要把 @Transactional 加在 private 方法上——不會報錯，就是不生效
• 不要把有 @Transactional 的方法或類別宣告成 final——同樣靜默失效（Kotlin 尤其要注意，Kotlin 的類別和方法預設就是 final，所以需要 kotlin-spring 外掛自動加 open）
• CGLIB 需要一個可用的建構子——早期版本需要無參建構子，現代 Spring 已用 Objenesis 繞過這個限制

怎麼確認實際用了哪一種

System.out.println(orderService.getClass().getName());

// JDK 代理  → com.sun.proxy.$Proxy123
// CGLIB     → com.example.OrderService$$SpringCGLIB$$0
// 沒有代理  → com.example.OrderService  ← 註解沒生效的訊號！

傳播行為回答的是：「呼叫這個方法的時候，如果外面已經有一個交易了，該怎麼辦？」

常用的三種

• REQUIRED（預設）——有就加入，沒有就新建。加入的意思是「用同一個交易」：外層回滾，內層做的事也一起回滾。
• REQUIRES_NEW——永遠開一個全新的、獨立的交易。把外層的交易掛起（suspend），自己跑完提交，再恢復外層。兩者的成敗互不影響。
• NESTED——在目前交易裡建立一個 savepoint。內層失敗只回滾到 savepoint，外層可以繼續；但外層回滾時，內層一定也跟著回滾。

REQUIRES_NEW 與 NESTED 的關鍵差別

                    內層失敗        外層失敗
REQUIRES_NEW    外層不受影響     內層「已提交」不受影響 ★
NESTED          外層可繼續       內層一起回滾 ★

★ 這是選擇的關鍵：內層的結果，該不該跟著外層一起消失？

REQUIRES_NEW 的隱藏代價：它要第二條連線

另外三種

• SUPPORTS——有交易就加入，沒有就以非交易方式執行
• NOT_SUPPORTED——掛起現有交易，以非交易方式執行（適合長時間的唯讀查詢，避免拉長交易）
• MANDATORY / NEVER——強制要求「必須有」／「必須沒有」交易，否則丟例外。適合用來保護那些「絕對不能單獨呼叫」的方法。

交易明明生效了（有經過代理），例外也拋出來了，但資料就是沒回滾。

原因一：checked exception 預設不回滾

@Transactional
public void process() throws IOException {
    orderRepo.save(order);
    throw new IOException("檔案讀取失敗");   // ❌ 不會回滾！
}

// 修法一：明確指定
@Transactional(rollbackFor = Exception.class)

// 修法二（更好）：業務例外一律繼承 RuntimeException
public class BusinessException extends RuntimeException { ... }

原因二：例外被 catch 住了

@Transactional
public void process() {
    try {
        orderRepo.save(order);
        riskyOperation();
    } catch (Exception e) {
        log.error("失敗了", e);   // ❌ 吞掉了，代理看不到例外 → 正常提交
    }
}

代理是靠「有沒有例外往外拋」來決定回滾的。你在方法內部把例外吃掉，代理就以為一切正常。

// 修法：處理完要重新拋出
catch (Exception e) {
    log.error("失敗了", e);
    throw new BusinessException("處理失敗", e);
}

// 或：明確標記回滾（不想拋例外時）
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

原因三：內層標記了 rollback-only，外層卻想提交

外層 @Transactional  →  呼叫內層 @Transactional（REQUIRED，同一個交易）
                          內層拋例外 → 標記整個交易為 rollback-only
                    ←  外層 catch 住例外，想正常結束
                    →  提交時發現交易被標記了
                    →  UnexpectedRollbackException:
                       Transaction rolled back because it has been
                       marked as rollback-only

把視角從 @Transactional 拉回 AOP 本身——它其實只是 Spring 內建的一個切面。

核心術語（用一句話對應）

• 切面 Aspect——「要織入的橫切邏輯」，例如交易、日誌、權限
• 連接點 Join Point——「可以被攔截的地方」，Spring AOP 裡只有方法呼叫
• 切入點 Pointcut——「要攔截哪些連接點」的表達式
• 通知 Advice——「攔截到之後做什麼」

五種通知與執行順序

@Around      前半部
  @Before
    ┌─────────────────┐
    │   目標方法執行   │
    └─────────────────┘
  @AfterReturning（正常回傳時）／ @AfterThrowing（拋例外時）
  @After（finally，兩種情況都會執行）
@Around      後半部

@Around 最強大也最危險——它必須自己呼叫 joinPoint.proceed()，忘了寫的話目標方法根本不會執行，而且完全不報錯。

多個切面的順序：@Order

@Aspect @Order(1)  class LoggingAspect { }     // 最外層
@Aspect @Order(2)  class SecurityAspect { }
// @Transactional 的優先序預設是 Ordered.LOWEST_PRECEDENCE（最內層）

切入點表達式常用寫法

// 攔截某個套件下所有 public 方法
@Pointcut("execution(public * com.example.service..*.*(..))")

// 攔截標了特定註解的方法（最常用，也最不容易誤傷）
@Pointcut("@annotation(com.example.RequirePermission)")

// 攔截某個註解標記的類別裡的所有方法
@Pointcut("@within(org.springframework.stereotype.Service)")

這張卡把三章串起來。「交易」在應用程式看是一個註解，在資料庫看是一段時間，在連線池看是一條被佔住的連線。

一個 @Transactional 方法實際佔用了什麼

進入 @Transactional 方法
  → 跟連線池借一條連線（ch03）      ★ 連線開始被佔用
  → 送出 BEGIN
  → 建立 Read View（ch02，RR 下第一次查詢時）★ 舊版本開始無法被清理
  → 執行你的業務邏輯 ……
  → COMMIT / ROLLBACK
  → 歸還連線                         ★ 連線釋放

正確的交易邊界

// ❌ 交易包住所有東西
@Transactional
public void createOrder(OrderRequest req) {
    Order order = orderRepo.save(toEntity(req));
    paymentClient.charge(order);        // 外部 API
    mailService.send(order);            // 寄信
    fileService.generatePdf(order);     // 檔案 I/O
}

// ✅ 交易只包住 DB 操作
public void createOrder(OrderRequest req) {
    Order order = txService.saveOrder(req);   // @Transactional 只在這裡
    paymentClient.charge(order);
    // 要在交易成功後才做的事，用事件
}

@TransactionalEventListener(phase = AFTER_COMMIT)
public void onOrderCreated(OrderCreatedEvent e) {
    mailService.send(e.getOrder());
}

@Transactional(readOnly = true) 值得養成習慣

• Hibernate 會關閉 dirty checking（不做快照比對，省記憶體也省 CPU）
• 某些設定下可以自動路由到唯讀副本
• 對資料庫明確表達意圖，某些驅動會做額外優化

AOP 解決的是「橫切關注點」——散落在很多地方、跟業務邏輯無關的重複程式碼。但它的代價是「隱形」：程式碼看不出來有東西在執行。

AOP 適合什麼

• 交易、快取、重試、限流
• 日誌與稽核紀錄
• 權限檢查
• 效能監控

共同特徵：邏輯統一、跟業務無關、散落在大量方法上。

不適合什麼

1. 核心業務邏輯——「訂單金額超過一萬要打九折」寫進切面，等於把業務規則藏進看不見的地方。三個月後沒有人找得到它。
2. 只有一兩個地方要用——直接寫在方法裡更清楚，用 AOP 是殺雞用牛刀。
3. 需要依賴呼叫端上下文的邏輯——切面拿不到完整的呼叫語境，硬要拿就會寫出一堆 if 判斷方法名稱，比不用還糟。

三個實用的自保習慣

• 切入點優先用註解（@annotation）而不是套件路徑——至少在方法上看得到標記，讀程式碼的人有線索
• 切面要記 log，至少在 debug 等級，出事時能確認它到底有沒有執行
• 啟動時驗證關鍵註解有生效——例如寫一個測試，斷言關鍵 Service 拿到的是代理物件（AopUtils.isAopProxy()）

回到整章的那句話