getBean流程介绍(以单例的Bean流程为准)
getBean(beanName)
从BeanFactory中获取Bean的实例对象，真正获取的逻辑由doGetBean实现。
doGetBean(beanName, requiredType, args, typeCheckOnly)
获取Bean实例的逻辑。
1 transformedBeanName(beanName)——处理Bean的名字
transformedBeanName()对BeanName做一层转换，这层转换主要设计两方面的处理，一是对BeanFactory的Name做一些处理(通常FactoryBean前面会增加一个&符号用来和BeanName区分，例如假设一个FactoryBean的name为&myFactoryBean,那么我们它创建的bean的name就为myFactoryBean)，另一个是针对别名的处理。
2 getSingleton(beanName, allowEarlyReferrence)——从三级缓存中搜索
getSingletion()方法会先检查BeanFactory.singletionObjects是否已经存在这个Bean的单例。
singletionObjects是BeanFactory内部的一个Map，存放已经是初始化完成的bean对象，其中key存放的是beanName，而value存放的是Bean实例。
如果singletionObjects中不存在但是该Bean是否正在创建中，则会尝试从earlySingletionObjects中获取。earlySingletionObjects也是一个map，存放的是已经创建出对象，但是还未设置属性的bean。
如果在earlySingletonObjects中依旧找不到Bean对象，那么要继续考虑通过ObjectFactory创建Bean对象的情况。
这里就引出了Spring中关于解决循环依赖问题的三级缓存。关于循环依赖的处理我们最后再分析。
/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
/** Cache of early singleton objects: bean name --> bean instance */
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
3 getParentBeanFactory().getBean()——从父容器中获取Bean
我们知道HierarchicalBeanFactory提供了BeanFactory父子容器的关系。子容器可以获取父容器中的Bean。
当我们从子容器中的三级缓存中获取不到Bean，且找不到该Bean的定义时，Spring会转而去父容器中查找，如果父容器中依旧没能找到，则说明该Bean不存在。如果父容器中存在，则从父容器中获得Bean。
4 markBeanAsCreated(beanName)
这步只是对这个BeanName做个标记，表示这个BeanName对应的Bean已经被创建或是正在被创建。
5 getMergedLocalBeanDefinition(beanName)
BeanDefinition是Spring中对Bean的定义和描述，其中难免会有很多属性和配置。在早起的xml时代，这些配置都需要人员编码，因此Spring对BeanDefition做了一种继承的机制，可以定义一个父定义，然后子类通过继承获得父定义中的属性（当然也支持覆盖父定义中的属性）。有点类似先定义一个宏。
而这个方法就是将父子BeanDefition整合一下，得到一个MergedBeanDefition。
6 getDependsOn()——处理DependsOn
Bean可以通过DependsOn来显示控制Bean的初始化顺序(和依赖注入时的隐式初始化顺序略有不同，显示的DependsOn不用要求两个Bean之间存在引用关系)。
Spring会优先创建DependsOn指定的Bean，这一过程中，也可能存在"循环依赖"的问题，但是这种情况下的"循环依赖"问题Spring是无法内部自己解决的（因为通常使用DependsOn，就是想强制让否个Bean优先启动）。
7 getSingleton(beanName, ObjectFactory)——获取Bean实例
这是对getSingleton方法的重载，前文版本中的getSingleton方法只会从三级缓存中搜索Bean的实例，而这个重载方法会真正去创建Bean的实例。
在真正实例化对象前，依旧会先从singletonObjects检查一次对象是否已经被创建，如果没有，方法就上锁，并进入实例化对象的流程。
7.1 beforeSingletonCreation(beanName)——创建前的处理
这步通常是做一些校验，并把该Bean标记成正在创建。
7.2 singletonFactory.getObject()——通过ObjectFactory创建对象
具体的对象创建过程会调用AbstractAutoWireCapableBeanFactory.createBean(beanName, beanDefinition, args)方法。
7.2.1 resolvedClass()——解析bean类型
这步主要针对bean类型做解析。
7.2.2 preparedMethodOverrides()——overrideMethod的处理
这里的overrideMthod主要是针对bean中的look-up和replace等配置。有兴趣的读者可以自己展开了解。
7.2.3 resolveBeforeInstantiation()——在真正创建bean前，给用户一次控制bean创建的过程
用户可以通过InstantiationAwarePostProcessor.postProcessBeforeInstantiation(beanClass, beanName)方法先行创建出Bean对象。
InstantiationAwarePostProcessor接口继承自BeanPostProcessor，主要是针对Bean的实例化前后阶段设置了回调。
如果在这步中返回了Bean的实例，那么Spring不会再执行默认的创建策略。
这步留给用户的拓展还是比较有用的，用户可以根据该特性为某个Bean设置代理。
7.2.4 doCreateBean(beanName, mbd, args)——创建bean的过程
Bean的创建过程可以分成两个步骤：
1).实例化Bean的对象
2).针对Bean实例做初始化
7.2.4.1 createBeanInstance()——创建bean实例
这个方法主要是对Bean实例的创建，创建方式顺序是BeanDefition的Supplier>BeanDefinition的FactoryMethod>构造器反射创建。
7.2.4.2 applyMergedBeanDefinitionPostProcessors()
应用MergedBeanDefinitionPostProcessor,对MergedBeanDefinition做后处理。
7.2.4.3 addSingletonFactory(beanName, ObjectFactory)
将创建的Bean封装到ObjectFactory中，然后添加到singletonFactories中（三级缓存）。
这样在出现循环依赖的时候，可以从三级缓存中获取到这个Bean的引用，虽然此时这个Bean还未完全准备好。
7.2.4.4 poplulateBean(beanName, mdb, instanceWrapper)
填充Bean的属性。被创建出来的Bean对象会在这一步被设置属性。
Spring会根据Bean的AutoWireType进行属性的装配。
注意装配的过程中可能发生循环依赖。
7.2.4.5 initializeBean(beanName, exposedObject, mdb)——调用初始化方法
经过7.2.4.4 其实Bean对象已经创建的差不多了，之所以还需要在进行初始化是因为一些Bean可能指定了init方法，做一些特殊的初始化动作。这一步就是为了能够执行这些逻辑。
7.2.4.6 registerDisposableBeanIfNecessary()
为Bean注册销毁时的回调。
7.3 afterSingletonCreation(beanName)——创建后的处理
同样是做一些校验，并且将bean从正在创建的状态中移除。
7.4 addSingleton()——添加单例
这一步Spring会将创建好的Bean添加到singletonObjects中(一级缓存，用来存放已经创建好的bean)，并从earlySingletonObjects和singletonFactories(二级缓存和三级缓存)中移除这个bean的引用。
8 校验类型
在getSingleton()执行完成之后，已经得到了bean的对象，这一步主要是针对Bean类型校验，看是否得到的实例是否是期望的类型，如果不是就对类型进行转换。
转换失败，则抛出异常。
9 返回bean
将得到的Bean返回给调用者。完成获取Bean的过程。
通过流程图加深印象：
循环依赖
什么是循环依赖
循环依赖是Spring容器在初始化Bean时，发现两个Bean互相依赖的一种特殊情况。
假设这么一种情况:
ComponentA和ComponentB为同一容器中的两个bean，且他们装配时都需要装配对方的引用：
@Component
public class ComponentA {
@Autowired
ComponentB b;
}
@Component
public class ComponentB {
@Autowired
ComponentA a;
}
那么在创建ComponentA时，发现需要装配ComponentB，转而去创建ComponentB时,又发现需要装配ComponentA。
那么是否会引起Spring创建Bean失败呢？Spring是如何解决这种问题的？
Spring解决循环依赖的方式
为了解决这种问题，Spring引入了三级缓存，分别存放不同时期的Bean引用。
singletonObjects：一级缓存用来存放完全初始化完成的Bean。
earlySingletonObjects：二级缓存用来存放实例化，但初始化完成的Bean。
sngletonFactories:三级缓存用来存放ObjectFactory,ObjectFactory通常会持有已经实例化完成的Bean引用，并在getObject()时可能加工一下Bean，并返回Bean引用。
回到之前的问题:
- Spring在创建
ComponentA时，先实例化了ComponentA，并通过ObjectFactory持有着ComponentA的引用。在singletonFactories中(第三级缓存)添加缓存。 - 然后开始装配
ComponentA，发现需要依赖ComponentB,由于ComponentB在三级缓存中都找不到，于是转而开始创建ComponentB。 - 同样实例化了
ComponentB,并在singletonFactories中添加缓存。 - 开始对
ComponentB进行装配，发现又需要ComponentA,Spring第二次去getBean(ComponentA) - 这次由于第三级缓存中已经存在了
ComponentA的缓存，因此能够取到ComponentA实例的引用。同时，由于此次的获取，三级缓存的关系也发生了变化，第三级缓存singletonFacotries移除了关于ComponentA的引用，而是第二级缓存earlySingletonObjects会放入ComponentA的引用（因为此时已经通过ObjectFactory获取过ComponentA的实例了）。 ComponentB得到了ComponentA的引用，完成了装配。被添加到第一级缓存singletonObjects中，表示已经初始化完成，可以供其他Bean使用。- 回到第一个
getBean(ComponentA)的地方，因为已经能够得到ComponentB的引用了，所以ComponentA也能被正常初始化完成。于是也被添加进了第一级缓存singletonObejcts中。
通过一个流程图帮助读者加深下印象：
无法解决的循环依赖的情形
上述循环依赖的情况是两个Bean在通过属性注入时产生的，而针对构造器注入的循环依赖Spring是无法解决的。
原因很简单，Spring之所以能解决循环依赖是因为它将Bean的创建过程分成了实例化和初始化两个阶段。实例化完成后Spring就通过三级缓存允许其他Bean先获取到该Bean的缓存。
而针对构造函数注入产生的循环依赖而言，由于在创建阶段就依赖了其他Bean，因此无法先创建实例供其他Bean引用。
疑惑
最后抛出一个问题：为什么解决循环依赖需要三级缓存的设计，个人认为二级缓存也能够解决循环依赖的问题，能否把第二级缓存和第三级缓存合并成一级？
希望有了解的同学可以帮我答疑解惑。