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

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

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第1张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第2张图片

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

  1. 设置容器的启动时间

  1. 设置活跃状态为true

  1. 设置关闭状态为false

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

  1. 准备监听器和事件的集合对象(默认为空)

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

创建容器

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第3张图片

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第4张图片

读取并解析XML配置文件

【Spring源码】AOP的开端:核心对象创建的准备工作_第5张图片

进入loadBeanDefinitions()

【Spring源码】AOP的开端:核心对象创建的准备工作_第6张图片
【Spring源码】AOP的开端:核心对象创建的准备工作_第7张图片
【Spring源码】AOP的开端:核心对象创建的准备工作_第8张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第9张图片

registerBeanDefinitions()

【Spring源码】AOP的开端:核心对象创建的准备工作_第10张图片
【Spring源码】AOP的开端:核心对象创建的准备工作_第11张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第12张图片

开始重头戏(。・ω・。)ノ

【Spring源码】AOP的开端:核心对象创建的准备工作_第13张图片

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

  • parseDefaultElement

  • parseCustomElement

  • 找到对应的handler

就属于自定义元素类型,所以我们进入parseCustomElement()方法中

【Spring源码】AOP的开端:核心对象创建的准备工作_第14张图片

进入parseCustomElement()

【Spring源码】AOP的开端:核心对象创建的准备工作_第15张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第16张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第17张图片

进入其一个实现类NamepaceHandlerSupport中

【Spring源码】AOP的开端:核心对象创建的准备工作_第18张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第19张图片

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

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

  1. 解析下的子节点

  1. POINTCUT

  1. ADVICE

  1. ASPECT

我们依次来看看

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第20张图片

进入方法configureAutoProxyCreator()

【Spring源码】AOP的开端:核心对象创建的准备工作_第21张图片

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

进入registerAspectJAutoProxyCreatorIfNecessary()

【Spring源码】AOP的开端:核心对象创建的准备工作_第22张图片

registerOrEscalateApcAsRequired()

【Spring源码】AOP的开端:核心对象创建的准备工作_第23张图片

进入registerOrEscalateApcAsRequired()

【Spring源码】AOP的开端:核心对象创建的准备工作_第24张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第25张图片

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

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第26张图片

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第27张图片

useClassProxyingIfNecessary()

【Spring源码】AOP的开端:核心对象创建的准备工作_第28张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第29张图片

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

registerComponentIfNecessary()

【Spring源码】AOP的开端:核心对象创建的准备工作_第30张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第31张图片

接着回到parse()方法中,可以看到此时还是null

【Spring源码】AOP的开端:核心对象创建的准备工作_第32张图片

第二个步骤:解析下的子节点

继续解析子节点下的

【Spring源码】AOP的开端:核心对象创建的准备工作_第33张图片

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

  • parsePointcut()

  • parseAdvisor()

  • parseAspect()

下面我们按照我们的测试代码中的XML配置(如下图)捋一遍流程(。・ω・。)ノ

【Spring源码】AOP的开端:核心对象创建的准备工作_第34张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第35张图片

parseAspect()

【Spring源码】AOP的开端:核心对象创建的准备工作_第36张图片

先获取的两个属性:

  • id属性

  • ref属性(代表切面,必须配置)

【Spring源码】AOP的开端:核心对象创建的准备工作_第37张图片

接着解析下的declare-parents节点,通过DeclareParentsAdvisor作为beanClass加载,然后继续解析其他节点

【Spring源码】AOP的开端:核心对象创建的准备工作_第38张图片

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

isAdviceNode()

判断是否为Advice节点

【Spring源码】AOP的开端:核心对象创建的准备工作_第39张图片

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

  • {@code before}

  • {@code after}

  • {@code after-returning}

  • {@code after-throwing}

  • {@code around}

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

解析成功则继续向下执行

【Spring源码】AOP的开端:核心对象创建的准备工作_第40张图片

parseAdvisor()

【Spring源码】AOP的开端:核心对象创建的准备工作_第41张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第42张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第43张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第44张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第45张图片

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

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

createAdviceDefinition()

进入方法createAdviceDefinition()

【Spring源码】AOP的开端:核心对象创建的准备工作_第46张图片

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

getAdviceClass()

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第47张图片

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

  • 设置aspectName属性和declarationOrder属性

  • 设置returning、throwing、arg-name这3个属性(先判断,有则设置)

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

  • Method

  • AspectJExpressionPointcut

  • AspectInstanceFactory

然后解析节点

【Spring源码】AOP的开端:核心对象创建的准备工作_第48张图片
parsePointcutProperty()
【Spring源码】AOP的开端:核心对象创建的准备工作_第49张图片

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第50张图片
  • methodDefinition:MethodLocatingFactoryBean

  • aspectFactoryDef:SimpleBeanFactoryAwareAspectInstanceFactory

  • adviceDef:AspectJMethodBeforeAdvice

  • adviceDefinition:AspectJPointcutAdvisor

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第51张图片

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第52张图片

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

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

【Spring源码】AOP的开端:核心对象创建的准备工作_第53张图片

全部遍历完成后一路返回

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

你可能感兴趣的:(Java,java,spring,源码,AOP)