Spring源码学习笔记9——构造器注入及其循环依赖
一丶前言
前面我们分析了spring基于字段的和基于set方法注入的原理，但是没有分析第二常用的注入方式（构造器注入）（第一常用字段注入），并且在循环依赖问题上构造器注入常被说spring无法解决构造器注入的循环依赖，下面我们来分析构造器注入和其循环依赖的源码
二丶构造器依赖注入
在spring初始化每一个非抽象，单例，非懒加载的bean的时候，会调用createBeanInstance方法去创建bean的实例，在使用默认的策略——无参构造or CGLIB生成子类对象的方式之前，先会使用所有的SmartInstantiationAwareBeanPostProcessor 来判断是否有用户指定的后置处理器
1.循环调用所有的SmartInstantiationAwareBeanPostProcessor实现类来推断该使用哪个构造器
这里重点是使用到了AutowiredAnnotationBeanPostProcessor来推断
2.AutowiredAnnotationBeanPostProcessor 推断构造器的逻辑
首先AutowiredAnnotationBeanPostProcessor 有一个缓存key是bean类型，value是之前推断的所有构造器数组。自然是一波双if+synchronized方式来读缓存中内容，缓存没有命中再进行推断
遍历每一个构造器（这里省去了spring对Kotlin语言支持的部分） 1.获取当前构造器上面的@Autowired 和 @Value 注解 2.如果注解信息为空，且当类是一个被CGLIB代理后的类， 会获取父类构造器上面的注解（要求父类构造器和当前遍历到的构造器参数类型顺序相同） 3.如果注解信息不为空，会检查 required 属性的信息 （spring还支持ejb等的注解，所有这里检查require的信息）像@Autowired 和 @Value这种不包含required属性的注解会默认是required为true， 并且记录当前构造器为候选者，也就是说有注解的才算在候选者 4.如果存在多个required=true的构造器抛出异常， 否则使用遍历记录当前required=true的构造器 5.如果候选者不为空，required=true的构造器为空 （一般这种情况是标注了EJB的注解指定required为false）spring会把无参构造加入到候选者中 6.如果原来类只定义了一个有参构造，那么使用这个有参构造 如果不考虑EJB中的依赖注入注解 那么就是如果构造器有@Autowired or @Value那么默认使用它 如果定义了一个有参构造那么使用这个有参构造 其他情况一律返回null(后续spring可能使用无参构造or CGLIB生成子类的方式)
3.使用构造器进行依赖注入的逻辑
推断出使用哪个构造器之后，spring调用autowireConstructor方法进行构造器注入，具体逻辑委托给ConstructorResolver的autowireConstructor方法，最终解析依赖注入参数的在createArgumentArray方法中进行，一般是调用resolveAutowiredArgument方法
最终还是殊途同归的调用到了beanFactory的resolveDependency方法
4.实例化对象
这一步还是调用的instantiate方法
三丶为什么构造器的循环依赖spring无法解决
1.构造方法注入无法解决循环依赖的情况及其原因
如果是这种循环依赖的情况spring是无法解决循环依赖的，下面是这种循环依赖出现时候的代码流程
问题出现在beforeSingletonCreation方法中
在spring创建bean的之前使用了set维护正在创建bean的名称，B需要A，再次创建A的时候就发现set中原本存在A，这时候就是无法解决循环依赖的情况，会抛出异常
同理这种情况也是不可以解决的
2.构造方法注入可以解决循环依赖的情况及其原因
这种情况下spring又是可以解决循环依赖的
原因是A是可以成功使用无参构造实例化的，所以B需要A的时候可以在三级缓存拿到A的ObjectFactory，调用后得到A，而不是再次创建A
我们可以得到结论 如果加载顺序是A然后B，那么A只能是字段注入or方法注入，不能是构造器注入 B无所谓那种注入方式
__EOF__
