Spring AOP 与事务

1. 为什么需要 AOP#

没有 AOP 时，每个 Service 方法都要手写相同套路：

1
public void transfer(...) {
2
    log.info("enter transfer");
3
    TransactionStatus tx = txManager.begin();
4
    try {
5
        // 业务 SQL
6
        txManager.commit(tx);
7
    } catch (Exception e) {
8
        txManager.rollback(tx);
9
        throw e;
10
    }
11
}

横切关注点（Cross-cutting Concern）：与具体业务无关、却散布在很多方法上的逻辑。AOP 把这些逻辑抽到切面（Aspect），在匹配的切点（Pointcut）上统一织入通知（Advice）。

Spring AOP 基于运行时代理实现，不修改业务类源码；与 IoC 配合：容器注入的往往是代理对象，而不是原始 Target。

2. AOP 核心概念#

通知类型

1
@Aspect
2
@Component
3
public class LogAspect {
4
    @Pointcut("execution(* com.example.service..*(..))")
5
    public void serviceLayer() {}
6

7
    @Before("serviceLayer()")
8
    public void logBefore(JoinPoint jp) {
9
        log.info("调用: {}", jp.getSignature().getName());
10
    }
11
}

Spring AOP 是方法级别的，不能像 AspectJ 编译期织入那样拦截字段赋值等所有连接点；对 Web 开发而言通常够用。

3. Spring AOP 工作原理：代理（核心）#

1
外部 Bean 调用 service.transfer()
2
  → 实际进入 Proxy
3
  → 事务 Advice：开启事务
4
  → 调用 Target.transfer() 执行业务
5
  → 正常则 commit，异常则 rollback
6
  → 返回给调用方

为什么 @Autowired 注入的 Service 上事务能生效？
因为注入的是容器里的 Proxy Bean；代理在 Bean 初始化后、由 BeanPostProcessor 创建（见 IoC 篇 生命周期第 8 节）。

为什么同类自调用事务失效？
this.transfer() 是目标对象内部直接调用，不经过 Proxy，事务拦截器根本不会执行。

1
@Service
2
public class AccountService {
3
    @Transactional
4
    public void transfer(Long from, Long to, BigDecimal amount) { /* ... */ }
5

6
    public void pay() {
7
        this.transfer(); // ✗ 自调用，事务不生效
8
    }
9
}

修复思路：把 transfer 抽到另一个 @Service；或注入自身接口代理；或 AopContext.currentProxy()（需开启 @EnableAspectJAutoProxy(exposeProxy = true)）。

4. JDK 动态代理 vs CGLIB#

Spring Boot 2.x 起默认倾向 CGLIB（spring.aop.proxy-target-class=true），即使实现了接口也可能用子类代理。面试答「有接口优先 JDK，无接口 CGLIB」即可；实际以项目配置为准。

限制：final 类/方法无法 CGLIB；JDK 代理只能代理接口方法。

5. 声明式事务 @Transactional#

1
@Service
2
public class AccountService {
3
    @Transactional(rollbackFor = Exception.class)
4
    public void transfer(Long from, Long to, BigDecimal amount) {
5
        accountMapper.debit(from, amount);
6
        accountMapper.credit(to, amount);
7
    }
8
}

Spring 不直接在业务代码里写 begin/commit，而是由 TransactionInterceptor（一种 Advice）在代理方法前后管理事务，底层通过 PlatformTransactionManager（常见 DataSourceTransactionManager）绑定到 Connection。

常用属性

默认回滚规则：仅 RuntimeException 和 Error 回滚；受检异常（Exception 子类但非 Runtime）默认不回滚，需显式 rollbackFor = Exception.class。

6. 事务传播行为（常考）#

传播行为解决：一个事务方法调用另一个事务方法时，事务边界怎么合并或拆分。

记忆：先记三个就够 —— REQUIRED（默认合体）、REQUIRES_NEW（独立新开）、NESTED（嵌套保存点）。

1
外层 REQUIRED + 内层 REQUIRED  → 同一个物理事务
2
外层 REQUIRED + 内层 REQUIRES_NEW → 两个独立事务，互不影响提交/回滚
3
外层 REQUIRED + 内层 NESTED → 同一连接上的保存点，内层 rollback 可只回滚到保存点

7. 事务隔离级别#

与 JDBC / 数据库一致，通过 @Transactional(isolation = ...) 指定：

8. @Transactional 失效常见原因#

1. 在 private 方法上加 @Transactional#

Spring 默认用代理模式，private 方法无法被代理拦截，事务不生效。应标在对外 public 业务方法上。

2. 只捕获异常不抛出#

1
@Transactional
2
public void update() {
3
    try {
4
        mapper.step1();
5
        mapper.step2();
6
    } catch (Exception e) {
7
        log.error("failed", e); // 异常被吞，事务仍 commit
8
    }
9
}

需要回滚时必须重新抛出或配置 rollbackFor 且让异常传到代理层。

3. 只读方法误用写传播#

查询方法标 @Transactional(readOnly = true) 可避免脏检查、优化连接；写操作不要标 readOnly。

4. 多数据源未指定事务管理器#

存在多个 TransactionManager 时，需 @Transactional(transactionManager = "xxx") 指定。