每天一点点 ，Spring 循环依赖

循环依赖的 三个 Map

1、DefaultSingletonBeanRegistry#singletonObjects

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

2、DefaultSingletonBeanRegistry#earlySingletonObjects

private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);

3、DefaultSingletonBeanRegistry#singletonFactories

private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

循环依赖

例如 UserService 和OrderService相互依赖

UserService

@Component
public class UserService {
	@Autowired
	private OrderService orderService;
	
}

OrderService

@Component
public class OrderService {

	@Autowired
	private UserService userService;
}

问题分析

UserService 创建的时候会经历
1、实例化前
2、实例化
3、属性填充
4、执行Aware 方法
5、执行初始化前
6、afterPropertiesSet方法
7、执行init方法
8、执行初始化后（AOP）

OrderService 创建的过程也会经历和UserService一样的过程

UserService 执行第三步进行属性填充的时候，会去容器中找有没有OrderService。此时没有，会执行OrderService的创建逻辑，在OrderService填充属性的时候，发现需要注入UserService，造成循环依赖。

尝试解决

1、导致循环依赖的原因是在OrderService在填充属性时，此时从单例池 singleObjects中获取UserService对象，但是此时单例池中没有，导致循环依赖。
2 、所以 我们是否可以在UserService 实例化之后，将实例化的对象保存到一个Map中，这样当OrderService在填充属性的时候，我就可以从这个map中获取这个对象。
3、而这个Map肯定不能是 单例池的singleObjects这个map中，因为此时的UserService并不是一个完整的对象(没有经历过一个完整的生命周期,例需要自动注入的属性没有被赋值),那此时如果直接放到 单例池中, 如果有另外一个线程去获取UserService,则拿出来的对象就是一个有问题的bean 。
4、所以，

方案一： 将这个创建出来的对象当做方法形参传递下去
方案二： 定义一个Map，命名为 earlySingletonObjects<String,Object> ，这个map的key为当前正在执行创建的beanName, value为当前实例化出来的bean对象

上面的两种方案选择，应该是方案二会更好一些，所以使用方案二（earlySingletonObjects）

我们再修改上面流程

---

UserService -->实例化–>属性填充->发现依赖OrderService( 从单例池singleObjects中找OrderService,发现找不到执行创建流程, 填充属性发现依赖UserService, 先从单例池earlySingletonObjects中拿,得到不到, 再从新加的 earlySingletonObjects中取,此时可以得到,执行 属性赋值等后续流程-- OrderService创建结束) -------> 后续的处理流程 —> 放入到单例池singleObjects中.

---

好了，这样 UserService和OrderService 都可以创建成功。
思考： 这样有没有问题 ？

1. 假如UserService 需要Aop呢 ？如果UserService 需要Aop，那么放入单例池singleObjects中的对象应该是代理对象。
2. 按照上面的逻辑，那么OrderService中注入的UserService并不是我们代理对象，而是我们的原始对象，这是有问题的
3. 那我们在放入earlySingletonObjects的时候直接生成代理对象，然后再放入不就好了吗？
4. 再思考一下：确实可以这么做, 但是这样是否合理呢?

1. earlySingletonObjects 存在的意义是做什么? 是相互依赖的时候, OrderService可以临时先得到一个UserService对象,完成创建流程, 避免一直这样 反复重复.
2. 如果当前类不存在循环依赖问题，我是否依旧需要存到这个earlySingletonObjects中？应该是不需要的吧？
3. 怎么判断当前类存不存在循环依赖？应该是在OrderService 填充属性的时候最好判断UserService是否存在循环依赖。
4. 当存在循环依赖的时候，需要得到一个 bean，这个bean有可能是原始对象，也有可能是代理对象。

5. 仔细思考

1. 在创建OrderService的时候，才会知道UserService是否存在循环依赖
2. 在实例化的时候进行AOP 应该是不合适的，因为在后面的操作中，是会需要原始对象的。
3. 我们需要在填充OrderService 的UserService属性的时候得到一个对象，这个对象可能是原始对象，也可能是代理对象。（考虑写一个接口提供这个方法？）

由此，出现第三个Map（singletonFactories<beanName, ObjectFactory>）

public interface ObjectFactory<T> {
	// 得到当前需要的对象,可能是代理对象,也可能是原始对象,这里面写了具体的逻辑
	T getObject() throws BeansException;
}

修改上述流程

---

UserService -->实例化–>属性填充->发现依赖OrderService( 从单例池singleObjects中找OrderService,发现找不到执行创建流程, 填充属性发现依赖UserService, 先从单例池earlySingletonObjects中拿,得到不到, 再从 earlySingletonObjects中取,如果取不到，再到 singletonFactories 中取，执行方法体得到一个UserService对象(此处我不关心是原始对象还是代理对象),执行属性赋值等后续流程-- OrderService创建结束) -------> 后续的处理流程 —> 放入到单例池singleObjects中.

---

总结

DefaultSingletonBeanRegistry#singleObjects<String, Object> ：

key ：beanName ； 
value ： 经历完整生命周期的bean对象

DefaultSingletonBeanRegistry#earlySingletonObjects<String, Object> ：

key ：beanName ； 
value ：没有经历完整生命周期的半成品bean对象

DefaultSingletonBeanRegistry#singletonFactories<String, ObjectFactory<?>>

key ：beanName ； 
value ：得到当前名称对应的一个bean对象，可能是原始对象，也可能是代理对象