深入理解Spring 之源码剖析AOP（注解方式）

一时失言乱红尘 2022-06-04 08:56 316阅读 0赞

上一篇文章我们从XML 配置文件的方式剖析了AOP的源码，我们也说了，虽然现在用XML配置的几乎没有了，但作为学习的例子，XML配置仍然是我们理解Spring AOP 的一个绝好的样本，但作为一个由追求的程序员，我们天天使用的注解方式的AOP 肯定也是要去看看到底是如何实现的。现在有了之前阅读 XML 配置的源码的基础，今天我们来阅读注解方式的源码也变得轻松起来。

还记得我们之前说过，XML 配置的AOP是使用 ProxyFactoryBean ，实现了 FactoryBean的接口，而FactoryBean是Spring特意留给开发者们扩展的接口，而Spring 留给开发者们不止一个扩展接口，比如 BeanPostProcess 接口，实现着接口就可以在每个Bean的生成前后做一些增强或自定义（具体Spring 留给我们有哪些扩展接口，楼主有机会将会再写一篇文章解析）。

接下来就要好好讲讲我们上篇文章漏讲的接口设计。这是我们理解 AOP 的基础。

先从 ProxyFactoryBean 讲起，这个熟悉的哥们。

## 1. ProxyFactoryBean 类结构 ##

![1240][]

### 1.1 ProxyCreatorSupport 类结构图 ###

它继承了 ProxyCreatorSupport 这个类，这个类很重要，我们看看该类结构

![1240 1][]

该类有2个重要的方法，分别是获取代理工厂，创建代理。那么代理工厂是什么呢？AopProxyFactory ，是个接口，只定义了一个方法：AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException， 并且该接口目前只有一个默认实现类：DefaultAopProxyFactory，该类主要重写了接口方法 createAopProxy， 内部逻辑是根据给定的类配置来创建不同的代理 AopProxy，那么 AopProxy 是什么呢？就是真正创建代理的工厂，他是一个接口，有3个实现：

### 1.2 AopProxy 接口 ###

![1240 2][]

### 1.3 AopProxy 继承结构 ###

![1240 3][]

从名字上可以看出来，一个是 JDK 动态代理，一个是 Cglib 代理，ObjenesisCglibAopProxy 扩展了它的父类 CglibAopProxy，在 DefaultAopProxyFactory 的实现里，使用的就是 ObjenesisCglibAopProxy 来实现 Cglib 的代理。他们分别实现了自己的getProxy 方法用以创建代理。我们看看这两个类的继承结构：

### 1.4 JdkDynamicAopProxy 继承结构 ###

![1240 4][]

### 1.5 CglibAopProxy 继承结构没什么，主要是众多内部类 ###

![1240 5][]

可以看到哟非常多的内部类，这些内部类是为了实现了 Cglib 的各种回调而实现的。主要实现了 MethodInterceptor 接口，  
Callback 接口，Joinpoint 接口，Invocation 接口等待，总之是实现了Spring 的 cglib 模块的各种接口。

说了那么多，我们回来看看 ProxyCreatorSupport ，下面是 ProxyCreatorSupport 的继承结构

## 2. ProxyCreatorSupport 类继承图 ##

![1240 6][]

该类有3个子类， 其中就有一个我们熟悉的 ProxyFactoryBean，该类实现了我们熟悉的 FactoryBean，还有一个可以获取容器内Bean的 BeanFactoyAware 接口，第二个是陌生的 AspectJProxyFactory 类，该类是用于集成 Spring 和 AspectJ 的。而最后一个类ProxyFactory 就是我们今天的主角，Spring 的类注释说：`用于编程使用的AOP代理，而不是在bean工厂中通过声明式设置。这个类提供了一种简单的方法，可以在定制的用户代码中获取和配置AOP代理实例`，大概意思就是通过编程的方式获取Bean 代理吧，而不是通过配置文件的方式。我们今天就可以见识到。

## 3. AnnotationAwareAspectJAutoProxyCreator 类 ##

这个类的名字很长，为什么要说这个类呢？还记得我们刚开始说的 BeanPostProcessor 扩展接口吗？我们说该接口是spring 留给开发人员自定义增强bean的接口。而该类则实现了该接口，看名字也知道，该类是根据注解自动创建代理的创建者类。我们看看他的类图：

![1240 7][]

可以看到，最底层的该类实现了 BeanPostProcessor 接口，可以在每个bena生成前后做操作。该类由 Rod Johnson 编写，注释上是这么说的：`任何AspectJ注释的类都将自动被识别，它们也会被识别`。和我们预想的一致。

我们知道了 AnnotationAwareAspectJAutoProxyCreator 是根据注解自动创建代理，而该类也算是 ProxyBean 的代理，那么，和它一样继承抽象父类的其他几个类的作用是什么呢？来都来了，就看看吧！我们看看类图：

![1240 8][]

可以看到该类由4个实现：他们实现了不同的创建代理的方式：  
1. 匹配Bean的名称自动创建匹配到的Bean的代理，实现类BeanNameAutoProxyCreator  
2. 根据Bean中的AspectJ注解自动创建代理，实现类AnnotationAwareAspectJAutoProxyCreator，也就是我们今天说的注解类。  
3. 根据Advisor的匹配机制自动创建代理，会对容器中所有的Advisor进行扫描，自动将这些切面应用到匹配的Bean中，实现类DefaultAdvisorAutoProxyCreator  
4. InfrastructureAdvisorAutoProxyCreator，该类只在 AopConfigUtils 中的静态块用到，该类的注释：自动代理创建者只考虑基础设施顾问bean，忽略任何应用程序定义的顾问。意思应该是只是Sprnig的基础代理，开发者的应用会忽略。有知道的同学可以告诉我。

加上我们的ProxyFactoryBean，一共5种实现方法。从这里可以看出Spring 对于扩展的软件设计是多么优秀。

那么我们就来看看 AnnotationAwareAspectJAutoProxyCreator 是如何创建代理的。我们说 BeanPostProcessor 是Spring 留给我们扩展的接口，那么他是如何定义的呢？我们看看该接口：

public interface BeanPostProcessor { 
        Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
        Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
    }

该接口定义了两个方法，一个是在bean初始化之前执行，一个是在bean初始化之后执行。也就是说，开发者可以在这两个方法中做一些有趣的事情。我们看看 AnnotationAwareAspectJAutoProxyCreator 是如何实现该方法的。实际上 AnnotationAwareAspectJAutoProxyCreator 的抽象父类已经实现了该方法，我们看看是如何实现的：

@Override
        public Object postProcessBeforeInitialization(Object bean, String beanName) {
            return bean;
        }
    
        /** * Create a proxy with the configured interceptors if the bean is * identified as one to proxy by the subclass. * @see #getAdvicesAndAdvisorsForBean */
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
            if (bean != null) {
                Object cacheKey = getCacheKey(bean.getClass(), beanName);
                if (!this.earlyProxyReferences.contains(cacheKey)) {
                    return wrapIfNecessary(bean, beanName, cacheKey);
                }
            }
            return bean;
        }

before 方法直接返回了bean，并没有做什么增强操作，重点在after方法，我们可以看该方法的注释：如果bean是由子类标识的，那么就创建一个配置的拦截器的代理。Spring 就是在这里创建了代理，我们进入关键方法 wrapIfNecessary 看看。该方法用来包装给定的Bean。

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
            if (beanName != null && this.targetSourcedBeans.contains(beanName)) {
                return bean;
            }
            if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
                return bean;
            }
            if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
                this.advisedBeans.put(cacheKey, Boolean.FALSE);
                return bean;
            }
    
            // Create proxy if we have advice.
            Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
            if (specificInterceptors != DO_NOT_PROXY) {
                this.advisedBeans.put(cacheKey, Boolean.TRUE);
                Object proxy = createProxy(
                        bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
                this.proxyTypes.put(cacheKey, proxy.getClass());
                return proxy;
            }
    
            this.advisedBeans.put(cacheKey, Boolean.FALSE);
            return bean;
        }

我们已将可以看到一个关键一行代码：Object proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean))，创建一个代理，该方法携带了bean的Class对象，benaName， 通知器数组，还有一个包装过的单例Bean，我们看看该方法实现（该方法对于我们来说已经到终点了），

protected Object createProxy(
                Class<?> beanClass, String beanName, Object[] specificInterceptors, TargetSource targetSource) {
    
            if (this.beanFactory instanceof ConfigurableListableBeanFactory) {
                AutoProxyUtils.exposeTargetClass((ConfigurableListableBeanFactory) this.beanFactory, beanName, beanClass);
            }
    
            ProxyFactory proxyFactory = new ProxyFactory();
            proxyFactory.copyFrom(this);
    
            if (!proxyFactory.isProxyTargetClass()) {
                if (shouldProxyTargetClass(beanClass, beanName)) {
                    proxyFactory.setProxyTargetClass(true);
                }
                else {
                    evaluateProxyInterfaces(beanClass, proxyFactory);
                }
            }
    
            Advisor[] advisors = buildAdvisors(beanName, specificInterceptors);
            proxyFactory.addAdvisors(advisors);
            proxyFactory.setTargetSource(targetSource);
            customizeProxyFactory(proxyFactory);
    
            proxyFactory.setFrozen(this.freezeProxy);
            if (advisorsPreFiltered()) {
                proxyFactory.setPreFiltered(true);
            }
    
            return proxyFactory.getProxy(getProxyClassLoader());
        }

我们能够看到其中有一行让我们激动的代码，就是 ProxyFactory proxyFactory = new ProxyFactory()，创建了一个ProxyFactory 对象，我们刚刚说过，该对象和ProxyFactoryBean一样，继承了 ProxyCreatorSupport， 因此也就和 ProxyFactoryBean 一样拥有了 getProxy 方法，到这里，我们的一切都豁然开朗。当然上面几行代码是设置了通知器链。我们先按下不表。

> ProxyFactoryBean 扩展了 FactoryBean 接口， AnnotationAwareAspectJAutoProxyCreator 扩展了 BenaPostProcessor 了接口，其目的都是在Bean生成的时候做增强操作，Spring 通过这两种方式，完成了两种不同的代理生成方式，但最终都是继承了 ProxyCreatorSupport 类，该类才是生成代理的核心类。

我们可以看看XML 配置方式和 注解方式的方法堆栈调用图，从中我们可以看出一些端倪：

**XML 配置方式堆栈图**

![1240 9][]

**注解配置方法堆栈图**

![1240 10][]

我们可以看到两者在AbstractBeanFactory 的 doGetBean 方法开始分道扬镳，走向了不同的逻辑，那么我们看看到底哪里不同，直接看代码：我们看XML配置堆栈，在258行：

![1240 11][]

从这里进入，该方法做了些什么呢？为什么让他们走向不同的路线？我们看看该方法：

![1240 12][]

该方法有个重要的判断：是否是 FactoryBean 的子类型，很明显，我们的XML配置的ProxyFacoroyBean 返回 false，而注解方式的Bean则返回 false，ProxyFacoroyBean 会一直向下走，直到创建代理，而注解方式则会直接返回。走到302行：

![1240 13][]

注解方式会执行 getSingleton 方法，最后触发 createBean 回调方法，完成创建代理的过程。

到此为止，现在我们知道了到 XML 配置方式的 AOP 和注解的方式AOP 的生成区别。我们可以开始总结了。

## 4. 总结 ##

首先，通过分析源码我们知道注解方式和 XML 配置方式的底层实现都是一样的，都是通过继承 ProxyCreatorSupport 来实现的，不同的通过扩展不同的 Spring 提供的接口，XML 扩展的是FactoryBean 接口， 而注解方式扩展的是 BenaPostProcessor 接口，通过Spring 的扩展接口，能够对特定的Bean进行增强。而 AOP 正式通过这种方式实现的。这也提醒了我们，我们也可以通过扩展 Spring 的某些接口来增强我们需要的 Bean 的某些功能。当然，篇幅有限，我们这篇文章只是了解了XML 配置方式和注解方式创建代理的区别，关于如何 @Aspect 和 @Around 的底层实现，还有通知器的底层实现，我们还没有分析，但我们隐隐的感觉到，其实万变不离其宗，底层的也是通过扩展 advice 和 pointcut 接口来实现的。 我们将会在后面的文章继续分析 AOP 是如何编织通知的。

good luck ！！！！

[1240]: /images/20220604/afc8f73087424d8d8a2b75a8206549a5.png
[1240 1]: /images/20220604/8b15b1132ace4469b934c8734bb4d797.png
[1240 2]: /images/20220604/7645c0ff05cb4efaaa973f484a1be7c9.png
[1240 3]: /images/20220604/d9fcbbdc29914de5833ded14d54f8670.png
[1240 4]: /images/20220604/d359771654ed41d3910e425f7491c4a6.png
[1240 5]: /images/20220604/9d986b02d79147e394a19f65ebf45652.png
[1240 6]: /images/20220604/4e8c153b8b584fb3ad7f5632ca7f19d5.png
[1240 7]: /images/20220604/469d1b3ec26740ee8355afa9e259d28f.png
[1240 8]: /images/20220604/76bec9601df74240890f5eec4eca8987.png
[1240 9]: /images/20220604/0ce5c00e305647b5843b06c14147e3a0.png
[1240 10]: /images/20220604/0a5df4d816bf4f5fae070ed59b19e33d.png
[1240 11]: /images/20220604/555f8cba37b94839a2b1d7a0dbdb15bb.png
[1240 12]: /images/20220604/175db530e4cc481383e3e72b6414c624.png
[1240 13]: /images/20220604/0412b10830574371b38846e533a3a311.png