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

Posted 2020-06-29 BazingaLyncc

其实上一篇文章价值很小，也有重复造轮子的嫌疑，网上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~