前言
循环依赖：就是N个类循环(嵌套)引用。 通俗的讲就是N个Bean互相引用对方，最终形成闭环。用一副经典的图示可以表示成这样（A、B、C都代表对象，虚线代表引用关系）：
注意：其实可以N=1，也就是极限情况的循环依赖：
自己依赖自己另需注意：这里指的循环引用不是方法之间的循环调用，而是对象的相互依赖关系。（方法之间循环调用若有出口也是能够正常work的）
可以设想一下这个场景：如果在日常开发中我们用new对象的方式，若构造函数之间发生这种循环依赖的话，程序会在运行时一直循环调用最终导致内存溢出，示例代码如下：
public class Main { public static void main(String[] args) throws Exception { System.out.println(new A()); } } class A { public A() { new B(); } } class B { public B() { new A(); } }
运行报错：
Exception in thread "main" java.lang.StackOverflowError
这是一个典型的循环依赖问题。本文说一下Spring是如果巧妙的解决平时我们会遇到的三大循环依赖问题的~
Spring Bean的循环依赖
谈到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已经完美的帮我们解决和规避了问题。所以即使平时我们这样循环引用，也能够整成进行我们的coding之旅~
Spring中三大循环依赖场景演示
在Spring环境中，因为我们的Bean的实例化、初始化都是交给了容器，因此它的循环依赖主要表现为下面三种场景。为了方便演示，我准备了如下两个类：
1、构造器注入循环依赖
@Service
public class A { public A(B b) { } } @Service public class B { public B(A a) { } }
结果：项目启动失败抛出异常BeanCurrentlyInCreationException
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference? at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:339) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:215) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
构造器注入构成的循环依赖，此种循环依赖方式是无法解决的，只能抛出
BeanCurrentlyInCreationException异常表示循环依赖。这也是构造器注入的最大劣势（它有很多独特的优势，请小伙伴自行发掘）
根本原因：Spring解决循环依赖依靠的是Bean的“中间态”这个概念，而这个中间态指的是已经实例化，但还没初始化的状态。而构造器是完成实例化的东东，所以构造器的循环依赖无法解决~~~
2、field属性注入（setter方法注入）循环依赖
这种方式是我们最最最最为常用的依赖注入方式（所以猜都能猜到它肯定不会有问题啦）：
@Service
public class A { @Autowired private B b; } @Service public class B { @Autowired private A a; }
结果：项目启动成功，能够正常work
备注：setter方法注入方式因为原理和字段注入方式类似，此处不多加演示
2、prototype field属性注入循环依赖
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; }
结果：需要注意的是本例中启动时是不会报错的（因为非单例Bean默认不会初始化，而是使用时才会初始化），所以很简单咱们只需要手动getBean()或者在一个单例Bean内@Autowired一下它即可
// 在单例Bean内注入
@Autowired
private A a;
这样子启动就报错：
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mytest.TestSpringBean': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'b': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference? at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:596) at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90) at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:374)
如何解决？？？ 可能有的小伙伴看到网上有说使用@Lazy注解解决：
@Lazy
@Autowired
private A a;
此处负责任的告诉你这样是解决不了问题的(可能会掩盖问题)，@Lazy只是延迟初始化而已，当你真正使用到它（初始化）的时候，依旧会报如上异常。
对于Spring循环依赖的情况总结如下：
- 不能解决的情况： 1. 构造器注入循环依赖 2.
prototypefield属性注入循环依赖 - 能解决的情况： 1. field属性注入（setter方法注入）循环依赖
Spring解决循环依赖的原理分析
在这之前需要明白java中所谓的引用传递和值传递的区别。
说明：看到这句话可能有小伙伴就想喷我了。java中明明都是传递啊，这是我初学java时背了100遍的面试题，怎么可能有错？？？ 这就是我做这个申明的必要性：伙计，你的说法是正确的，
java中只有值传递。但是本文借用引用传递来辅助讲解，希望小伙伴明白我想表达的意思~
Spring的循环依赖的理论依据基于Java的引用传递，当获得对象的引用时，对象的属性是可以延后设置的。（但是构造器必须是在获取引用之前，毕竟你的引用是靠构造器给你生成的，儿子能先于爹出生？哈哈）
Spring创建Bean的流程
首先需要了解是Spring它创建Bean的流程，我把它的大致调用栈绘图如下：
对Bean的创建最为核心三个方法解释如下：
createBeanInstance：例化，其实也就是调用对象的构造方法实例化对象populateBean：填充属性，这一步主要是对bean的依赖属性进行注入(@Autowired)initializeBean：回到一些形如initMethod、InitializingBean等方法
从对单例Bean的初始化可以看出，循环依赖主要发生在第二步（populateBean），也就是field属性注入的处理。
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)); }
注：AbstractBeanFactory继承自DefaultSingletonBeanRegistry~
singletonObjects：用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用earlySingletonObjects：提前曝光的单例对象的cache，存放原始的 bean 对象（尚未填充属性），用于解决循环依赖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三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决
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的时候都会删除二级缓存里面对应的缓存值，是互斥的
源码解析
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