主题 10Spring AOP 与事务

10.1为什么 AOP 和事务必须一起讲

面试里这两道题从来不是分开的。问 AOP 是为了问代理，问代理是为了问事务—— @Transactional 就是一个方法拦截器，除此之外什么都不是。

10.2AOP 三块积木，和代理的两个真身

AOP 的名词听着玄，落到代码只有三样东西：在哪切（切点）、切了做什么（通知）、谁来执行（代理）。 前两个是配置，第三个才是原理。Spring 只有两种代理，实测各是什么类：

=== case1 代理的三种形态与开销 ===
JDK 代理类   : $Proxy22
    是接口实现: true，是原类: false
CGLIB 代理类 : TxDemo$GreetImpl$$SpringCGLIB$$0
    是原类子类: true
    [拦截器执行] hi
    调 final 方法返回: final 方法本体（上一行没有拦截日志 = final 没被拦）
直接调用   x5000000: 40.5 ms（8.1 ns/次）
代理调用   x5000000: 246.0 ms（49.2 ns/次）
代理额外开销: 41.1 ns/次，约 6.1 倍

final 方法为什么拦不到？CGLIB 靠生成子类并重写方法，final 方法不能被重写， 于是调用时执行的是父类原方法，拦截器根本没机会进场。实测时 Spring 甚至直接打了一条警告：

警告: Public final method [public final java.lang.String TxDemo$GreetImpl.fixed()]
cannot get proxied via CGLIB, consider removing the final marker or using
interface-based JDK proxies.

10.3自调用：事务为什么没生效

这是「@Transactional 失效」的第一名。看实测，同一个类里两个入口：

public void createDirect() {
    insert();                     // ← 自调用：this.insert()，走的是裸对象
}

public void createViaProxy() {
    ctx.getBean(OrderService.class).insertViaProxy();   // ← 从容器拿代理再调
}

@Transactional
public void insert() { ... }      // 加注解也没用，因为压根没经过代理

=== case2 自调用让 @Transactional 失效 ===
注入了 OrderService，它的真实类型: $Proxy19
    外层方法（无事务）开始，内部 this.insert()
        this.insert() 执行，事务是否活跃: false
    抛出: RuntimeException
    [自调用（this.insert）之后] 行数=1 余额合计=100      ← 数据留下了
    [清空表，准备对照] 行数=0 余额合计=0
    外层方法（无事务）开始，内部 getBean().insert()
        代理.insert() 执行，事务是否活跃: true
    抛出: RuntimeException
    [经代理调用之后] 行数=0 余额合计=0                    ← 真回滚了

两行 事务是否活跃 就是全部答案：false 的那次，SQL 自动提交了，根本没开事务。 注意第一行日志——注入进来的对象是 $Proxy19，但代理内部执行方法时用的是 target， target 里的 this 指向自己，不再经过代理，事务拦截器自然没被调用。

10.4什么异常才回滚

「抛异常就回滚」是错的。默认规则只有一条：只有 RuntimeException 和 Error 回滚。 受检异常（Exception 的直接子类且非运行时）不回滚。五种写法一次测完：

=== case3 什么异常才会回滚 ===
    抛出: IllegalStateException
    [RuntimeException 未捕获] 行数=0 余额合计=0
    抛出: Exception
    [Exception 未捕获（默认不回滚）] 行数=1 余额合计=100
    抛出: Exception
    [Exception + rollbackFor] 行数=0 余额合计=0
    方法内部 catch 住了异常，没有往外抛
    [catch 吞掉异常] 行数=1 余额合计=100
    抛出: RuntimeException
    [catch 后重新抛出] 行数=0 余额合计=0

10.5注解挂在哪些方法上不管用

这一组实验有意外。ModifierService 没有实现接口，所以 Spring 用 CGLIB 生成子类， 四种可见性的方法各挂一个 @Transactional，都在事务里插一行然后抛运行时异常：

=== case4 哪些方法上的 @Transactional 不管用 ===
注入对象类型: TxDemo$ModifierService$$SpringCGLIB$$0
        public 执行中，事务活跃=true，this.jdbc=有值
    抛出: RuntimeException
    [public 方法] 行数=0 余额合计=0
        final 执行中，事务活跃=false，this.jdbc=null（代理对象上没注入）
    抛出: RuntimeException
    [public final 方法] 行数=1 余额合计=1
        protected 执行中，事务活跃=true，this.jdbc=有值
    抛出: RuntimeException
    [protected 方法] 行数=0 余额合计=0
        private 执行中，事务活跃=false，this.jdbc=null（代理对象上没注入）
    抛出: RuntimeException
    [private 方法] 行数=1 余额合计=1

10.6传播行为：内层失败，外层还能提交吗

这是本章最重要的一组数据。场景统一为：外层 REQUIRED 先插一行， 调用内层（内层也插一行然后抛异常），外层 catch 住异常并继续提交。 只改内层的传播行为：

=== case5 传播行为：外层捕获内层异常会怎样 ===
    外层 catch 住: 内层 REQUIRED 失败
    外层继续执行，准备提交
    提交时抛出: org.springframework.transaction.UnexpectedRollbackException
        消息: Transaction rolled back because it has been marked as rollback-only
    [外层 REQUIRED + 内层 REQUIRED（内层失败后被 catch）] 行数=0 余额合计=0
    外层 catch 住: 内层 REQUIRES_NEW 失败
    外层继续执行，准备提交
    提交成功
    [外层 REQUIRED + 内层 NEW（内层失败后被 catch）] 行数=1 余额合计=100
    外层 catch 住: 内层 NESTED 失败
    外层继续执行，准备提交
    提交成功
    [外层 REQUIRED + 内层 NESTED（内层失败后被 catch）] 行数=1 余额合计=100
        内层 NOT_SUPPORTED，事务是否活跃: false
    外层继续执行，准备提交
    提交成功
    [外层 REQUIRED + 内层 NOTSUPPORTED（内层失败后被 catch）] 行数=2 余额合计=110

10.7timeout：管 SQL，不管你的 sleep

@Transactional(timeout = 1) 看起来很安全，实测两次，差别巨大：

=== case6 timeout 到底管不管用 ===
    已插入，开始 sleep 3000ms（timeout=1 秒）
    sleep 结束，事务是否还在: true
    方法正常返回
    总耗时 3007 ms
    [timeout=1 + sleep 3s（没有 SQL）] 行数=1 余额合计=1
    已插入，开始执行 select sleep(3)（timeout=1 秒）
    抛出: org.springframework.dao.QueryTimeoutException
        消息: StatementCallback; SQL [select sleep(3)];
             Statement cancelled due to timeout or client request
    总耗时 1026 ms
    [timeout=1 + select sleep(3)] 行数=0 余额合计=0

10.8readOnly 到底拦不拦写

很多人以为 readOnly = true 只是给 ORM 的「优化提示」，写操作照样能改。实测：

=== case7 readOnly 拦得住写操作吗 ===
    [初始] 行数=1 余额合计=5
    抛出: TransientDataAccessResourceException: StatementCallback;
         SQL [update account set balance = balance + 1 where name = 'ro'];
         Connection is read-only. Queries leading to data modification are not allowed.
    [readOnly 里 update 之后] 行数=1 余额合计=5
    [readOnly 里 select 之后] 行数=1 余额合计=5

10.9一次事务到底多贵

把「有没有事务」这件事从其他变量里剥出来：同一个 select 1，一个走代理事务，一个不走， 各跑 300 次（先预热 20 次），连接池固定 2 个空闲连接：

=== case8 一次事务的真实开销 ===
无事务 select 1  x300: 70.9 ms（0.24 ms/次）
有事务 select 1  x300: 172.1 ms（0.57 ms/次）
事务额外成本: 0.34 ms/次

10.10速记卡、自测与动手清单

五张速记卡

六个自测（能脱口而出才算过）

1. this.insert() 为什么让 @Transactional 失效？代理对象在哪一步被绕过？
2. 同样是「内层抛异常、外层 catch」，为什么 REQUIRED 会在提交时才报错？报什么？
3. rollbackFor = Exception.class 加与不加，实测行数差多少？为什么默认不包含受检异常？
4. @Transactional(timeout = 1) 的方法里 sleep(3)，事务会不会超时？为什么？
5. final 方法上的注解为什么无效？实测日志里 this.jdbc=null 说明了什么？
6. 一万条数据在 for 循环里各调一次事务方法，光事务开销大概几秒？怎么改？

动手清单与自查表