上一篇分析了两种代理的大致原理，spring框架内的aop就是使用的这两种代理模式。spring在默认情况下可以根据被代理类是否实现接口自动切换代理方式，实现了接口使用jdk代理，没实现接口使用cglib。
public class DefaultAopProxyFactory implements AopProxyFactory, Serializable {
@Override
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
Class<?> targetClass = config.getTargetClass();
if (targetClass == null) {
throw new AopConfigException("TargetSource cannot determine target class: " +
"Either an interface or a target is required for proxy creation.");
}
if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
return new JdkDynamicAopProxy(config);
}
return new ObjenesisCglibAopProxy(config);
}
else {
return new JdkDynamicAopProxy(config);
}
}
/**
* Determine whether the supplied {@link AdvisedSupport} has only the
* {@link org.springframework.aop.SpringProxy} interface specified
* (or no proxy interfaces specified at all).
*/
private boolean hasNoUserSuppliedProxyInterfaces(AdvisedSupport config) {
Class<?>[] ifcs = config.getProxiedInterfaces();
return (ifcs.length == 0 || (ifcs.length == 1 && SpringProxy.class.isAssignableFrom(ifcs[0])));
}
}
然后如果我们在配置文件设置了<aop:aspectj-autoproxy proxy-target-class="true"/>后，“通常，指定{@code proxyTargetClass}来强制执行CGLIB代理，或指定一个或多个接口以使用JDK动态代理。” 这是spring的注释，意思是代理被强制指定cglib。
上面这段代码发生在程序启动时，bean注入到DefaultListableBeanFactory的beanDefinitionNames里面，如果当前被注入的bean并没有需要代理的标签等，比如自定义aop，声明式事务等，是不会走到这里的，直接注入的就是相应的类，而需要代理的会被包装成代理注入进去。
然后接下来还是启动过程中，会执行bean的初始化的托管注入，被@Autowiredd的bean会走一系列的步骤寻找出实例注入到当前初始化的bean。这一系列的动作链路很长，并且bean加载顺序不同，步骤略有不同，debug出一种：
DefaultListableBeanFactory.resolveDependency()--DefaultListableBeanFactory.doResolveDependency()--DefaultListableBeanFactory.findAutowireCandidates()--BeanFactoryUtils.beanNamesForTypeIncludingAncestors()--
DefaultListableBeanFactory.getBeanNamesForType()--DefaultListableBeanFactory.doGetBeanNamesForType()--AbstractBeanFactory.isTypeMatch()--ResolvableType.isInstance()--ResolvableType.static ResolvableType forRawClass()--
ResolvableType.static ResolvableType forRawClass {}isAssignableFrom()--ResolvableType.getRawClass()--ClassUtils.isAssignable() retrun true or false。
ClassUtils.isAssignable()方法是native的方法，用来判断是否可以转型。
这样分两种情况：
1.proxy-target-class=false
一个没实现接口的类，spring动态选择使用了cglib代理，被注入时TypeMatch时比较这个类和代理后他的子类，可以注入。
一个实现了接口的类，spring动态选择使用了jdk代理，当使用接口（如xxxService）注入时，TypeMatch时比较接口类和代理后的Proxy子类并实现了这个接口xxxService的类，可以注入。
一个实现了接口的类，spring动态选择使用了jdk代理，当使用实现类（如xxxServiceImpl）注入时，TypeMatch时比较实现类与代理后的Proxy子类并实现了这个接口xxxService的类，这时候是不通过的，因为他们既不是父类子类的关系，也不是实现的关系，这会导致启动失败，无法注入的错误。但是一般不会有人这么做，这是在我们项目里发现的做法，导致不能使用动态选择代理，只能将proxy-target-class=true解决。
2.proxy-target-class=true
一个没实现接口的类，spring强制使用了cglib代理，被注入时TypeMatch时比较这个类和代理后他的子类，可以注入。
一个实现了接口的类，spring强制使用了cglib代理，当使用接口（如xxxService）注入时，TypeMatch时比较接口类和代理后的xxxServiceImpl类型的子类，可以注入。
一个实现了接口的类，spring强制使用了cglib代理，当使用实现类（如xxxServiceImpl）注入时，TypeMatch时比较xxxServiceImpl和代理后的xxxServiceImpl类型的子类，可以注入。
所以配置文件中如何选择proxy-target-class属性，可根据具体代码决定。
实际项目中，发现在配置文件applicationContext.xml中加了proxy-target-class=true后，实现类注入依然注入失败，排查发现配置文件的component-scan配置有问题。正常我们项目有两个主要的配置文件，applicationContext.xml的父容器，xxx-servlet.xml的mvc子容器配置文件。component-scan配置正确的方式是父容器扫描除了controller外的bean，然后mvc子容器仅扫描controller的bean。
父容器：
<context:component-scan base-package="com.storm">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" />
</context:component-scan>
mvc子容器：
<context:component-scan base-package="com.storm" use-default-filters="false">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller" />
</context:component-scan>
这样是正确的配置，也可以制定具体的包进行扫描，例如：
<context:component-scan base-package="com.storm.controller" />
我们项目在mvc的配置文件没有加use-default-filters="false"，如果不加这个配置，他会默认扫描全部4种注解，导致又一次的扫描到service注解，serivce又被初始化了一遍，并覆盖之前初始化好的bean，而这个子容器的proxy-target-class没有配置，为默认的false，所以导致了初始化失败。
