一、@Autowired依赖注入的缓存

二、@Resource依赖注入过程

三、循环依赖

1. singletonObjects：缓存经过了完整生命周期的bean
2. earlySingletonObjects：缓存未经过完整生命周期的bean，如果某个bean出现了循环依赖，就会提前把这个暂时未经过完整生命周期的bean放入earlySingletonObjects中，这个bean如果要经过AOP，那么就会把代理对象放入earlySingletonObjects中，否则就是把原始对象放入earlySingletonObjects，但是不管怎么样，就是是代理对象，代理对象所代理的原始对象也是没有经过完整生命周期的，所以放入earlySingletonObjects我们就可以统一认为是未经过完整生命周期的bean。
3. singletonFactories：缓存的是一个ObjectFactory，也就是一个Lambda表达式。在每个Bean的生成过程中，经过实例化得到一个原始对象后，都会提前基于原始对象暴露一个Lambda表达式，并保存到三级缓存中，这个Lambda表达式可能用到，也可能用不到，如果当前Bean没有出现循环依赖，那么这个Lambda表达式没用，当前bean按照自己的生命周期正常执行，执行完后直接把当前bean放入singletonObjects中，如果当前bean在依赖注入时发现出现了循环依赖（当前正在创建的bean被其他bean依赖了），则从三级缓存中拿到Lambda表达式，并执行Lambda表达式得到一个对象，并把得到的对象放入二级缓存（(如果当前Bean需要AOP，那么执行lambda表达式，得到就是对应的代理对象，如果无需AOP，则直接得到一个原始对象)）。
4. 其实还要一个缓存，就是earlyProxyReferences，它用来记录某个原始对象是否进行过AOP了。

earlySingletonObjects是解决循环依赖的关键，如果A、B两个对象相互依赖，两次调getSingleton()方法，第二次是A对象进来，然后单例池中还没有A对象，earlySingletonObjects没有调getObject()方法也没有存A对象，又创建新的的对象，B调用getSingleton()方法又面临相同的问题

prototype是没法保证循环依赖不出错的，原理还是之前说的A、B之间相互依赖，A注入B，B调用getBean()创建对象，也进行依赖注入，A属性是原型的需要重新创建，注入A，回到A，A也要对B注入，B也是原型的又要重新创建，无法解决