SpingAOP源码研究

     如果之前没有读过Spring源码,建议先看一下我之前写的一个实现AOP的小demo

     在看SpingAOP源码之前先简单说一下SpingIOC的实现机制。SpingIOC的中最核心的接口是BeanFactory它更像是IOC容器的一个最基本的功能说明书,它有一个底层的实现类DefaultListableBeanFactory这个类基本上实现了BeanFactory体系中的所有重要功能,只有就是我们所熟悉的ApplicationContext。它是在BeanFactory的基础上做了扩展。继承了MessageSource, ApplicationEventPublisher, ResourcePatternResolver等接口以增强除BeanFactory基本功能之外的功能。ApplicationContext的子类基本上使用的就是DefaultListableBeanFactory。

IOC容器的初始化步骤:

     1> 定位Resource资源

     2> 创建DefaultListableBeanFactory

     3> 创建处理资源的BeanDefinitionReader

     4> 将Resource解析为Document

     5> 将Document解析为Spring定义的内部数据结构BeanDefinition

     6> 将BeanDefinition注册到Factory的CurrentHashMap中

     7> 创建对象(BeanFactory,Constructor,CGLIB)

     8> 解决依赖关系注入Property(期间会创建所有直接依赖或者间接依赖的类,直到这些类都创建并初始化完成之后,主类才会初始化完成)

     9> 将Bean注册到DefaultSingletonBeanRegistry的ConcurrentHashMap中 SpingIOC是非常强大的强大的副作用就是代码不容易理解。所以说肯定是没有我之前写的那个AOP小Demo好理解了。首先来看AOP通知接口的体系结构。

     SpingIOC是非常强大的强大的副作用就是代码不容易理解。所以说肯定是没有我之前写的那个AOP小Demo好理解了。首先来看AOP通知接口的体系结构。
       
 

之后是切入点:

   

还有一个Advisor(通知器),它用来将Advice和Pointcut组织在一起


  想要调用代理方法,必须要先有代理对象,那么代理对象是在哪产生的?代理对象其实是在一个处理器AbstractAutoProxyCreator中产生的。用过Spring中处理器的人肯定知道实现BeanPostProcessor接口,然后覆盖postProcessBeforeInitialization,postProcessAfterInitialization两个方法就可以在bean执行init方法前后来处理逻辑了。其实现原理其实很简单,在初始化Bean时可以看到如下代码



 分别是前置处理,init方法调用,后置处理。看一下生成代理对象类AbstractAutoProxyCreator的类签名



 

 

     这样明白了,其实AbstractAutoProxyCreator类就是处理器。如果一个Bean需要创建代理对象的话,就会在这个Bean的init方法执行完之后调用后置处理器创建。创建完之后就会被放置到AbstractAutoProxyCreator类中的一个ConcurrentHashMap中



 

由于我的目标对象实现了接口所以使用的是JDK代理,否则的话会使用CGLIB代理。


这是最核心的类,所有被代理的方法都会调用它的invoke方法其中有一个字段

 

	/** Config used to configure this proxy */
	private final AdvisedSupport advised;

 下面是它的截图


 

 

只要搞定它是怎么来的,就会知道通知,切入点,目标类是怎么产生的。

想向下追两个方法都很有用

 


 

在这里判断了是使用CGLIB创建代理还是JDK创建代理

 


 

可以看到之前那个万能的字段其实是ProxyCrentorSupport类的实例,还记得之前创建代理的AbstractAutoProxyCreator吗,它们有着共同的基类。ProxyConfig为它的子类提供了配置属性。


下面就要追一下这两个类之间是怎么建立关系的。上图调用createAopProxy(this)函数最开始的调用者是AbstractAutoProxyCreator也就是说这个this其实是ProxyFactory的实例




可以看到ProxyFactory又是ProxyCreatorSupport的子类。

那么proxyFactory又是怎么来的?



 

 

这样也就建立了ProxyCrentorSupport类与AbstractAutoProxyCreator的关系 。也就是说ProxyCrentorSupport在创建代理的工厂AbstractAutoProxyCreator与代理类之间建立了一个桥梁,真正有用的数据像通知,切入点,目标类等最初还是AbstractAutoProxyCreator提供的。ProxyCrentorSupport也起到屏蔽AbstractAutoProxyCreator中的一些敏感信息,防止被代理类获取到作用。ProxyCrentorSupport还是一个抽象工厂,是非常经典的抽象工厂模式的应用。

可以稍微追一下advisor是从哪来的



 现在来看JdkDynamicAopProxy中invoke是怎么执行的。首先它会创建一个ReflectiveMethodInvocation实例,然后让这个实例来调用proceed方法。这个ReflectiveMethodInvocation就相当于之前小Demo的ApplicationFilterChain。其结构如下



 其中每一个advice被调用时都会把自身实例传入其中,然后调完通知方法之后就会重新调用ReflectiveMethodInvocation实例的proceed方法。这样便形成了回调机制,也就实现了AOP的功能(跟我的小demo原理一样)。其他通知与前置通知类似,异常通知是直接让你执行一个try…catch块环绕的代码,这样报错之后就会被处理。至于最终通知是把proceed放在了一个try…finally中。

猜你喜欢

转载自smallbug-vip.iteye.com/blog/2283026