AOP 与代理：最重要的一种"加工实例"

4.1代理是谁创建的

Spring AOP 代理由 AbstractAutoProxyCreator 这个 BeanPostProcessor 在 Bean 初始化完成后创建，并用代理对象替换容器里的原始 Bean。

AbstractAutoProxyCreator 实现了 SmartInstantiationAwareBeanPostProcessor（BPP 的子接口），在 第 1 章 描述的 BPP 轨道中属于 postProcessAfterInitialization 阶段——即 Bean 完成属性注入、Aware 回调、@PostConstruct 初始化之后。调用链为：

// postProcessAfterInitialization 是 BPP 的钩子
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
    return wrapIfNecessary(bean, beanName, ...);  // 判断是否需要代理
}

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
    // 找到适用于此 bean 的所有 Advisor（Pointcut + Advice）
    Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(...);
    if (specificInterceptors != DO_NOT_PROXY) {
        return createProxy(...);  // 包成代理，返回给容器
    }
    return bean;  // 无需代理，原样返回
}

容器随后把这个代理对象存入单例池，后续所有依赖注入拿到的都是代理，而非原始 Bean。这是"@Transactional 的魔法"——本质上是第 1 章 BPP 加工实例的一个具体实例，没有任何额外机制。

4.2JDK 动态代理 vs CGLIB

DefaultAopProxyFactory.createAopProxy() 的决策逻辑如下：

• 若 proxyTargetClass=true，或目标类没有用户接口（实现的接口只有 Spring 内部接口不算）→ 选 CGLIB（运行时用 ObjenesisCglibAopProxy 生成子类）。
• 否则 → 选 JDK 动态代理（JdkDynamicAopProxy，实现目标类的接口）。

Spring Boot 的 AopAutoConfiguration 把 spring.aop.proxy-target-class 默认设为 true，因此 Boot 默认选 CGLIB——这与裸 Spring（偏好 JDK 动态代理）不同。这就是"为什么我的 Bean 实例是个 CGLIB 子类"的答案。

# Boot 默认 true（CGLIB）；设 false 则在有接口时回退 JDK 动态代理
spring.aop.proxy-target-class=false

4.3@Transactional / @Async / @Cacheable 都是代理

三个注解背后是同一套机制——对应 BPP 分别由不同的 AbstractAutoProxyCreator 子类或 Advisor 注册，代理拦截到方法调用后织入各自的 Advice：

• @Transactional：TransactionInterceptor 在方法进入前 begin 事务，正常返回后 commit，抛出指定异常后 rollback。依赖 @EnableTransactionManagement（Boot 的 TransactionAutoConfiguration 自动开启）。
• @Async：AsyncExecutionInterceptor 把方法体提交到指定线程池并立即返回（返回 Future / CompletableFuture）。依赖 @EnableAsync。
• @Cacheable：CacheInterceptor 在方法调用前查缓存，命中则直接返回；未命中则执行方法并写入缓存。依赖 @EnableCaching。

@Service
public class OrderService {

    private final OrderRepository repo;

    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }

    // 容器注入给调用方的是 CGLIB 代理；
    // 代理在进方法前 begin 事务，正常退出 commit，RuntimeException rollback
    @Transactional
    public void placeOrder(Order order) {
        repo.save(order);
        // 若此处抛出 RuntimeException，代理层触发 rollback
        chargePayment(order);
    }

    // @Cacheable 也走代理——同样要避免 self-invocation（见 4.4 节）
    @Cacheable("orders")
    public Order findById(Long id) {
        return repo.findById(id).orElseThrow();
    }
}

三者可以叠加在同一方法上：代理链的执行顺序由各 Advisor 的 order 决定，事务通常在最外层（先 begin，最后 commit/rollback），缓存在其内侧。

4.4self-invocation 根因与失效场景

this.method() 直接落在原始 Bean 上，代理不在调用栈里，Advice 永远无法触发。

容器把代理注入给调用方，但 Bean 内部的 this 引用始终指向原始对象——代理套在外层，内部的 this 调用绕过了它。这不是 Bug，是代理模式的固有特性：代理只拦截从外部（经由注入引用）发起的调用。

失效场景汇总