最近遇到一个Spring注入失败的问题。起因是需要在一个Controller ClassB里注入另一个Controller ClassA（一个令人蛋疼的原因），启动的时候报异常，提示需要的类型是ClassA，找到的Bean的实际类型是com.sun.proxy.$Proxy。代码里有一个用来打日志Aop的切面涉及到了ClassA。但是ClassA明明没有实现任何接口啊，proxy对象也应该是使用CGlib生成的，类型应该是ClassA$$EnhancerByCGLIB才对。
把注入Controller的类型改为Object，然后加了断点Debug看了下bean内容。如下图所示，可以看出真正的原始Controller被代理了两次。先是使用CGlib生成的FirstController$$EnhancerBySpringCGLIB类型的代理对象，然后使用JDK动态代理使用这个代理对象做为target又生成了一个com.sun.proxy.$Proxy类型的代理对象
google了一下，看到一篇文章和我遇到的问题很相似：spring二次代理的问题。先说一下问题产生的根本原因：spring上下文里的的BeanPostProcessor列表有多个AbstractAdvisorAutoProxyCreator。spring的动态代理的原理是在bean生命周期的BeanPostProcessor拓展点对bean进行检查是否符合某一个AOP切面的规则，如果需要代理的话，将这个bean替换为代理对象。AbstractAdvisorAutoProxyCreator就是用来生成代理
对象的BeanPostProcessor，它一共有下面四个实现，除了InfrastructureAdvisorAutoProxyCreator，其他的ProxyCreator都能够解析用户通过Advisor类型的Bean定义的切面
DefaultAdvisorAutoProxyCreator //基础的ProxyCreator
AnnotationAwareAspectJAutoProxyCreator //能够解析AspectJ注解的ProxyCreator
AspectJAwareAdvisorAutoProxyCreator //能够解析AspectJ规则的ProxyCreator
InfrastructureAdvisorAutoProxyCreator //只解析Spring本身基础设施里的切面，忽略用户定义的切面
BeanPostProcessor的机制是从Spring管理的bean中找到所有实现了BeanPostProcessor接口的类，将其注册到beanPostProcessors中，bean会被beanPostProcessors中的每一个Processor处理，也就是说在存在多个ProxyCreator的情况下，bean被之前的ProxyCreator处理以后已经变成了一个代理对象，仍然会被下一个ProxyCreator继续处理，如果这个代理对象仍然符合某一个AOP切面的规则，就会对这个代理对象在产生一个代理对象。
项目中出现问题的代码类似于下面这样,通过Advisor定义了一个切面，规则是所有q.g.controller下的类生效。即使用了aop:aspectj-autoproxy（相当于注册了一个DefaultAdvisorAutoProxyCreator），又注册了一个DefaultAdvisorAutoProxyCreator。这时beanPostProcessors就有了就有了两个ProxyCreator，首先第一个ProxyCreator对controller进行处理，因为controller没有实现任何接口，所以采用CGlib生成了代理对象，代理对象的类型是FirstController$$EnhancerBySpringCGLIB，同时实现了三个接口：org.springframework.aop.SpringProxy
org.springframework.aop.framework.Advised
org.springframework.cglib.proxy.Factory
然后第二个ProxyCreator对这个代理对象进行处理，该代理对象的类的package也是q.g.controller，仍然符合切面的规则。因为该代理对象实现了三个接口，所以就使用JDK基于接口的动态代理生成代理对象。代理对象的类型是$Proxy，package是com.sun.proxy，不再符合切面的规则，即使后面仍然有更多的ProxyCreator，也不会再基于当前的代理对象生成一个新的代理对象
<aop:aspectj-autoproxy/>
<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
<bean id="firstAdvice" class="q.g.aop.FirstAdvice"></bean>
<bean id="advisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice">
<ref bean="firstAdvice" />
</property>
<property name="patterns">
<list>
<value>q\.g\.controller\..*</value>
</list>
</property>
</bean>
如果将配置改为下面这样，强制使用CGlib生成代理对象，有N个ProxyCreator就会产生N次代理
<aop:aspectj-autoproxy proxy-target-class="true"/>
<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
<property name="proxyTargetClass" value="true"/>
</bean>
<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
<property name="proxyTargetClass" value="true"/>
</bean>
<bean id="firstAdvice" class="q.g.aop.FirstAdvice"></bean>
<bean id="advisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice">
<ref bean="firstAdvice" />
</property>
<property name="patterns">
<list>
<value>q\.g\.controller\..*</value>
</list>
</property>
</bean>
总结
出现多次代理的条件：
- 有多个ProxyCreator
- 生成的代理对象仍然符合切面规则
不要使用多种AOP配置的方式和定义切面时范围尽量精确可以很大程度避免发生这个问题。
另外，杂乱的spring配置文件真是排查这类问题的大敌。不得不吐槽公司项目中的spring 配置文件真的又多又乱，没有一个统一的规则，大家在改动时使用的配置方式、修改的配置文件都不一样，再加上Spring mvc里servlet context 和root context的关系大家一般也不会去关注，很容易埋一些坑在里面。
