一、面试为啥好问循环依赖问题
Spring是一个集大成者，我想能对其细节摸的透透的人，必定是大神级别了。
其实我一直好奇为啥网上一直流传Spring 循环依赖问题的面试题。我也断断续续看了很多人再解释循环依赖原理问题。但对于我来说，似乎还是对其有种似懂非懂的感觉。
面试问这个问题的意义在哪？
直到，我从源码世界转了几圈后，再回头看这个问题，我有种豁然开朗的感觉。
是因为这个循环依赖问题背后所需要的知识。
- 你需要对Bean的生命周期(即Spring 创建Bean的过程)有了解
- 你需要对AOP原理有了解
是的，简简单单一个循环依赖问题，其实蕴含的是Spring 最核心的两个点： Bean的生命周期与AOP原理。
这个问题很大程序上就能拷问出你对Spring框架的理解程度，这才是这道题深层的含义吧
基于此种思考，我也来讲讲我对循环依赖的理解。
二、基础知识准备
1. Java 引用传递还是值传递?
JAVA 里是值传递，值传递，值传递!!!
public class Test2 { public static void main(String[] args) { A a = new A(); System.out.println("（1）调用change前"+a); change(a); System.out.println("（3）调用change后"+a); } public static void change(A a){ a= new A(); System.out.println("（2）change方法内"+a); } } class A{ }
（1）调用change前com.wsjia.ms.controller.A@61064425 （2）change方法内com.wsjia.ms.controller.A@7b1d7fff （3）调用change后com.wsjia.ms.controller.A@61064425
我承认JAVA中都是值传递。
但此处想要表达的是：引用类型参数，与原引用值共同指向一块内存地址，对对象的修改是相互影响的。
本文姑且叫他引用的传递【我知道你应该懂得什么意思】
2. Bean创建的几个关键点
此处只是列出Bean的几个重要的阶段，为了讲清楚循环依赖，具体的在以后专门讲讲Bean的创建。
Spring 创建Bean的过程，大致和对象的初始化有点类似吧。有几个关键的步骤
- createBeanInstance ：实例化，此处要强调的是，
Bean的早期引用在此出现了。 - populateBean ： 填充属性，此处我们熟悉的
@Autowired属性注入就发生在此处 - initializeBean : 调用一些初始化方法，例如
init,afterPropertiesSet
此外：BeanPostProcessor作为一个扩展接口，会穿插在Bean的创建流程中，留下很多钩子，让我们可以去影响Bean的创建过程。其中最主要的就属AOP代理的创建了。
3. AOP的原理
AOP是以一个InstantiationAwareBeanPostProcessor类型的BeanPostProcessor,参与到Bean的创建逻辑中，并根据是否需要代理当前Bean，决定是否创建代理对象。
主要逻辑在(BeanPostProcessor)AbstractAutoProxyCreator类中中,有三个重要方法。
//早期bean创建代理用 public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { Object cacheKey = getCacheKey(bean.getClass(), beanName); this.earlyProxyReferences.put(cacheKey, bean); return wrapIfNecessary(bean, beanName, cacheKey); } //bean创建代理用 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean != null) { Object cacheKey = getCacheKey(bean.getClass(), beanName); if (this.earlyProxyReferences.remove(cacheKey) != bean) { return wrapIfNecessary(bean, beanName, cacheKey); } } return bean; } protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) { //创建代理的逻辑 }
当一个Bean创建代理后，我们通过beanname从BeanFactory中获取的就是就是代理的对象的了
4. getBean()返回的是什么？
当我们尝试按name从BeanFactory.getBean(beanname)一个Bean时，返回的一定是A类对应的实例吗？
答案是否， 当A需要需要创建代理对象时，我们getBean 得到是 代理对象的引用。
5. 三个缓存
本文暂时只考虑单例的情况
把创建好的Bean缓存起来，这是非常平常的逻辑。
/** Cache of singleton objects: bean name --> bean instance */ private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256); /** Cache of early singleton objects: bean name --> bean instance */ private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16); /** Cache of singleton factories: bean name --> ObjectFactory */ private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16); 复制代码
- singletonObjects：第一级缓存，里面存放的都是创建好的
成品Bean。 - earlySingletonObjects : 第二级缓存，里面存放的都是
半成品的Bean。 - singletonFactories ：第三级缓存， 不同于前两个存的是 Bean对象引用，此缓存存的bean 工厂对象，也就存的是
专门创建Bean的一个工厂对象。此缓存用于解决循环依赖
这里有个点：我个人认为这么叫这三个缓存更加合适
- singletonObjects：成品缓存
- earlySingletonObjects： 半成品缓存
- singletonFactories ：单例工厂缓存
至于为什么，稍微给我个人理解。
三、解析循环依赖
接下来开始讲讲循环依赖
本文只讨论，属性注入的情况。
假设有这么两个类产生了循环依赖。如果解决这个问题？
public class A { B b; public A() { } } class B{ @Autowired A a; public B() { } }
1.一个缓存能解决不？
首先我们先来讨论下这个循环依赖问题
- 从A获取开始，从缓存里查看，没有开始创建A实例，执行构造方法，填充属性时发现需要依赖B，
- 尝试从缓存中获取B。
- 开始创建B实例，执行构造方法，填充属性时，发现需要依赖A，取缓存找A .
- A正在创建没有完成。
- `死结`
2.两个缓存能解决不？？
不等创建完成，有了引用后，提前放入半成品缓存
- A引用创建后，提前暴露到
半成品缓存中 - 依赖B，创建B ，B填充属性时发现依赖A，
先从成品缓存查找，没有,再从半成品缓存查找取到A的早期引用。 B顺利走完创建过程, 将B的早期引用从半成品缓存移动到成品缓存- B创建完成，A获取到B的引用，继续创建。
- A创建完成，将
A的早期引用从半成品缓存移动到成品缓存 - `完美解决循环依赖`
嗯？ 两个缓存就能解决？？？为啥需要三个缓存？？
