前言
所谓的三级缓存只是三个可以当作是全局变量的Map，Spring的源码中大量使用了这种先将数据放入容器中等使用结束再销毁的代码风格
Spring的初始化过程大致有四步：
- 创建beanFactory，加载配置文件
- 解析配置文件转化beanDefination，获取到bean的所有属性、依赖及初始化用到的各类处理器等
- 刷新beanFactory容器，初始化所有单例bean
- 注册所有的单例bean并返回可用的容器
我们说的循环依赖就是第四步在给Bean属性注入的时候发生的一个问题
1什么是循环依赖
循环依赖就是：
假设有两个类 A和B，A中需要注入B，B中需要注入A
由于A注入B时B没有创建，B创建时A也无法创建导致的死循环问题
2 如何解决循环依赖
我们都知道AOP是Spring的一个重要核心思想，其实现就是根据动态代理来实现的，也就是说我们的Bean其实很大概率都是要生成代理类，让我们先来看无代理的情况：
Bean的初始化大概是这样的：
根据以上步骤可以看出bean初始化是一个相当复杂的过程，假如初始化A bean时，发现A bean依赖B bean,即A初始化执行到了第4步填充属性，需要注入B bean，此时B还没有初始化，则需要暂停A，先去初始化B，那么此时new出来的A对象放哪里，直接放在容器Map里显然不合适，半残品怎么能用，所以需要提供一个可以标记创建中bean(A)的Map，可以提前暴露正在创建的bean供其他bean依赖，而如果初始化A所依赖的bean B时，发现B也需要注入一个A的依赖(即发生循环依赖)，则B可以从创建中的beanMap中直接获取A对象（创建中）注入A，然后完成B的初始化，返回给正在注入属性的A，最终A也完成初始化，皆大欢喜。
如果没有循环依赖，A 依赖B，就是创建B，B依赖C就去创建C，创建完了逐级返回就行，并不需要什么缓存，所以，一级缓存之后的其他缓存(二三级缓存)就是为了解决循环依赖而设立的
一级缓存其实就是我们的成熟的Bean了，可以直接被使用
我们去看一下源码：
从源码中我们可以看到，三级缓存里放的并不是实例化的Bean，而是一个工厂，这是为什么呢？
循环依赖在实际应用可能会有，但很少，简单的应用场景是： controller注入service，service注入mapper，只有复杂的业务，可能service互相引用，有可能出现循环依赖，所以为了出现循环依赖才去解决，不出现就不解决，虽然支持循环依赖，但是只有在出现循环依赖时才真正暴露早期对象，否则只暴露个获取bean的方法，并没有真正暴露bean，因为这个方法不会被执行到，这块的实现就是三级缓存（singletonFactories），只缓存了一个单例bean工厂。
为什么是一个工厂？或者说这个工厂的作用？
三级缓存bean工厂的getObject方式，实际执行的是getEarlyBeanReference，如果对象需要被代理(存在beanPostProcessors -> SmartInstantiationAwareBeanPostProcessor)，则提前生成代理对象。
三级缓存已经解决所有问题了，二级缓存用来做什么呢？为什么三级缓存不直接叫做二级缓存?这个应该是在缓存使用时决定的：
此时这个方法中的判断逻辑是：
- 一级缓存中没有
- 对象A确实正在创建中
- 二级缓存中也没有
- 最终去三级缓存中获取对象,从三级缓存获取后把对象从三级缓存删除然后放入到二级缓存中，由于当初放入到三级缓存中的是一个工厂，所以从三级缓存中拿对象是调用getEarlyBeanReference这个方法获取，这个方法的作用是如果对象需要代理，那么就返回代理类，如果不需要代理就返回原生类，至此属性注入A完成
那么为什么要把对象从三级缓存放到二级缓存呢？
给大家一个循环依赖的流程图，大家一看便知：
看到了吗，如果AB都需要代理，我们在A的属性注入时创建了B，但是此时A还是原生的A，但是我们需要代理A，而代理A在B注入A时已经创建并放入二级缓存中了，我们直接从二级缓存拿然后替换原生A即可。
所以，我理解的是二级缓存是为了应对代理这个情况而生的
至此，循环依赖的问题已经完美解决
3无法解决的循环依赖
构造函数循环依赖：
如果我们的成员属性是在构造函数里呢？
首先要解决循环依赖就是要先实例化，然后放入三级缓存暴露出来，那么如果是构造函数这一步循环依赖，
实例化的时候就会产生无限递归创建，所以不能解决
多例的循环依赖：
如果是多例的，在容器初始化的时候，不会去创建，所以早期没有放入到三级缓存中暴露出来，所以无法解决循环依赖，会报错
到此这篇关于Spring解决循环依赖问题及三级缓存的作用的文章就介绍到这了,更多相关Spring解决循环依赖问题内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax！