上一章，我们对 BeanDefinition 阶段的加载、解析、注册都有了一个清晰的了解和深入研究，本章我们要研究的，是在 bean 的初始化阶段，bean 的实例化过程。
本章主要会涉及到的原理部分：
好，下面我们进入源码分析。上一章我们说过了，**refresh** 方法承载了 ApplicationContext 的整体初始化动作，而这里面初始化 bean 的逻辑在第 11 步。不过在此之前，还有一个非常重要的部分，它就是 BeanPostProcessor 的注册动作，这两个动作在 refresh 方法中的位置如下：
复制 public void refresh() throws BeansException , IllegalStateException {
synchronized ( this . startupShutdownMonitor ) {
prepareRefresh() ;
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory() ;
prepareBeanFactory(beanFactory) ;
try {
postProcessBeanFactory(beanFactory) ;
invokeBeanFactoryPostProcessors(beanFactory) ;
// 6. 注册BeanPostProcessor
registerBeanPostProcessors(beanFactory) ;
initMessageSource() ;
initApplicationEventMulticaster() ;
onRefresh() ;
registerListeners() ;
// 11. 初始化剩余的单实例Bean
finishBeanFactoryInitialization(beanFactory) ;
finishRefresh() ;
}
// catch ......
finally {
resetCommonCaches() ;
}
}
} 下面我们先来解析 registerBeanPostProcessors 动作。
1. 注册BeanPostProcessor
复制 protected void registerBeanPostProcessors( ConfigurableListableBeanFactory beanFactory) {
PostProcessorRegistrationDelegate . registerBeanPostProcessors (beanFactory , this );
} 又是走了 PostProcessorRegistrationDelegate 的方法，那我们就跳转过去看看吧：
复制 public static void registerBeanPostProcessors(
ConfigurableListableBeanFactory beanFactory , AbstractApplicationContext applicationContext) {
String [] postProcessorNames = beanFactory . getBeanNamesForType ( BeanPostProcessor . class , true , false );
// Register BeanPostProcessorChecker that logs an info message when
// a bean is created during BeanPostProcessor instantiation, i.e. when
// a bean is not eligible for getting processed by all BeanPostProcessors.
// 1.1 此处会先注册一个BeanPostProcessorChecker
int beanProcessorTargetCount = beanFactory . getBeanPostProcessorCount () + 1 + postProcessorNames . length ;
beanFactory . addBeanPostProcessor ( new BeanPostProcessorChecker(beanFactory , beanProcessorTargetCount) );
// Separate between BeanPostProcessors that implement PriorityOrdered,
// Ordered, and the rest.
// 根据排序规则，给所有的后置处理器分类
List < BeanPostProcessor > priorityOrderedPostProcessors = new ArrayList <>();
List < BeanPostProcessor > internalPostProcessors = new ArrayList <>();
List < String > orderedPostProcessorNames = new ArrayList <>();
List < String > nonOrderedPostProcessorNames = new ArrayList <>();
for ( String ppName : postProcessorNames) {
if ( beanFactory . isTypeMatch (ppName , PriorityOrdered . class )) {
// 1.2 注意此处，PriorityOrdered类型的后置处理器被提前初始化了
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
priorityOrderedPostProcessors . add (pp);
// MergedBeanDefinitionPostProcessor要额外筛出来
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
else if ( beanFactory . isTypeMatch (ppName , Ordered . class )) {
orderedPostProcessorNames . add (ppName);
}
else {
nonOrderedPostProcessorNames . add (ppName);
}
}
// First, register the BeanPostProcessors that implement PriorityOrdered.
// 首先，注册所有实现了PriorityOrdered接口的后置处理器
sortPostProcessors(priorityOrderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , priorityOrderedPostProcessors) ;
// Next, register the BeanPostProcessors that implement Ordered.
// 其次，注册所有实现了Ordered接口的后置处理器
List < BeanPostProcessor > orderedPostProcessors = new ArrayList <>( orderedPostProcessorNames . size ());
for ( String ppName : orderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
orderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
sortPostProcessors(orderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , orderedPostProcessors) ;
// Now, register all regular BeanPostProcessors.
// 最后，注册所有普通的后置处理器
List < BeanPostProcessor > nonOrderedPostProcessors = new ArrayList <>( nonOrderedPostProcessorNames . size ());
for ( String ppName : nonOrderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
nonOrderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
registerBeanPostProcessors(beanFactory , nonOrderedPostProcessors) ;
// Finally, re-register all internal BeanPostProcessors.
// 1.3 注意此处，所有MergedBeanDefinitionPostProcessor又被注册了一次
sortPostProcessors(internalPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , internalPostProcessors) ;
// Re-register post-processor for detecting inner beans as ApplicationListeners,
// moving it to the end of the processor chain (for picking up proxies etc).
// 最后又注册了一个ApplicationListenerDetector（27章3.2节）
beanFactory . addBeanPostProcessor ( new ApplicationListenerDetector(applicationContext) );
} 来，理一下这个方法的整体逻辑脉络：首先它会先获取到 IOC 容器中已经有的 BeanPostProcessor 的 name ，获取到之后先不处理，先注册一个 **BeanPostProcessorChecker** ，然后才是处理那些 BeanPostProcessor 。处理 **BeanPostProcessor** 的过程跟 **BeanFactoryPostProcessor** 部分十分相似 ，不过对比起这三个逻辑处理，实现了 **PriorityOrdered** 接口的后置处理器似乎有 “特权” ，它们会在所有的 **BeanPostProcessor** 注册之前先初始化好 。当这三种后置处理器都注册完成后，它又将所有的 **MergedBeanDefinitionPostProcessor** 类型的后置处理器重新注册了一遍 ，最后又注册了一个 **ApplicationListenerDetector** 。
整个逻辑倒是清晰，但这里面的操作实在是很迷惑，这些经过设计的动作究竟是为何呢，下面咱一一解释。
1.1 BeanPostProcessorChecker
从类名上看，它是一个后置处理器的检查器 ，可它本身也是个后置处理器，那它检查个啥咧？咱先试着从 javadoc 中获取一点信息吧：
BeanPostProcessor that logs an info message when a bean is created during BeanPostProcessor instantiation, i.e. when a bean is not eligible for getting processed by all BeanPostProcessors.
它是一个 BeanPostProcessor ，当在 BeanPostProcessor 实例化期间创建 Bean 时，即当某个 Bean 不能被所有 BeanPostProcessor 处理时，它会记录一条信息。
原来如此，它的作用是检查 **BeanPostProcessor** 的初始化阶段中是否有 bean 的意外创建 。注意这个 “意外创建” ，其实它不意外，如果在 BeanPostProcessor 中有注入其它的普通 bean ，根据依赖注入的原则，会在 **BeanPostProcessor** 的创建之前，先把这些注入的普通 bean 先初始化出来 ，又因为当前阶段 **BeanPostProcessor** 还没有初始化完毕 ，这些普通 bean 还没有来得及被 **BeanPostProcessor** 处理 ，导致出现 bean 的 “残缺不全 ” 。BeanPostProcessorChecker 的作用，就是用来提醒我们开发者对该问题引起注意。
其实，如果有用过 Spring 的小伙伴，在开发时遇到这种日志：xxxxxx is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying) ，这就意味着你的 BeanPostProcessor 中有注入普通 bean 了，需要给代码作出调整。
从源码的角度上分析，注意看 PostProcessorRegistrationDelegate 的 registerBeanPostProcessors 方法中，它将所有的 BeanPostProcessor 都取出来，随后计算出了所有的 BeanPostProcessor 的数量是 beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length ，即所有的后置处理器数量 + 1 。
另外，在 BeanPostProcessorChecker 的 postProcessAfterInitialization 方法中，它会检查当前 BeanFactory 中的后置处理器数量是否少于一开始计算的预计后置处理器数量，如果少了，那就代表有 bean 被提前创建了。
复制 public Object postProcessAfterInitialization( Object bean , String beanName) {
// 此处判断是否有普通bean被提前创建
if ( ! (bean instanceof BeanPostProcessor) && ! isInfrastructureBean(beanName) &&
this . beanFactory . getBeanPostProcessorCount () < this . beanPostProcessorTargetCount ) {
if ( logger . isInfoEnabled ()) {
logger . info ( "Bean '" + beanName + "' of type [" + bean . getClass () . getName () +
"] is not eligible for getting processed by all BeanPostProcessors " +
"(for example: not eligible for auto-proxying)" );
}
}
return bean;
} 1.2 PriorityOrdered类型的后置处理器被提前创建的目的
我们仔细看一下这段代码的处理：
复制 List < BeanPostProcessor > priorityOrderedPostProcessors = new ArrayList <>();
List < BeanPostProcessor > internalPostProcessors = new ArrayList <>();
List < String > orderedPostProcessorNames = new ArrayList <>();
List < String > nonOrderedPostProcessorNames = new ArrayList <>();
for ( String ppName : postProcessorNames) {
if ( beanFactory . isTypeMatch (ppName , PriorityOrdered . class )) {
// 实现了PriorityOrdered接口的BeanPostProcessor被提前初始化了
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
priorityOrderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
else if ( beanFactory . isTypeMatch (ppName , Ordered . class )) {
orderedPostProcessorNames . add (ppName);
}
else {
nonOrderedPostProcessorNames . add (ppName);
}
}
sortPostProcessors(priorityOrderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , priorityOrderedPostProcessors) ;
List < BeanPostProcessor > orderedPostProcessors = new ArrayList <>( orderedPostProcessorNames . size ());
for ( String ppName : orderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
orderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
sortPostProcessors(orderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , orderedPostProcessors) ; 这段源码中很明显可以看懂，实现了 PriorityOrdered 接口的 BeanPostProcessor 被提前初始化了，这是为什么呢？
这里先不解释原因，我们先对这段源码做两次变式，看看如果修改逻辑之后会出现什么问题。
1.2.1 变式一：如果循环过程中顺便初始化
如果说先把后置处理器的全限定名都取出来，再实例化出来是多此一举，那每次循环的时候直接初始化出来不好吗？就像这样：
复制 for ( String ppName : postProcessorNames) {
if ( beanFactory . isTypeMatch (ppName , PriorityOrdered . class )) {
// 初始化实现了PriorityOrdered接口的后置处理器
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
priorityOrderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
else if ( beanFactory . isTypeMatch (ppName , Ordered . class )) {
// 初始化实现了Ordered接口的后置处理器
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
orderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
// else ......
} 这样会有什么问题呢？我们可以假想一个故事场景来演绎一下。
注：该故事仅为虚拟场景的情节演绎，小伙伴们切勿模仿该行为！！！！！！
现在有三个 “黑社会” 熊猫（代指三个后置处理器），他们仨常蹲在路口边上打劫收保护费，他们平常 “作案” 的流程是这样的：老大负责恐吓威胁路人，把路人吓唬住了就带到老二那边收保护费，如果路人不交保护费，则老三直接上去一个酒瓶子把路人抡倒，就像这样：
解释一下这个场景的一些要素哈：此处我们假定老大实现了 PriorityOrdered 接口，老二和老三实现了 Ordered 接口。按理讲，老大的出手时机一定比老二和老三早（ PriorityOrdered 接口的处理时机比 Ordered 早）。
老大威胁路人的行为在此处比作正常的 bean 初始化阶段的 postProcessBeforeInitialization 方法回调，老三拿酒瓶子抡路人的行为在此处比作 bean 初始化阶段的 postProcessAfterInitialization 方法回调。所以我们在这里虚拟的场景是这样：每个路人是一个普通的 bean ，在 bean 执行初始化阶段的回调之前会有 BeanPostProcessor 去拦截一下 bean 并作额外处理（也就是收路人的保护费）。
平常每天都是老大先找准了蹲点的地方，埋伏好了之后老二和老三就赶过来，就这样哥仨一直靠收路人的保护费混日子。不过这个场景在某天出现了意外，那天老三 喝多了，大清早的天还没亮就带着老二先出发了 ，随便找了一个点就埋伏好了，等路人经过就去收他钱。好巧不巧，这天老大就路过了老三所在的这个点 ，老三喝多了啊，连自己老大都不认识了，就去叫老二去收保护费，本来就是天还没亮就被老三叫起来，老二也睡眼惺忪的，就让他老大交钱。老大也懵了啊，我去不会这片地儿还有另一派黑恶势力？可是昨天我刚跟我那两个兄弟喝酒了啊，没钱了咋整。这就尴尬了，老二没看清是老大，就让老三上去收拾了，结果老三一个酒瓶子下去，把老大敲懵了。。。
好，故事到这里停一下，咱讲讲这个情节对应的代码实现。在这种意外场景下，由于老二和老三在所有 **BeanPostProcessor** 列表的前置位 ，导致它们（这两个实现了 Ordered 接口的后置处理器）先被读取。如果此时初始化后置处理器的代码逻辑是上面的变式，则上面的故事情景就会发生：老二和老三先注册到了 ApplicationContext 中，它们已经开始起作用了。之后即便再来老大（实现了 PriorityOrdered 接口的后置处理器）的时候，老二和老三把老大当普通路人看待了（即 被后置处理器处理了），于是就把老大揍了，导致结果出现意外（程序出现错误）。
所以到这里，小伙伴们是否理解了为什么不能在循环中顺便初始化 BeanPostProcessor 了吧，咱简单总结一下：
如果 **BeanPostProcessor** 的初始化逻辑是一边循环一边初始化，则可能会导致优先级低的 **BeanPostProcessor** 干预了优先级高的 **BeanPostProcessor** ，从而引发程序的运行情况异常。而正确的做法就是只初始化最高优先级的 **BeanPostProcessor** ，其余的都只是记录下全限定名，等所有最高优先级的 **BeanPostProcessor** 都初始化完成后，再依次初始化低优先级的 **BeanPostProcessor** （优先级低的 **BeanPostProcessor** 可能也需要被优先级高的 **BeanPostProcessor** 处理）。
1.2.2 变式二：如果循环过程中不初始化
既然不能一边循环一边初始化，那为什么不先循环完事了，再依次初始化呢，就像这样子：
复制 List < BeanPostProcessor > internalPostProcessors = new ArrayList <>();
List < String > priorityOrderedPostProcessorNames = new ArrayList <>();
List < String > orderedPostProcessorNames = new ArrayList <>();
List < String > nonOrderedPostProcessorNames = new ArrayList <>();
for ( String ppName : postProcessorNames) {
// 只循环，不初始化
if ( beanFactory . isTypeMatch (ppName , PriorityOrdered . class )) {
priorityOrderedPostProcessorNames . add (ppName);
}
else if ( beanFactory . isTypeMatch (ppName , Ordered . class )) {
orderedPostProcessorNames . add (ppName);
}
else {
nonOrderedPostProcessorNames . add (ppName);
}
}
// 此处再依次初始化实现了PriorityOrdered接口的BeanPostProcessor
List < BeanPostProcessor > priorityOrderedPostProcessors = new ArrayList <>();
for ( String ppName : priorityOrderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
priorityOrderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
sortPostProcessors(priorityOrderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , priorityOrderedPostProcessors) ;
// 初始化实现了Ordered接口的BeanPostProcessor
List < BeanPostProcessor > orderedPostProcessors = new ArrayList <>( orderedPostProcessorNames . size ());
for ( String ppName : orderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory . getBean (ppName , BeanPostProcessor . class );
orderedPostProcessors . add (pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors . add (pp);
}
}
sortPostProcessors(orderedPostProcessors , beanFactory) ;
registerBeanPostProcessors(beanFactory , orderedPostProcessors) ; 这样写有问题吗？当然没问题，但是我想请小伙伴们看一下这个过程中创建的 **List** 集合有几个 ，跟源代码的比较如何？
很明显，它多创建了一个 priorityOrderedPostProcessorNames 吧！但是增加这一个 List 后并没有给整体代码的时间复杂度带来有效降低，反而还增加了一轮循环（遍历 priorityOrderedPostProcessorNames 集合），所以 SpringFramework 的开发者将此处实现了 PriorityOrdered 接口的 BeanPostProcessor 提前初始化好了，这样不光节省了内存消耗（降低空间复杂度），还少了一轮循环（降低时间复杂度） 。由此我们不得不佩服这些写框架的大佬，他们对代码的优化实在是高！
1.2.3 PriorityOrdered接口到底都有啥
既然 SpringFramework 中要这么干，那看来 PriorityOrdered 这个接口是很重要且关键的吧！那问题就来了，这些实现了 PriorityOrdered 接口的后置处理器都是些干啥的呢？小册来随便列举两个，小伙伴们一看便知：
AutowiredAnnotationBeanPostProcessor —— 处理 @Autowired 注解
CommonAnnotationBeanPostProcessor —— 处理 JSR250 规范的注解
得，看来确实很关键了，如果这两个后置处理器不先初始化好的话，后面的东西就别想用咱平常用的 @Autowired 、@PostConstruct 等等的注解了。所以说这些实现了 PriorityOrdered 接口的组件通常都是些内置的核心组件 ，SpringFramework 为了保证功能的正常运转，就必须要让这些核心组件都正常到位才可以。
1.3 MergedBeanDefinitionPostProcessor被重复注册
在整个方法的接近最后部分，这里有一句很迷的代码：
复制 // Finally, re-register all internal BeanPostProcessors.
sortPostProcessors(internalPostProcessors, beanFactory);
// 重复注册了一次？？？
registerBeanPostProcessors(beanFactory, internalPostProcessors); 不是，这些后置处理器不是在前面初始化完成了，一起注册了吗？咋这里又重新注册一遍？不怕重复了吗？
哎，伙计，你都想到了，你觉得写框架的那些大佬会想不到吗？咱进入 registerBeanPostProcessors 方法中看一眼：
复制 private static void registerBeanPostProcessors(
ConfigurableListableBeanFactory beanFactory , List< BeanPostProcessor > postProcessors) {
for ( BeanPostProcessor postProcessor : postProcessors) {
beanFactory . addBeanPostProcessor (postProcessor);
}
}
public void addBeanPostProcessor( BeanPostProcessor beanPostProcessor) {
Assert . notNull (beanPostProcessor , "BeanPostProcessor must not be null" );
// Remove from old position, if any
// 如果后置处理器已经存在，则移除
this . beanPostProcessors . remove (beanPostProcessor);
// Track whether it is instantiation/destruction aware
if (beanPostProcessor instanceof InstantiationAwareBeanPostProcessor) {
this . hasInstantiationAwareBeanPostProcessors = true ;
}
if (beanPostProcessor instanceof DestructionAwareBeanPostProcessor) {
this . hasDestructionAwareBeanPostProcessors = true ;
}
// Add to end of list
// 添加至后置处理器列表的末尾
this . beanPostProcessors . add (beanPostProcessor);
} 喔原来如此，它是将这些 MergedBeanDefinitionPostProcessor 类型的后置处理器都放到了整个后置处理器列表的最后 了！仅此而已。
1.3.1 MergedBeanDefinitionPostProcessor后置的目的
还记得之前第 27 章中讲到的 MergedBeanDefinitionPostProcessor 应用吗？AutowiredAnnotationBeanPostProcessor 会根据 merge 后的 BeanDefinition ，给 bean 对象进行依赖注入。这个策略是 SpringFramework 内置的既定策略，过会在下面依赖注入的部分我们会讲到。
到这里，BeanPostProcessor 就初始化好了，下面就可以进入到 refresh 方法的第 11 步，finishBeanFactoryInitialization 方法中了，我们以测试代码中的 Cat 为例，来跟踪它的实例化过程。
2. finishBeanFactoryInitialization
整个方法中，唯一处理单实例 bean 初始化的动作是最后一行，其余的部分我们不关心：
复制 protected void finishBeanFactoryInitialization( ConfigurableListableBeanFactory beanFactory) {
// ......
// Instantiate all remaining (non-lazy-init) singletons.
beanFactory . preInstantiateSingletons ();
} 来到 DefaultListableBeanFactory 中，看看 preInstantiateSingletons 的实现：
复制 public void preInstantiateSingletons() throws BeansException {
// logger ......
List < String > beanNames = new ArrayList <>( this . beanDefinitionNames );
// Trigger initialization of all non-lazy singleton beans...
// 此处循环初始化剩余的非延迟加载的单实例bean
for ( String beanName : beanNames) {
// 先合并BeanDefinition
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName) ;
// 不是抽象的、不是延迟加载的单实例bean要初始化
if ( ! bd . isAbstract () && bd . isSingleton () && ! bd . isLazyInit ()) {
// FactoryBean默认不立即初始化，除非指定isEagerInit=true
if ( isFactoryBean(beanName) ) {
Object bean = getBean(FACTORY_BEAN_PREFIX + beanName) ;
if (bean instanceof FactoryBean) {
FactoryBean < ? > factory = ( FactoryBean<?> ) bean;
boolean isEagerInit;
if ( System . getSecurityManager () != null && factory instanceof SmartFactoryBean) {
isEagerInit = AccessController . doPrivileged (
( PrivilegedAction< Boolean > ) (( SmartFactoryBean<?> ) factory) :: isEagerInit ,
getAccessControlContext() );
}
else {
isEagerInit = (factory instanceof SmartFactoryBean &&
(( SmartFactoryBean<?> ) factory) . isEagerInit ());
}
if (isEagerInit) {
getBean(beanName) ;
}
}
}
else {
// 普通的初始化，就是getBean方法
getBean(beanName) ;
}
}
}
// 初始化的最后阶段 ......
} 纵观整段源码，可以发现处理思路还是蛮清晰的，这里面最最关键的初始化 bean 的动作，就是我们从一开始学习 SpringFramework 就用的 **getBean** 方法！！！
2.1 getBean → doGetBean
进入 getBean 方法，发现它直接调用了 doGetBean 方法：
复制 public Object getBean( String name) throws BeansException {
return doGetBean(name , null , null , false ) ;
}
protected < T > T doGetBean( String name , @ Nullable Class< T > requiredType , @ Nullable Object [] args , boolean typeCheckOnly)
throws BeansException {
// 处理bean的alias
String beanName = transformedBeanName(name) ;
Object bean;
// Eagerly check singleton cache for manually registered singletons.
// 循环依赖的探测（boot小册第15章专门有讲）
Object sharedInstance = getSingleton(beanName) ;
if (sharedInstance != null && args == null ) {
// logger ......
bean = getObjectForBeanInstance(sharedInstance , name , beanName , null ) ;
}
else {
// Fail if we're already creating this bean instance:
// We're assumably within a circular reference.
// 如果原型bean之间互相依赖，则一定会引发无限循环，此处会抛出循环依赖的异常
if ( isPrototypeCurrentlyInCreation(beanName) ) {
throw new BeanCurrentlyInCreationException(beanName) ;
}
// Check if bean definition exists in this factory.
// 如果本地不存在当前bean的定义信息，则尝试让父容器实例化bean
// 此举可以保证每个BeanFactory持有它应该有的bean，而不是所有的bean都集中在某一个BeanFactory中
BeanFactory parentBeanFactory = getParentBeanFactory() ;
if (parentBeanFactory != null && ! containsBeanDefinition(beanName) ) {
// Not found -> check parent.
String nameToLookup = originalBeanName(name) ;
if (parentBeanFactory instanceof AbstractBeanFactory) {
return ((AbstractBeanFactory) parentBeanFactory) . doGetBean (
nameToLookup , requiredType , args , typeCheckOnly);
}
// else if parentBeanFactory.getBean ......
}
// 标记当前bean已经开始被创建了
if ( ! typeCheckOnly) {
markBeanAsCreated(beanName) ;
}
try {
// 此处会合并BeanDefinition，并检查是否为抽象类(abstract则会抛出无法实例化的异常)
RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName) ;
checkMergedBeanDefinition(mbd , beanName , args) ;
// Guarantee initialization of beans that the current bean depends on.
// 此处会处理
String [] dependsOn = mbd . getDependsOn ();
if (dependsOn != null ) {
for ( String dep : dependsOn) {
// 循环依赖的检查：如果两个bean互相显式依赖，也会引发循环依赖的问题
if ( isDependent(beanName , dep) ) {
throw new BeanCreationException( mbd . getResourceDescription() , beanName ,
"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'" ) ;
}
registerDependentBean(dep , beanName) ;
try {
// 迫切初始化显式依赖的bean
getBean(dep) ;
} // catch ......
}
}
// Create bean instance.
// 单实例bean的初始化，最终调用createBean
if ( mbd . isSingleton ()) {
sharedInstance = getSingleton(beanName , () -> {
try {
return createBean(beanName , mbd , args);
} // catch ......
}) ;
bean = getObjectForBeanInstance(sharedInstance , name , beanName , mbd) ;
}
// 原型bean的初始化，直接调用createBean
else if ( mbd . isPrototype ()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null ;
try {
beforePrototypeCreation(beanName) ;
prototypeInstance = createBean(beanName , mbd , args) ;
}
finally {
afterPrototypeCreation(beanName) ;
}
bean = getObjectForBeanInstance(prototypeInstance , name , beanName , mbd) ;
}
// 处理自定义的scope ......
}
// catch ......
}
// 类型强转前的检查 ......
return (T) bean;
} 好长的源码是吧，这还是修剪过一部分的了。这部分前面的部分小伙伴们在现阶段只需要知道流程就好啊（感兴趣的可以深入看一看，但一定不要扎进去出不来了），对于 bean 的生命周期来讲，最重要的部分是中间的 getMergedLocalBeanDefinition 合并 BeanDefinition ，以及下面的 createBean 方法。下面我们分述这两个重要的方法。
2.1.1 getMergedLocalBeanDefinition
合并 BeanDefinition ，这是之前在第 25 章就了解过的知识了，这里我们简单看一下合并 BeanDefinition 的底层实现方式。
进入到 getMergedLocalBeanDefinition 方法中，发现它又是在折腾重载的方法，最终调用的是三参数的方法：
复制 protected RootBeanDefinition getMergedLocalBeanDefinition( String beanName) throws BeansException {
// Quick check on the concurrent map first, with minimal locking.
RootBeanDefinition mbd = this . mergedBeanDefinitions . get (beanName);
if (mbd != null && ! mbd . stale ) {
return mbd;
}
return getMergedBeanDefinition(beanName , getBeanDefinition(beanName)) ;
}
protected RootBeanDefinition getMergedBeanDefinition( String beanName , BeanDefinition bd)
throws BeanDefinitionStoreException {
return getMergedBeanDefinition(beanName , bd , null ) ;
} 这里的设计相当简单，只是在最上面的调用位置上做了一个缓存的获取动作（由此可见合并后的 BeanDefinition 也是会缓存在 BeanFactory 中的），接下来就是这个最复杂的的三参数重载的方法了：
复制 protected RootBeanDefinition getMergedBeanDefinition(
String beanName , BeanDefinition bd , @ Nullable BeanDefinition containingBd)
throws BeanDefinitionStoreException {
synchronized ( this . mergedBeanDefinitions ) {
RootBeanDefinition mbd = null ;
RootBeanDefinition previous = null ;
// Check with full lock now in order to enforce the same merged instance.
if (containingBd == null ) {
mbd = this . mergedBeanDefinitions . get (beanName);
}
if (mbd == null || mbd . stale ) {
previous = mbd;
// 此处会判断BeanDefinition是否没有父定义（即独立的GenericBeanDefinition或RootBeanDefinition）
if ( bd . getParentName () == null ) {
// Use copy of given root bean definition.
if (bd instanceof RootBeanDefinition) {
mbd = ((RootBeanDefinition) bd) . cloneBeanDefinition ();
} else {
mbd = new RootBeanDefinition(bd) ;
}
}
else {
// Child bean definition: needs to be merged with parent.
// 否则，此处需要合并BeanDefinition了
BeanDefinition pbd;
try {
String parentBeanName = transformedBeanName( bd . getParentName()) ;
if ( ! beanName . equals (parentBeanName)) {
pbd = getMergedBeanDefinition(parentBeanName) ;
}
else {
BeanFactory parent = getParentBeanFactory() ;
if (parent instanceof ConfigurableBeanFactory) {
// 此处会递归合并
pbd = ((ConfigurableBeanFactory) parent) . getMergedBeanDefinition (parentBeanName);
} // else throw ex ......
}
} // catch ......
// Deep copy with overridden values.
// 合并完成后，生成一个新的RootBeanDefinition
mbd = new RootBeanDefinition(pbd) ;
mbd . overrideFrom (bd);
}
// Set default singleton scope, if not configured before.
// 配置scope（如果自己和父定义都没有定义scope，则此处默认singleton）
if ( ! StringUtils . hasLength ( mbd . getScope ())) {
mbd . setScope (SCOPE_SINGLETON);
}
if (containingBd != null && ! containingBd . isSingleton () && mbd . isSingleton ()) {
mbd . setScope ( containingBd . getScope ());
}
if (containingBd == null && isCacheBeanMetadata() ) {
this . mergedBeanDefinitions . put (beanName , mbd);
}
}
if (previous != null ) {
copyRelevantMergedBeanDefinitionCaches(previous , mbd) ;
}
return mbd;
}
} 抓住里面的核心逻辑：它会自下而上递归 寻找父 BeanDefinition ，再从上到下合并 获得最终的 BeanDefinition 。这里面的合并细节，如果小伙伴们感兴趣，可以稍微看一下，小册不作过多深入了。
2.1.2 createBean的调用区别
这个 **createBean** 方法又是 bean 的实例化中巨重要的方法了，但此处没有把标题级别往上调，是想先让小伙伴有一个初步的感觉。注意看单实例 bean 跟原型 bean 对于 createBean 方法的调用方式：
复制 // Create bean instance.
if ( mbd . isSingleton ()) {
sharedInstance = getSingleton(beanName , () -> {
try {
return createBean(beanName , mbd , args);
} // catch ......
}) ;
bean = getObjectForBeanInstance(sharedInstance , name , beanName , mbd) ;
}
else if ( mbd . isPrototype ()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null ;
try {
beforePrototypeCreation(beanName) ;
prototypeInstance = createBean(beanName , mbd , args) ;
}
finally {
afterPrototypeCreation(beanName) ;
}
bean = getObjectForBeanInstance(prototypeInstance , name , beanName , mbd) ;
} 单实例 bean 的调用，是在 getSingleton 方法的 lambda 参数中调用的，而这个 lambda表达式的底层是一个 ObjectFactory 。小伙伴们可以先想一下，为什么单实例 bean 会有一个额外的操作，而原型 bean 不需要考虑那么多，直接 createBean 就好呢？
很简单，原型 bean 没有缓存的必要 ，每次获取必定会创建新的 bean 对象出来；而单实例 bean 只能创建一次 ，第二次再获取就需要从缓存中获取了，所以这里会多一步操作。
那么新的问题又来了：getSingleton 方法中都干了什么呢？那必然是要深入方法中看呀，来咱们点进去瞅瞅。
2.1.3 getSingleton
复制 public Object getSingleton( String beanName , ObjectFactory<?> singletonFactory) {
Assert . notNull (beanName , "Bean name must not be null" );
synchronized ( this . singletonObjects ) {
// 加锁后再查一次单实例bean的缓存
Object singletonObject = this . singletonObjects . get (beanName);
if (singletonObject == null ) {
if ( this . singletonsCurrentlyInDestruction ) {
// throw ex ......
}
// ......
try {
// 【createBean】如果单实例bean的缓存中真的没有，那就创建对象
singletonObject = singletonFactory . getObject ();
newSingleton = true ;
} // catch finally ......
// 新创建的单实例bean要存入单实例bean的缓存中
if (newSingleton) {
addSingleton(beanName , singletonObject) ;
}
}
return singletonObject;
}
} 其实这段源码一点也不神秘哈，无非就是加锁之后再判断一次单例（双检锁 的设计），如果没有，那就调用 ObjectFactory 的 getObject 方法，而这个 ObjectFactory 就是前面看到的 lambda 表达式。
所以由此就可以得知，无论怎样，只要是创建 bean ，一定会走 **createBean** 方法就对了。好，那下面我们就进入 createBean 方法中。
2.2 createBean
复制 protected Object createBean( String beanName , RootBeanDefinition mbd , @ Nullable Object [] args)
throws BeanCreationException {
// logger ......
RootBeanDefinition mbdToUse = mbd;
Class < ? > resolvedClass = resolveBeanClass(mbd , beanName) ;
if (resolvedClass != null && ! mbd . hasBeanClass () && mbd . getBeanClassName () != null ) {
mbdToUse = new RootBeanDefinition(mbd) ;
mbdToUse . setBeanClass (resolvedClass);
}
try {
// 前置校验，不重要
mbdToUse . prepareMethodOverrides ();
} // catch ......
try {
// Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
// 【后置处理器拦截创建bean】
Object bean = resolveBeforeInstantiation(beanName , mbdToUse) ;
if (bean != null ) {
return bean;
}
} // catch ......
try {
// 【真正的创建bean】
Object beanInstance = doCreateBean(beanName , mbdToUse , args) ;
// logger ......
return beanInstance;
} // catch ......
} 可以看到，这个 createBean 的方法中，除了最底下的 doCreateBean 真正创建 bean 之外，在上面还有一步：**resolveBeforeInstantiation** ，而且看注释也能获得这句代码的关键用途：Give BeanPostProcessors a chance to return a proxy instead of the target bean instance. （给后置处理器一个机会来创建代理 bean 而不是目标 bean 实例 ）。跟前面咱学过的 InstantiationAwareBeanPostProcessor 联系起来，这里自然就可以想到，它是会让这些 InstantiationAwareBeanPostProcessor 先试着实例化当前要创建的 bean 。好，那咱进入 resolveBeforeInstantiation 方法中一探究竟。
2.2.1 resolveBeforeInstantiation
复制 protected Object resolveBeforeInstantiation( String beanName , RootBeanDefinition mbd) {
Object bean = null ;
if ( ! Boolean . FALSE . equals ( mbd . beforeInstantiationResolved )) {
// Make sure bean class is actually resolved at this point.
if ( ! mbd . isSynthetic () && hasInstantiationAwareBeanPostProcessors() ) {
Class < ? > targetType = determineTargetType(beanName , mbd) ;
if (targetType != null ) {
// 执行所有InstantiationAwareBeanPostProcessor
bean = applyBeanPostProcessorsBeforeInstantiation(targetType , beanName) ;
if (bean != null ) {
// 如果成功创建出了bean，则执行BeanPostProcessor的后置初始化
bean = applyBeanPostProcessorsAfterInitialization(bean , beanName) ;
}
}
}
mbd . beforeInstantiationResolved = (bean != null );
}
return bean;
}
protected Object applyBeanPostProcessorsBeforeInstantiation( Class<?> beanClass , String beanName) {
for ( BeanPostProcessor bp : getBeanPostProcessors() ) {
// 循环找出所有的InstantiationAwareBeanPostProcessor
if (bp instanceof InstantiationAwareBeanPostProcessor) {
// 调用它们的postProcessBeforeInstantiation尝试实例化bean对象
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
Object result = ibp . postProcessBeforeInstantiation (beanClass , beanName);
if (result != null ) {
return result;
}
}
}
return null ;
} 看，这里的核心动作就是调用 InstantiationAwareBeanPostProcessor 的 postProcessBeforeInstantiation 方法了，接下来的逻辑就很简单了吧。
不过这里面有一个细节哦，小伙伴们可以思考一下：如果 postProcessBeforeInstantiation 方法真的实例化出来了 bean 对象，为什么还需要回调 BeanPostProcessor 的 postProcessAfterInitialization 呢？
回想一下刚开始学 BeanPostProcessor 的时候，我们说 postProcessAfterInitialization 方法的一个关键的作用是生成代理对象 ，如果一个 bean 被 **InstantiationAwareBeanPostProcessor** 提前创建出 bean 了，但又需要创建代理对象 ，这个时候就必须要回调 BeanPostProcessor 的 postProcessAfterInitialization 方法了。
不过从咱写的两个测试 Demo 中，都没有涉及到这部分的内容，感兴趣的小伙伴可以自己修改一下测试 Demo 的代码，添加一个 InstantiationAwareBeanPostProcessor 来测试效果。
2.3 doCreateBean
进入到这个方法，那就相当于要真实的中规中矩的创建 bean 对象了！这个方法中共有三个大步骤：
实例化 bean 对象（此时 bean 中所有属性均为空）
bean 对象的初始化（执行完该步骤后 bean 已经完整）
本章只会讲解这三大步骤的第一步 实例化 bean 对象 ，而这部分的源码还是很简单的：
复制 protected Object doCreateBean( String beanName , RootBeanDefinition mbd , @ Nullable Object [] args)
throws BeanCreationException {
// Instantiate the bean.
BeanWrapper instanceWrapper = null ;
// 处理FactoryBean的小细节问题
if ( mbd . isSingleton ()) {
instanceWrapper = this . factoryBeanInstanceCache . remove (beanName);
}
if (instanceWrapper == null ) {
// 【真正的bean对象创建】
instanceWrapper = createBeanInstance(beanName , mbd , args) ;
}
// 得到真实的bean对象引用
Object bean = instanceWrapper . getWrappedInstance ();
Class < ? > beanType = instanceWrapper . getWrappedClass ();
if (beanType != NullBean . class ) {
mbd . resolvedTargetType = beanType;
}
// ...... ...... ...... 这里面的最核心步骤是 **createBeanInstance** ，它会把真正的 bean 对象实例化出来，不过在此之前有一个小细节的处理：this.factoryBeanInstanceCache.remove(beanName) ，它是干什么的呢？
2.3.1 factoryBeanInstanceCache的作用
借助 IDEA ，观察 factoryBeanInstanceCache 的使用位置，唯一可以找到的 put 方法调用是在 AbstractAutowireCapableBeanFactory 的 getSingletonFactoryBeanForTypeCheck 方法末尾部分：
复制 FactoryBean < ? > fb = getFactoryBean(beanName , instance) ;
if (bw != null ) {
this . factoryBeanInstanceCache . put (beanName , bw);
}
return fb; 且不管这个操作是干什么用，借助 IDEA 继续向上找 getSingletonFactoryBeanForTypeCheck 方法的调用，可以发现进入到 getTypeForFactoryBean 中了。不需要深挖这个方法是干嘛用，且看方法名，就可以知道，它可以获取到 **FactoryBean** 中生成的 bean 的类型 ！可是你获取就获取呗，直接取泛型不好吗？哎，这还真不行，小伙伴们思考一下为什么？
因为。。。泛型可以写抽象类或者接口呀。如果真的这么写，回头框架拿泛型的时候，只能取到接口级别，但具体的实现类可拿不到呀。所以，FactoryBean 中还设计了一个方法：getObjectType ，它可以编程式的返回最终创建出来的对象的类型。不过想要调用 getObjectType 方法，就需要先把 FactoryBean 创建出来。这里面就产生新的问题了：一旦 FactoryBean 被预先创建出来了，而且这个 FactoryBean 还是单实例的 bean ，那原则上讲就不能再创建第二次了。
基于这个原则，SpringFramework 给出的解决方案是：如果提前调用了 getTypeForFactoryBean 确认 FactoryBean 中生成的 bean 的类型，则它会把这个 FactoryBean 本身先存在一个 factoryBeanInstanceCache 中（注意此时的 FactoryBean 只会利用 getObjectType 方法，不会调用 getObject 创建 bean ）；等后续真的需要由 FactoryBean 生成 bean 的时候，它会直接从 factoryBeanInstanceCache 中取出刚才已经实例化的 FactoryBean ，继续执行 bean 的初始化动作（属性赋值、依赖注入等）。
对于这个 factoryBeanInstanceCache 的设计，小伙伴们没必要太深入探究，只需要对这个设计的思想有一个大概的认识即可，也体会一下 SpringFramework 对于 bean 对象控制的滴水不漏。
2.4 createBeanInstance
经过前面的动作，正常情况下第一次执行 doCreateBean 时，一定会走 createBeanInstance 方法的。而这个方法又是好复杂呀！小册还是把这个方法拆解开解释吧：
2.4.1 解析bean类型
复制 protected BeanWrapper createBeanInstance( String beanName , RootBeanDefinition mbd , @ Nullable Object [] args) {
// 解析出bean的类型
Class < ? > beanClass = resolveBeanClass(mbd , beanName) ;
// bean无法被访问，则抛出异常
if (beanClass != null && ! Modifier . isPublic ( beanClass . getModifiers ()) && ! mbd . isNonPublicAccessAllowed ()) {
throw new BeanCreationException( mbd . getResourceDescription() , beanName ,
"Bean class isn't public, and non-public access not allowed: " + beanClass . getName()) ;
}
// ...... 第一步倒是很简单了，它会把当前即将实例化的 bean 的类型先确定出来。确定出来之后有一个校验（要是 bean 的类型本身就没办法被 SpringFramework 访问，那还实例化个锤子。。。），校验完成就可以进行下一步了。
2.4.2 工厂方法创建
复制 // ......
// SpringFramework5的新特性
Supplier < ? > instanceSupplier = mbd . getInstanceSupplier ();
if (instanceSupplier != null ) {
return obtainFromSupplier(instanceSupplier , beanName) ;
}
// 【工厂方法创建】
if ( mbd . getFactoryMethodName () != null ) {
return instantiateUsingFactoryMethod(beanName , mbd , args) ;
}
// ...... 这两段源码，本质都是干一件事：如果在 BeanDefinition 中指定了工厂类型的创建逻辑，则直接走工厂创建。注意这里面的工厂包含两种情况，咱一一解释。
InstanceSupplier
这个设计来自于 AbstractBeanDefinition 中，是 SpringFramework 5.0 之后出现的新 API 。jdk 8 之后多了几个很重要很实用的 lambda ，其中之一就是 Supplier ，它是一个生产型接口。跟工厂的思路类似，Supplier 也可以完成构造 bean 的工作，所以在 BeanDefinition 中加入了这样一个设计，作为 factory-method 的一个替代方案。不过一般情况下我们也不会操纵 BeanDefinition ，所以这个东西我们也用不大到，小伙伴们知道一下就好了。
factoryMethod
真正与我们接触比较多的，是这个 factoryMethod ，除了在 xml 配置文件中定义的 factory-method 之外，注解配置类中被 @Bean 标注的方法，本质上也是一个工厂方法（还记得上一章 2.7.2 节中说的 setFactoryBeanName 、setUniqueFactoryMethodName 方法吧）。源码中它会执行 instantiateUsingFactoryMethod 方法来触发这个 factoryMethod ，由于这个方法实在是太长了！！！（200+行）所以小册在这里帮小伙伴们简单概括一下吧：它会根据工厂名称，找到对应的静态工厂 / 实例工厂 / 注解配置类对象（如果是注解配置类的话，还需要解析 @Bean 方法上的参数列表，注入对应的依赖），随后反射执行工厂方法，生成 bean 对象。
2.4.3 为原型bean的小优化
复制 // ......
// Shortcut when re-creating the same bean...
// 这一步是为原型Bean的一个小优化
boolean resolved = false ;
boolean autowireNecessary = false ;
if (args == null ) {
synchronized ( mbd . constructorArgumentLock ) {
if ( mbd . resolvedConstructorOrFactoryMethod != null ) {
resolved = true ;
autowireNecessary = mbd . constructorArgumentsResolved ;
}
}
}
if (resolved) {
if (autowireNecessary) {
return autowireConstructor(beanName , mbd , null , null ) ;
}
else {
return instantiateBean(beanName , mbd) ;
}
}
// ...... 这部分为什么说它是一个优化呢？注意看后半部分：if (resolved) ，这个判断如果成立，会立即执行注入 / 实例化 bean 的动作（尽管下面还有一些代码没有执行）。那这个部分的设计缘由是什么呢？来我们考虑一个小小的问题：原型 bean 的创建过程中，每次的执行流程都是一样一样的吧！既然是每次都一样，那这些准备动作就没必要每次都执行一遍吧！执行一次之后，把这个过程中一些需要的东西都缓存起来就 OK 吧！所以，这个逻辑中，会把 bean 中需要的一些信息都保存起来，以备后续再创建该 bean 时可以直接拿这些信息，去创建 bean 对象。
这部分缓存的数据主要是解析好的构造器，以及工厂方法。
2.4.4 实例化bean
复制 // Candidate constructors for autowiring?
// 当满足任一条件，就会执行基于构造器的实例化
// 1. 通过SmartInstantiationAwareBeanPostProcessor找到了构造器
// 2. 配置了注入方式是AUTOWIRE_CONSTRUCTOR
// 3. 定义bean的时候指定了constructor-arg
// 4. 构造bean时传入了args参数
Constructor < ? >[] ctors = determineConstructorsFromBeanPostProcessors(beanClass , beanName) ;
if (ctors != null || mbd . getResolvedAutowireMode () == AUTOWIRE_CONSTRUCTOR ||
mbd . hasConstructorArgumentValues () || ! ObjectUtils . isEmpty (args)) {
return autowireConstructor(beanName , mbd , ctors , args) ;
}
// Preferred constructors for default construction?
ctors = mbd . getPreferredConstructors ();
if (ctors != null ) {
return autowireConstructor(beanName , mbd , ctors , null ) ;
}
// No special handling: simply use no-arg constructor.
return instantiateBean(beanName , mbd) ;
} 这部分就是解析构造器、给构造器参数注入，以及反射实例化 bean 的步骤了。首先它会解析实例化 bean 需要的构造器，如果 bean 中有显式的声明非空参数的构造器，则会依次解析构造器参数列表，并进行注入，最后反射创建 bean 对象。如果没有声明，则会调用最后一行的 instantiateBean 方法，使用默认空参构造器反射创建 bean 对象。
简单地来看，最后一行的 instantiateBean 方法中，最终会借助 InstantiationStrategy ，调用 BeanUtils.instantiateClass 方法反射实例化 bean 对象，涉及到的源码如下：
复制 protected BeanWrapper instantiateBean( final String beanName , final RootBeanDefinition mbd) {
try {
Object beanInstance;
final BeanFactory parent = this ;
if // ......
else {
// 借助InstantiationStrategy
beanInstance = getInstantiationStrategy() . instantiate (mbd , beanName , parent);
}
BeanWrapper bw = new BeanWrapperImpl(beanInstance) ;
initBeanWrapper(bw) ;
return bw;
}
// ......
} autowireConstructor 方法中涉及的解析逻辑比较复杂且源码很长，相比较于整体逻辑来看，这个细节的研究性价比不高，小册在此不再深入展开，感兴趣的小伙伴们可以自行深入浏览一下（但不要陷入其中啊啊啊啊）。
当 createBeanInstance 方法执行完之后，就可以得到一个光秃秃的 bean 对象了，bean 的实例化过程也就完成了。下面来总结一下这个阶段发生的内容吧：
3. 总结
bean 实例阶段的生命周期包含三大步骤：
在所有非延迟加载的单实例 bean 初始化之前，会先初始化所有的 **BeanPostProcessor** 。
在 **ApplicationContext** 的 **refresh** 方法中， **finishBeanFactoryInitialization** 步骤会初始化所有的非延迟加载的单实例 bean 。实例化 bean 的入口是 **getBean** → **doGetBean** ，该阶段会合并 **BeanDefinition** ，并根据 bean 的 scope 选择实例化 bean 的策略。
创建 bean 的逻辑会走 **createBean** 方法，该方法中会先执行所有 **InstantiationAwareBeanPostProcessor** 的 **postProcessBeforeInstantiation** 方法尝试创建 bean 实例，如果成功创建，则会直接调用 **postProcessAfterInitialization** 方法初始化 bean 后返回；如果 **InstantiationAwareBeanPostProcessor** 没有创建 bean 实例，则会调用 **doCreateBean** 方法创建 bean 实例。在 **doCreateBean** 方法中，会先根据 bean 的 **Class** 中的构造器定义，决定如何实例化 bean ，如果没有定义构造器，则会使用无参构造器，反射创建 bean 对象。
bean 对象创建完成后，就会执行属性赋值 + 依赖注入的步骤。（下一章继续）
