【Spring源码解析】面试官：Spring底层如何使用三级缓存处理循环依赖问题？
文章目录
- 一、前言
- 二、什么是循环依赖？
- 三、Spring Bean的循环依赖
- 3.1 Spring Bean循环依赖的产生(单例模式的下的循环依赖,不用记,记住3.2三种循环依赖的构建就好)
- 3.2 Spring中对三种循环依赖的处理
- 3.2.1 循环依赖：构造函数
- 3.2.2 循环依赖：单例模式下属性注入(金手指:只是默认注入方式)
- 3.2.3 循环依赖：原型模式下的属性依赖
- 四、Spring解决循环依赖的原理分析
- 4.1 Spring创建Bean的流程
- 4.2 Spring容器的“三级缓存”
- 4.3 源码解析
- 4.4 流程总结
- 4.4.1 入口处即是实例化、初始化A这个单例Bean。AbstractBeanFactory.doGetBean("a")
- 4.4.2 下面进入到最为复杂的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()环节，创建A的实例
- 五、面试金手指
- 面试金手指1：什么是循环依赖？Spring中三种循环依赖？
- 面试金手指2：Spring底层如何使用三级缓存处理循环依赖问题？
- 面试金手指3：附加问题：为什么构造函数不可以？为什么单例模式属性注入可以？为什么原型模式属性注入不可以？
- 六、小结
一、前言
二、什么是循环依赖？
循环依赖：就是N个类循环（嵌套）引用。
通俗的讲就是N个Bean互相引用对方，最终形成闭环。用一副经典的图示可以表示成这样（A、B、C都代表对象，虚线代表引用关系）：
（1）其实可以N=1，也就是极限情况的循环依赖：自己依赖自己
（2）这里指的循环引用不是方法之间的循环调用，而是对象的相互依赖关系。（方法之间循环调用若有出口也是能够正常work的）
三、Spring Bean的循环依赖
3.1 Spring Bean循环依赖的产生(单例模式的下的循环依赖,不用记,记住3.2三种循环依赖的构建就好)
谈到Spring Bean的循环依赖，有的小伙伴可能比较陌生，毕竟开发过程中好像对循环依赖这个概念无感知。其实不然，你有这种错觉，权是因为你工作在Spring的襁褓中，从而让你“高枕无忧”~
我十分坚信，小伙伴们在平时业务开发中一定一定写过如下结构的代码：
@Service
public class AServiceImpl implements AService {
@Autowired
private BService bService;
...
}
@Service
public class BServiceImpl implements BService {
@Autowired
private AService aService;
...
}
这其实就是Spring环境下典型的循环依赖场景。但是很显然，这种循环依赖场景，Spring已经完美的帮我们解决和规避了问题（金手指：这是Spring三种循环依赖中的一种，单例模式的属性注入，Spring使用第三级缓存singletonFactories中的addSingletonFactory()处理循环依赖的问题）。所以即使平时我们这样循环引用，也能够整成进行我们的coding之旅~
3.2 Spring中对三种循环依赖的处理
在Spring环境中，因为我们的Bean的实例化、初始化都是交给了容器，因此它的循环依赖主要表现为下面三种场景。为了方便演示，我准备了如下两个类：
Spring容器对于注入属性(值或引用)有三种方式：
构造器
每一种注入引用，都会造成循环依赖，且看Spring对于不同的注入方式是如何处理的
3.2.1 循环依赖：构造函数
@Service
public class A {
public A(B b) {
}
}
@Service
public class B {
public B(A a) {
}
}
结果：项目启动失败抛出异常BeanCurrentlyInCreationException
构造器注入构成的循环依赖，此种循环依赖方式是无法解决的，只能抛出BeanCurrentlyInCreationException异常表示循环依赖。这也是构造器注入的最大劣势
根本原因：Spring解决循环依赖依靠的是Bean的“中间态”这个概念，而这个中间态指的是已经实例化，但还没初始化的状态。而构造器是完成实例化的，所以构造器的循环依赖无法解决~~~
3.2.2 循环依赖：单例模式下属性注入(金手指:只是默认注入方式)
这种方式是我们最最最最为常用的依赖注入方式（所以猜都能猜到它肯定不会有问题啦）：
@Service
public class A {
@Autowired
private B b;
}
@Service
public class B {
@Autowired
private A a;
}
结果：项目启动成功，能够正常work
备注：setter方法注入方式因为原理和字段注入方式类似，此处不多加演示
金手指：单例模式下属性注入是默认注入方式，初级程序员写代码就是这样注入的，这种注入方式的循环依赖可以被Spring处理，所以初级程序员一直没有遇到过循环依赖处理，由此可见Spring封装设计的优美
3.2.3 循环依赖：原型模式下的属性依赖
prototype在平时使用情况较少，但是也并不是不会使用到，因此此种方式也需要引起重视。
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class A {
@Autowired
private B b;
}
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class B {
@Autowired
private A a;
}
对于属性依赖，默认使用单例模式，不需要在一个将要设置到springioc容器中的类上面，使用@Scope注解（照顾初级开发者），也可以使用@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)指定为原型模式
结果：需要注意的是本例中启动时是不会报错的（因为非单例Bean默认不会初始化，而是使用时才会初始化），所以很简单咱们只需要手动getBean()或者在一个单例Bean内@Autowired一下它即可
// 在单例Bean内注入
@Autowired
private A a;
这样子启动就报错：
如何解决？？？
可能有的小伙伴看到网上有说使用@Lazy注解解决：
@Lazy
@Autowired
private A a;
此处负责任的告诉你这样是解决不了问题的(可能会掩盖问题)，@Lazy只是延迟初始化而已，当你真正使用到它（初始化）的时候，依旧会报如上异常。
金手指：对于Spring循环依赖的情况总结如下：
不能解决的情况： 构造器注入循环依赖、prototype模式field属性注入循环依赖
能解决的情况： singleton模式field属性注入（setter方法注入）循环依赖
四、Spring解决循环依赖的原理分析
在这之前需要明白java中所谓的引用传递和值传递的区别。
说明：看到这句话可能有小伙伴就想喷我了。java中明明都是传递啊，这是我初学java时背了100遍的面试题，怎么可能有错？？？
回答：这就是我做这个申明的必要性：伙计，你的说法是正确的，java中只有值传递。但是本文借用引用传递来辅助讲解，希望小伙伴明白我想表达的意思~
Spring的循环依赖的理论依据基于Java的引用传递，当获得对象的引用时，对象的属性是可以延后设置的。（但是构造器必须是在获取引用之前，毕竟你的引用是靠构造器给你生成的，儿子能先于爹出生？哈哈）
4.1 Spring创建Bean的流程
首先需要了解是Spring它创建Bean的流程，我把它的大致调用栈绘图如下：
对Bean的创建最为核心三个方法解释如下：
createBeanInstance：例化，其实也就是调用对象的构造方法实例化对象
populateBean：填充属性，这一步主要是对bean的依赖属性进行注入(@Autowired)
initializeBean：回到一些形如initMethod、InitializingBean等方法
从对单例Bean的初始化可以看出，循环依赖主要发生在第二步（populateBean），也就是field属性注入的处理。
金手指：从getBean() doGetBean() createBean() doCreateBean()
AbstractBeanFactory类中的getBean()方法和doGetBean()方法
AbstractAutowireCapableBeanFactory类中的createBean()方法和doCreateBean()方法，createBeanInstance()、populateBean()、initializeBean()
4.2 Spring容器的“三级缓存”
在Spring容器的整个声明周期中，单例Bean有且仅有一个对象。这很容易让人想到可以用缓存来加速访问。
从源码中也可以看出Spring大量运用了Cache的手段，在循环依赖问题的解决过程中甚至不惜使用了“三级缓存”，这也便是它设计的精妙之处~
三级缓存其实它更像是Spring容器工厂的内的术语，采用三级缓存模式来解决循环依赖问题，这三级缓存分别指：
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
...
// 从上至下 分表代表这“三级缓存”
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一级缓存
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二级缓存
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三级缓存
...
/** Names of beans that are currently in creation. */
// 这个缓存也十分重要：它表示bean创建过程中都会在里面呆着~
// 它在Bean开始创建时放值，创建完成时会将其移出~
private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
/** Names of beans that have already been created at least once. */
// 当这个Bean被创建完成后，会标记为这个 注意：这里是set集合 不会重复
// 至少被创建了一次的 都会放进这里~~~~
private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
}
一级缓存、二级缓存、三级缓存都是hashMap，key都是String
但是一级缓存和二级缓存value是Object，用来存放单例对象，三级缓存value是ObjectFactory，用来存放单例工厂对象
注：AbstractBeanFactory继承自DefaultSingletonBeanRegistry
（1）singletonObjects：用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用；
（2）earlySingletonObjects：提前曝光的单例对象的cache，存放原始的 bean 对象（尚未填充属性），用于解决循环依赖；
（3）singletonFactories：单例对象工厂的cache，存放 bean 工厂对象，用于解决循环依赖。
获取单例Bean的源码如下：
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
...
@Override
@Nullable
public Object getSingleton(String beanName) {
return getSingleton(beanName, true);
}
@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
...
public boolean isSingletonCurrentlyInCreation(String beanName) {
return this.singletonsCurrentlyInCreation.contains(beanName);
}
protected boolean isActuallyInCreation(String beanName) {
return isSingletonCurrentlyInCreation(beanName);
}
...
}
- 先从一级缓存singletonObjects中去获取。（如果获取到就直接return）
- 如果获取不到或者对象正在创建中（isSingletonCurrentlyInCreation()），那就再从二级缓存earlySingletonObjects中获取。（如果获取到就直接return）
- 如果还是获取不到，且允许singletonFactories（allowEarlyReference=true）通过getObject()获取。就从三级缓存singletonFactory.getObject()获取。（如果获取到了就从singletonFactories中移除，并且放进earlySingletonObjects。其实也就是从三级缓存移动（是剪切、不是复制哦~）到了二级缓存）
金手指：为什么基于构造器的循环依赖无法解决？
单例模式下的属性注入是使用singletonFactories来完成，但是加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决
getSingleton()从缓存里获取单例对象步骤分析可知，Spring解决循环依赖的诀窍：就在于singletonFactories这个三级缓存。这个Cache里面都是ObjectFactory，它是解决问题的关键。
// 它可以将创建对象的步骤封装到ObjectFactory中 交给自定义的Scope来选择是否需要创建对象来灵活的实现scope。 具体参见Scope接口
@FunctionalInterface
public interface ObjectFactory<T> {
T getObject() throws BeansException;
}
经过ObjectFactory.getObject()后，此时放进了二级缓存earlySingletonObjects内。这个时候对象已经实例化了，虽然还不完美，但是对象的引用已经可以被其它引用了。
金手指：二级缓存earlySingletonObjects的添加与移除？
唯一添加：向里面添加数据只有一个地方，就是上面说的getSingleton()里从三级缓存里挪过来
唯三移除：addSingleton、addSingletonFactory、removeSingleton从语义中可以看出添加单例、添加单例工厂ObjectFactory的时候都会删除二级缓存里面对应的缓存值，是互斥的。
4.3 源码解析
Spring容器会将每一个正在创建的Bean 标识符放在一个“当前创建Bean池”中，Bean标识符在创建过程中将一直保持在这个池中，而对于创建完毕的Bean将从当前创建Bean池中清除掉。
这个“当前创建Bean池”指的是上面提到的singletonsCurrentlyInCreation那个集合。
public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
...
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
...
// Eagerly check singleton cache for manually registered singletons.
// 先去获取一次，如果不为null，此处就会走缓存了~~
Object sharedInstance = getSingleton(beanName);
...
// 如果不是只检查类型，那就标记这个Bean被创建了~~添加到缓存里 也就是所谓的 当前创建Bean池
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
...
// Create bean instance.
if (mbd.isSingleton()) {
// 这个getSingleton方法不是SingletonBeanRegistry的接口方法 属于实现类DefaultSingletonBeanRegistry的一个public重载方法~~~
// 它的特点是在执行singletonFactory.getObject();前后会执行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName);
// 也就是保证这个Bean在创建过程中，放入正在创建的缓存池里 可以看到它实际创建bean调用的是我们的createBean方法~~~~
sharedInstance = getSingleton(beanName, () -> {
try {
return createBean(beanName, mbd, args);
} catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
}
...
}
// 抽象方法createBean所在地 这个接口方法是属于抽象父类AbstractBeanFactory的 实现在这个抽象类里
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {
...
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {
...
// 创建Bean对象，并且将对象包裹在BeanWrapper 中
instanceWrapper = createBeanInstance(beanName, mbd, args);
// 再从Wrapper中把Bean原始对象（非代理~~~） 这个时候这个Bean就有地址值了，就能被引用了~~~
// 注意：此处是原始对象，这点非常的重要
final Object bean = instanceWrapper.getWrappedInstance();
...
// earlySingletonExposure 用于表示是否”提前暴露“原始对象的引用，用于解决循环依赖。
// 对于单例Bean，该变量一般为 true 但你也可以通过属性allowCircularReferences = false来关闭循环引用
// isSingletonCurrentlyInCreation(beanName) 表示当前bean必须在创建中才行
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isTraceEnabled()) {
logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
}
// 上面讲过调用此方法放进一个ObjectFactory，二级缓存会对应删除的
// getEarlyBeanReference的作用：调用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()这个方法 否则啥都不做
// 也就是给调用者个机会，自己去实现暴露这个bean的应用的逻辑~~~
// 比如在getEarlyBeanReference()里可以实现AOP的逻辑~~~ 参考自动代理创建器AbstractAutoProxyCreator 实现了这个方法来创建代理对象
// 若不需要执行AOP的逻辑，直接返回Bean
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
Object exposedObject = bean; //exposedObject 是最终返回的对象
...
// 填充属于，解决@Autowired依赖~
populateBean(beanName, mbd, instanceWrapper);
// 执行初始化回调方法们~~~
exposedObject = initializeBean(beanName, exposedObject, mbd);
// earlySingletonExposure：如果你的bean允许被早期暴露出去 也就是说可以被循环引用 那这里就会进行检查
// 此段代码非常重要~~~~~但大多数人都忽略了它
if (earlySingletonExposure) {
// 此时一级缓存肯定还没数据，但是呢此时候二级缓存earlySingletonObjects也没数据
//注意，注意：第二参数为false 表示不会再去三级缓存里查了~~~
// 此处非常巧妙的一点：：：因为上面各式各样的实例化、初始化的后置处理器都执行了，如果你在上面执行了这一句
// ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);
// 那么此处得到的earlySingletonReference 的引用最终会是你手动放进去的Bean最终返回，完美的实现了"偷天换日" 特别适合中间件的设计
// 我们知道，执行完此doCreateBean后执行addSingleton() 其实就是把自己再添加一次 **再一次强调，完美实现偷天换日**
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 这个意思是如果经过了initializeBean()后，exposedObject还是木有变，那就可以大胆放心的返回了
// initializeBean会调用后置处理器，这个时候可以生成一个代理对象，那这个时候它哥俩就不会相等了 走else去判断吧
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
// allowRawInjectionDespiteWrapping这个值默认是false
// hasDependentBean：若它有依赖的bean 那就需要继续校验了~~~(若没有依赖的 就放过它~)
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
// 拿到它所依赖的Bean们~~~~ 下面会遍历一个一个的去看~~
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
// 一个个检查它所以Bean
// removeSingletonIfCreatedForTypeCheckOnly这个放见下面 在AbstractBeanFactory里面
// 简单的说，它如果判断到该dependentBean并没有在创建中的了的情况下,那就把它从所有缓存中移除~~~ 并且返回true
// 否则（比如确实在创建中） 那就返回false 进入我们的if里面~ 表示所谓的真正依赖
//（解释：就是真的需要依赖它先实例化，才能实例化自己的依赖）
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
// 若存在真正依赖，那就报错（不要等到内存移除你才报错，那是非常不友好的）
// 这个异常是BeanCurrentlyInCreationException，报错日志也稍微留意一下，方便定位错误~~~~
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
return exposedObject;
}
// 虽然是remove方法 但是它的返回值也非常重要
// 该方法唯一调用的地方就是循环依赖的最后检查处~~~~~
protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {
// 如果这个bean不在创建中 比如是ForTypeCheckOnly的 那就移除掉
if (!this.alreadyCreated.contains(beanName)) {
removeSingleton(beanName);
return true;
}
else {
return false;
}
}
}
这里举例：例如是field属性依赖注入，在populateBean时它就会先去完成它所依赖注入的那个bean的实例化、初始化过程，最终返回到本流程继续处理，因此Spring这样处理是不存在任何问题的。
这里有个小细节：
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
这一句如果exposedObject == bean表示最终返回的对象就是原始对象，说明在populateBean和initializeBean没对他代理过，那就啥话都不说了exposedObject = earlySingletonReference，最终把二级缓存里的引用返回即可~
4.4 流程总结
此处以如上的A、B类的互相依赖注入为例，在这里表达出关键代码的走势：
4.4.1 入口处即是实例化、初始化A这个单例Bean。AbstractBeanFactory.doGetBean(“a”)
protected <T> T doGetBean(...){
...
// 标记beanName a是已经创建过至少一次的~~~ 它会一直存留在缓存里不会被移除（除非抛出了异常）
// 参见缓存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
// 此时a不存在任何一级缓存中，且不是在创建中 所以此处返回null
// 此处若不为null，然后从缓存里拿就可以了(主要处理FactoryBean和BeanFactory情况吧)
Object beanInstance = getSingleton(beanName, false);
...
// 这个getSingleton方法非常关键。
//1、标注a正在创建中~
//2、调用singletonObject = singletonFactory.getObject();（实际上调用的是createBean()方法） 因此这一步最为关键
//3、此时实例已经创建完成 会把a移除整整创建的缓存中
//4、执行addSingleton()添加进去。（备注：注册bean的接口方法为registerSingleton，它依赖于addSingleton方法）
sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
}
4.4.2 下面进入到最为复杂的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()环节，创建A的实例
protected Object doCreateBean(){
...
// 使用构造器/工厂方法 instanceWrapper是一个BeanWrapper
instanceWrapper = createBeanInstance(beanName, mbd, args);
// 此处bean为"原始Bean" 也就是这里的A实例对象：A@1234
final Object bean = instanceWrapper.getWrappedInstance();
...
// 是否要提前暴露（允许循环依赖） 现在此处A是被允许的
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
// 允许暴露，就把A绑定在ObjectFactory上，注册到三级缓存`singletonFactories`里面去保存着
// Tips:这里后置处理器的getEarlyBeanReference方法会被促发，自动代理创建器在此处创建代理对象（注意执行时机 为执行三级缓存的时候）
if (earlySingletonExposure) {
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
...
// exposedObject 为最终返回的对象，此处为原始对象bean也就是A@1234,下面会有用处
Object exposedObject = bean;
// 给A@1234属性完成赋值，@Autowired在此处起作用~
// 因此此处会调用getBean("b")，so 会重复上面步骤创建B类的实例
// 此处我们假设B已经创建好了 为B@5678
// 需要注意的是在populateBean("b")的时候依赖有beanA，所以此时候调用getBean("a")最终会调用getSingleton("a")，
//此时候上面说到的getEarlyBeanReference方法就会被执行。这也解释为何我们@Autowired是个代理对象，而不是普通对象的根本原因
populateBean(beanName, mbd, instanceWrapper);
// 实例化。这里会执行后置处理器BeanPostProcessor的两个方法
// 此处注意：postProcessAfterInitialization()是有可能返回一个代理对象的，这样exposedObject 就不再是原始对象了 特备注意哦~~~
// 比如处理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在这个时间里生成代理对象的（有坑，请小心使用@Aysnc）
exposedObject = initializeBean(beanName, exposedObject, mbd);
... // 至此，相当于A@1234已经实例化完成、初始化完成（属性也全部赋值了~）
// 这一步我把它理解为校验：校验：校验是否有循环引用问题~~~~~
if (earlySingletonExposure) {
// 注意此处第二个参数传的false，表示不去三级缓存里singletonFactories再去调用一次getObject()方法了~~~
// 上面建讲到了由于B在初始化的时候，会触发A的ObjectFactory.getObject() 所以a此处已经在二级缓存earlySingletonObjects里了
// 因此此处返回A的实例：A@1234
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 这个等式表示，exposedObject若没有再被代理过，这里就是相等的
// 显然此处我们的a对象的exposedObject它是没有被代理过的 所以if会进去~
// 这种情况至此，就全部结束了~~~
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
// 继续以A为例，比如方法标注了@Aysnc注解，exposedObject此时候就是一个代理对象，因此就会进到这里来
//hasDependentBean(beanName)是肯定为true，因为getDependentBeans(beanName)得到的是["b"]这个依赖
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
// A@1234依赖的是["b"]，所以此处去检查b
// 如果最终存在实际依赖的bean：actualDependentBeans不为空 那就抛出异常 证明循环引用了~
for (String dependentBean : dependentBeans) {
// 这个判断原则是：如果此时候b并还没有创建好，this.alreadyCreated.contains(beanName)=true表示此bean已经被创建过，就返回false
// 若该bean没有在alreadyCreated缓存里，就是说没被创建过(其实只有CreatedForTypeCheckOnly才会是此仓库)
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
}
由于关键代码部分的步骤不太好拆分，为了更具象表达，那么使用下面一副图示帮助小伙伴们理解：
五、面试金手指
面试金手指1：什么是循环依赖？Spring中三种循环依赖？
答案就是第二部分和3.2，直接背下来就好
面试金手指2：Spring底层如何使用三级缓存处理循环依赖问题？
面试不会让你一行行搞懂源码，但是要说明整个意思
第一，先上代码，单例模式下的属性注入制造循环依赖
@Service
public class AServiceImpl implements AService {
@Autowired
private BService bService;
...
}
@Service
public class BServiceImpl implements BService {
@Autowired
private AService aService;
...
}
第二，执行图
第三，解释整个流程
Spring中Bean创建的过程，首先Spring会尝试从缓存中获取，这个缓存就是指singletonObjects，主要调用的方法是：
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);}
首先解释两个参数：
（1）isSingletonCurrentlyInCreation 判断对应的单例对象是否在创建中，当单例对象没有被初始化完全(例如A定义的构造函数依赖了B对象，得先去创建B对象，或者在populatebean过程中依赖了B对象，得先去创建B对象，此时A处于创建中)；
（2）allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象。
分析getSingleton的整个过程，Spring首先从singletonObjects（一级缓存）中尝试获取，如果获取不到并且对象在创建中，则尝试从earlySingletonObjects(二级缓存)中获取，如果还是获取不到并且允许从singletonFactories通过getObject获取，则通过singletonFactory.getObject()(三级缓存)获取。如果获取到了则
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
则移除对应的singletonFactory,将singletonObject放入到earlySingletonObjects，其实就是将三级缓存提升到二级缓存中！
Spring解决循环依赖的诀窍就在于singletonFactories这个cache，这个cache中存的是类型为ObjectFactory，其定义如下：
public interface ObjectFactory<T> {
T getObject() throws BeansException;
}
在bean创建过程中，有两处比较重要的匿名内部类实现了该接口。一处是
new ObjectFactory<Object>() {
@Override public Object getObject() throws BeansException {
try {
return createBean(beanName, mbd, args);
} catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
}
在上文已经提到，Spring利用其创建bean（这样做真的很不明确呀…）
另一处就是:
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}});
此处就是解决循环依赖的关键，这段代码发生在createBeanInstance之后，也就是说单例对象此时已经被创建出来的。这个对象已经被生产出来了，虽然还不完美（还没有进行初始化的第二步和第三步），但是已经能被人认出来了（根据对象引用能定位到堆中的对象），所以Spring此时将这个对象提前曝光出来让大家认识，让大家使用。
这样做有什么好处呢？让我们来分析一下“A的某个field或者setter依赖了B的实例对象，同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步，并且将自己提前曝光到singletonFactories中，此时进行初始化的第二步，发现自己依赖对象B，此时就尝试去get(B)，发现B还没有被create，所以走create流程，B在初始化第一步的时候发现自己依赖了对象A，于是尝试get(A)，尝试一级缓存singletonObjects(肯定没有，因为A还没初始化完全)，尝试二级缓存earlySingletonObjects（也没有），尝试三级缓存singletonFactories，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全，但是总比没有好呀)，B拿到A对象后顺利完成了初始化阶段1、2、3，完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中，A此时能拿到B的对象顺利完成自己的初始化阶段2、3，最终A也完成了初始化，长大成人，进去了一级缓存singletonObjects中，而且更加幸运的是，由于B拿到了A的对象引用，所以B现在hold住的A对象也蜕变完美了！一切都是这么神奇！！
面试金手指3：附加问题：为什么构造函数不可以？为什么单例模式属性注入可以？为什么原型模式属性注入不可以？
第一个，为什么构造函数不可以？（与单例模式属性注入对比）
Spring容器会将每一个正在创建的Bean标识符放在一个“当前创建Bean池”中，Bean标识符在创建过程中将一直保持在这个池中。
因此如果在创建Bean过程中发现自己已经在“当前创建Bean池”里时将抛出BeanCurrentlyInCreationException异常表示循环依赖；而对于创建完毕的Bean将从“当前创建Bean池”中清除掉。
根据上述源码实现分析：Spring容器先创建单例StudentA，StudentA依赖StudentB，然后将A放在“当前创建Bean池”中，此时创建StudentB, StudentB依赖StudentC ,然后将B放在“当前创建Bean池”中,此时创建StudentC，StudentC又依赖StudentA， 但是，此时StudentA已经在池中，所以会报错，因为在池中的Bean都是未初始化完的，所以会依赖错误 ，（初始化完的Bean会从池中移除）
**根本原因-无法构造一种实例化而未被初始化的中间态：
单例模式下的属性注入是使用singletonFactories来完成，这个singletonFactories解决循环依赖依靠的是Bean的“中间态”这个概念，这个中间态指的是已经实例化，但还没初始化的状态。
单例模式中的这种中间态是调用无参构造函数得到的，带参构造器是直接初始化的，直接使用带参构造函数，无法构造这种已被实例化未被初始化的状态，所以构造器的循环依赖没法解决。
**
第二个，为什么单例模式属性注入可以？
如图中前两步骤得知：Spring是先将Bean对象实例化之后再设置对象属性的
Spring先是用构造实例化Bean对象（无参构造函数），此时Spring会将这个实例化结束的对象放到一个Map中，并且Spring提供了获取这个未设置属性的实例化对象引用的方法。
第三个，为什么原型模式属性注入不可以？（与单例模式对比）
原型模式中，scope=“prototype” 意思是 每次请求都会创建一个实例对象。
原型模式和单例模式两者的区别是：有状态的bean都使用Prototype作用域，无状态的一般都使用singleton单例作用域。
对于“prototype”作用域Bean，Spring容器无法完成依赖注入，因为“prototype”作用域的Bean，Spring容器不进行缓存（Spring的三级缓存不保存非单例模式的bean对象），因此无法提前暴露一个创建中的Bean。
一句话解释，因为Spring bean初始化的循环依赖只能解决单例模式的set方式（依赖第三级缓存提前暴露无参构造函数new出的对象），Spring的三级缓存不保存非单例模式的bean对象，所以scope="prototype"时，无法处理循环依赖问题。
一句话解释：
为什么单例模式可以？源码解释：面试金手指2，第三，解释整个过程。
为什么构造函数不可以？源码解释：无法构造一种实例化而未被初始化的中间态：
单例模式下的属性注入是使用singletonFactories来完成，这个singletonFactories解决循环依赖依靠的是Bean的“中间态”这个概念，这个中间态指的是已经实例化，但还没初始化的状态。单例模式中的这种中间态是调用无参构造函数得到的，带参构造器是直接初始化的，直接使用带参构造函数，无法构造这种已被实例化未被初始化的状态，所以构造器的循环依赖没法解决。
为什么原型模式属性注入不可以？源码解释：Spring的三级缓存不保存非单例模式的bean对象
六、小结
Spring底层如何使用三级缓存处理循环依赖问题？完成
天天打码，天天进步！！！