【Spring源码】AOP的开端：核心对象创建的准备工作

AOP的核心成员是如何被被加载的？

本篇我们主要分析使用xml的逻辑，如果使用注解，增加注解处理类即可（ConfigurationClassPostProcessor）

拿之前分析循环的时候举的例子🌰，它的日志切面就是通过xml进行配置的（配置文件📃内容如下，完整测试代码可参考【实践向】当移除了三级缓存…… 中的示例代码）

通过ApplicationContext applicationContext = new ClassPathXmlApplicationContext("circulate.xml");启动容器

进入refresh()方法后，先调用prepareRefresh()方法进行的是容器刷新前的准备工作，这里的准备工作大致包括5个内容：

1. 设置容器的启动时间

2. 设置活跃状态为true

3. 设置关闭状态为false

4. 获取Environment对象，并加载当前系统的属性值到Environment对象中

5. 准备监听器和事件的集合对象（默认为空）

在准备工作完成后，开始了下面的创建容器的流程

创建容器

进入方法obtainFreshBeanFactory()，开始Spring容器的创建

可以看到此时创建的是上下文对象是ClassPathXmlApplicationContext

接着进入方法refreshBeanFactory()中，开始BeanFactory的初始化以及XML配置文件的读取和解析

读取并解析XML配置文件📃

进入loadBeanDefinitions()

终于看到了咱们的doLoadBeanDefinitions() ，正式开始读取+解析标签🏷️的逻辑

registerBeanDefinitions()

进入doRegisterBeanDefinition()（没错、do-开头的方法都是干实事的～）

开始重头戏(｡･ω･｡)ﾉ

进入parseBeanDefinitions()，方法中对于 Element 的处理主要分为两种类型：

• parseDefaultElement

• parseCustomElement

• 找到对应的handler

<aop:config>就属于自定义元素类型，所以我们进入parseCustomElement()方法中

进入parseCustomElement()

我们可以看到，此时的处理器handler为AopNamespaceHandler

按照案例代码，我们进入了NamespaceHandlerSupport接口中，重写了parse

进入其一个实现类NamepaceHandlerSupport中

由于parser != null为true，再次进入名为parse()的方法中

这里主要进行了两个步骤的处理：

1. 注册自动代理模式创建器

2. 解析<aop:config>下的子节点

1. POINTCUT

2. ADVICE

3. ASPECT

我们依次来看看

第一个步骤：【注册自动代理模式创建器】configureAutoProxyCreator()

进入方法configureAutoProxyCreator()

此时集合containingComponents中只有一个元素："aop:config"

进入registerAspectJAutoProxyCreatorIfNecessary()

registerOrEscalateApcAsRequired()

进入registerOrEscalateApcAsRequired()

如果已经存在了自动代理创建器，且存在的自动代理创建器与当前不一致，那么需要根据优先级来判断下到底需要使用哪个；如果已经存在了自动代理创建器，且存在的自动代理创建器与当前一致，则无需再次创建，返回null即可

下面的变量表中可以看到，这里注册的Bean名为org.springframework.aop.config.internalAutoProxyCreator的beanDefinition；并且其中的BeanDefinition的具体Class类为AspectJAwareAdvisorAutoProxyCreator

方法registerOrEscalateApcAsRequired()执行到最后的registerBeanDefinition()时，当前的BeanDefinition（也就是AspectJAwareAdvisorAutoProxyCreator的BeanDefinition）就已经注册成功了

由下图的静态代码块中也同样添加了InfrastructureAdvisorAutoProxyCreator和AnnotationAwareAspectJAutoProxyCreator这两个类，因此可以推断出他俩的注册流程与AspectJAwareAdvisorAutoProxyCreator类似

那么问题来了：AspectJAwareAdvisorAutoProxyCreator跟我们熟悉的那些BeanPostProcessor、Aware等等有什么关系么？

(*≧ω≦)我们看下类关系图（下图中右下角的就是AspectJAwareAdvisorAutoProxyCreator）

useClassProxyingIfNecessary()

方法中主要是对proxy-target-class和expose-proxy这两个属性进行处理

如果被代理的目标对象实现了至少一个接口，就会使用JDK动态代理，该目标类型实现的接口都会被代理；如果没有实现任何接口，则创建一个Cglib代理对象

registerComponentIfNecessary()

最后调用方法registerComponentIfNecessary()注册对应的组件

接着回到parse()方法中，可以看到此时<aop:config>还是null

第二个步骤：解析<aop:config>下的子节点

继续解析<aop:config>子节点下的

• <aop:pointcut>

• <aop:advice>

• <aop:aspect>

在这里会根据获取到的localName进入不同的if条件语句，进而执行不同的解析方法

• parsePointcut()

• parseAdvisor()

• parseAspect()

下面我们按照我们的测试代码中的XML配置（如下图）捋一遍流程(｡･ω･｡)ﾉ

由于获取到的localName为"aspect"，满足ASPECT.equals(localName)为true的条件，所以进入parseAspect()方法中

parseAspect()

先获取<aop:aspect>的两个属性：

• id属性

• ref属性（代表切面，必须配置）

接着解析<aop:aspect>下的declare-parents节点，通过DeclareParentsAdvisor作为beanClass加载，然后继续解析其他节点

在获取到节点后，遍历循环，解析其下的Advice类型的节点，通过调用isAdviceNode()判断遍历到的当前节点是否为Advice类型的节点

isAdviceNode()

判断是否为Advice节点

如上图中方法上面的注释，Advice类型的节点有5个：

• {@code before}

• {@code after}

• {@code after-returning}

• {@code after-throwing}

• {@code around}

与上面任何一个类型形同返回值即为true

解析成功则继续向下执行

parseAdvisor()

方法parseAdvisor()先生成了methodDefinition（解析advice中的"method"属性，并包装为MethodLocatingFactoryBean对象 ）、aspectFactoryDef（关联aspectName，包装为SimpleBeanFactoryAwareAspectInstanceFactory对象）这两个RootBeanDefinition对象，并依次为他俩赋值

随后解析pointcut属性，将上面👆两个对象传入了方法createAdviceDefinition()中，包装为AspectJMethodBeforeAdvice对象返回并赋值给名为adviceDef的AbstractBeanDefinition对象

最后将这个对象包装为名为advisorDefinition的RootBeanDefinition对象并为相关的属性赋值

最后完成注册，就可以在parseContext对象的readerContext -> reader -> registry -> beanDefinitionMap属性中看到这个AspectJPointcutAdvisor对象叻（AspectJPointcutAdvisor#0）

那么问题来了：这些生成的RootBeanDefinition对象有什么区别吗，他们具体都是哪些类呢？

我们先来详细介绍下createAdviceDefinition()这个方法

createAdviceDefinition()

进入方法createAdviceDefinition()

首先根据adviceElement节点通过调用getAdviceClass()方法分析出是什么类型的Advice，获取到一个adviceDefinition对象

getAdviceClass()

这个方法其实与刚刚介绍过的isAdviceNode()判断的类型是完全一致的

继续给刚刚获取到的adviceDefinition对象设置属性值

• 设置aspectName属性和declarationOrder属性

• 设置returning、throwing、arg-name这3个属性（先判断，有则设置）

• 设置构造函数的入参变量

• Method

• AspectJExpressionPointcut

• AspectInstanceFactory

然后解析<point-cut>节点

parsePointcutProperty()

至此，方法createAdviceDefinition()执行结束，返回一个AbstractBeanDefinition类型的对象adviceDef。我们也来回答下介绍方法前的问题：这些生成的RootBeanDefinition对象具体都是哪些类呢？

• methodDefinition：MethodLocatingFactoryBean

• aspectFactoryDef：SimpleBeanFactoryAwareAspectInstanceFactory

• adviceDef：AspectJMethodBeforeAdvice

• adviceDefinition：AspectJPointcutAdvisor

回到方法parseAspect()中，将当前解析过的beanDefinition（advisorDefinition）添加进集合beanDefinitions中

接着进入下一轮循环♻️，继续解析列表中的节点

第二次循环执行完成在parseContext对象的readerContext -> reader -> registry -> beanDefinitionMap属性中又多了一个AspectJPointcutAdvisor对象（AspectJPointcutAdvisor#1），嘿嘿没错每完成一次循环就会多一个～～0、1、2……递增

这些类外部都是AspectJPointcutAdvisor对象，用后缀#1、#2、#3……来区分，但是内部真正的通知类型Advisor是不一样的

循环结束后，返回到parse()方法中，由于我在XML配置文件（如下图）中加了两个aspect标签🏷️，所以childElts里有两个Element，于是会再按上面👆得大致流程再执行一遍

全部遍历完成后一路返回

其实吧，说到底BeanDefinition的解析过程( loadBeanDefinitions()），也就是配置文件的加载过程，毕竟都是Bean嘛^ ^