做一个合格的程序猿之浅析Spring AOP源码(十八) Spring AOP开发大作战源码解析

其实上一篇文章价值很小,也有重复造轮子的嫌疑,网上AOP的实例很多,不胜枚举,其实我要说的并不是这个,我想要说的就是上一节中spring的配置文件:

我们这边并没有用到我们上几节分析的哪几个AOP的主要实现类:ProxyFactoryBean.java , ProxyFactory.java ,AspectJProxyFactory.java ,在我们这个配置文件中,根本没有显示的去配置这些类,那么spring到底是怎么做到的呢?


大家可以这么想,spring到底是怎么去杀害目标对象的呢?真正的凶手到底是谁呢(ProxyFactoryBean?ProxyFactory?AspectJProxyFactory)?在什么时候杀害的呢(Spring IoC容器初始化的哪个阶段做代理的呢?)



其实,这边有好几个问题

① spring容器里面到底有几个实例

(其实这个很好解决,我们只需要打开refresh方法,看下beanfactory中的beandefinitionMap中有多少个对象就可以知道了)

②spring到底什么时候偷梁换柱的呢,也就是说,我们的目标对象到底在spring容器初始化阶段的哪个阶段被换成了代理呢?

关于这个问题,我觉得我们应该自己给出答案,还记得我们在分析Spring IoC 源码的时候,我们说想修改一个bean 大体上只有2个阶段,或者说3个小段


首先是在执行beanfactoryPostProcessor的阶段,我们以前讲过这个阶段是修改beandefinition,修改了beandefinition就会直接修改了这个bean的生成,所以这个阶段很有可能是做代理的地方,但是仔细一分析,应该也不是,如果在这个阶段代理了,那么如果我们被代理的目标对象实现了其他接口呢,例如InitializingBean,或者定义了init-method这些方法呢,是不是得不到执行呢?所以应该不是

然后第二个最大的疑点就是beanPostProcessor阶段,这个接口又分成了2个阶段,大家应该还记得这个接口的核心接口:



其实这2个方法都可以直接临时修改bean,但最最有可能的就是postProcessAfterInitialization这个接口了,因为我们以前分析过postProcessAfterInitialization这个方法是在bean初始化过程中最后一个执行的,也就是说,如果在这个阶段,Spring偷偷地替换了bean,对于我们来说是透明的,完全没有感觉,因为bean的一些实例化操作都全部做完了


好了,分析到现在,其实我就想说我们现在要做的事情就是我们看下IoC 的refresh方法,主要看看一下几点,就知道基于IoC配置的AOP的原理了

①看下beanDefinition

②看下BeanFactoryPostProcessor这个处理

③看下BeanPostProcessor的注册

④看下我们目标对象在postProcessAfterInitialization这个阶段发生了什么?

⑤看下我们advisor是怎么生成的,代理怎么做的


好了,我们先看第一点:

首先BeanFactory中BeanDefinitionMap的对象是9个,除了我们明面上定义的2个,还有7个我们不知道的bean也生成了(关于这7个是怎么生成的,这边就不细讲了,主要是根据Spring的xml文件的命名空间去做转换然后当做普通的bean处理的),这边最值得怀疑的就是上图中红色标中的前2个(尼玛,看名字就知道了)



我们接着看第二点:

当我们debug已经过了BeanFactoryPostProcessor的执行过后,我们看下beandefinitionMap:

看样子并没有进行修改,说明凶手并不是BeanFactoryPostProcessor


好了,我们接着看第四点(第三点最后看),我们将断点打到AbstractAutowireCapableBeanFactory.java的1518行(spring.3.2.5)

进入详细方法:

好了,我们来看下我们目标对象的遗照吧,等下即将被凶手残忍的杀害

到这边为止bean中的对象还是我们的bussinessServiceImpl


接下来凶杀即将开始,当我们执行到一个名字叫org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator$BeanFactoryAdvisorRetrievalHelperAdapter的时候,我们进入一下postProcessAfterInitialization这个方法:AbstractAutoProxyCreator.java的postProcessAfterInitialization方法

进入wrapIfNecessary中

好了,我们再看下到底用什么刀杀的,进入createProxy方法:


原来这把刀就是ProxyFactory,哈哈~终于找出原因了


现在我们已经知道凶手是谁,在什么地方杀害的目标对象,那么还剩下最后一个问题,凶手是怎么潜入被害者的房间呢?


我们还是回到我们刚刚没说的第三点:我们看看BeanPostProcessor的注册,回到refresh方法中的registerBeanPostProcessors方法

看到没有,凶手就是在这个时候潜入房间的,等到下文spring在实例化目标对象的时候,一杀即中



到目前为止,我们已经基本上知道了凶杀的基本流程,但是细节我们还没有分析,比如说advisor怎么生成的,凶手怎么知道在黑夜中就是要杀bussinessService呢?这些还请大家稍微看下就可以了~


今天就到这边了,各位柯南大神,end~










  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值