> For the complete documentation index, see [llms.txt](https://ldbmcs.gitbook.io/java/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ldbmcs.gitbook.io/java/java-frameworks-69/spring/spring-ioc/spring-bean-de-sheng-ming-zhou-qi-san-shi-li-hua-jie-duan.md).

# Spring Bean的生命周期(三) - 实例化阶段

上一章，我们对 `BeanDefinition` 阶段的加载、解析、注册都有了一个清晰的了解和深入研究，本章我们要研究的，是在 bean 的初始化阶段，bean 的实例化过程。

本章主要会涉及到的原理部分：

* `BeanPostProcessor` 的注册
* bean 的实例化动作及方式

好，下面我们进入源码分析。上一章我们说过了，`**refresh**` 方法承载了 `ApplicationContext` 的整体初始化动作，而这里面初始化 bean 的逻辑在第 11 步。不过在此之前，还有一个非常重要的部分，它就是 `BeanPostProcessor` 的注册动作，这两个动作在 `refresh` 方法中的位置如下：

```java
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

```java
protected void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) {
    PostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);
}
```

又是走了 `PostProcessorRegistrationDelegate` 的方法，那我们就跳转过去看看吧：

```java
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 被提前创建了。

```java
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类型的后置处理器被提前创建的目的

我们仔细看一下这段代码的处理：

```java
    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 变式一：如果循环过程中顺便初始化

如果说先把后置处理器的全限定名都取出来，再实例化出来是多此一举，那每次循环的时候直接初始化出来不好吗？就像这样：

```java
    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 ......
    }
```

这样会有什么问题呢？我们可以假想一个故事场景来演绎一下。

注：该故事仅为虚拟场景的情节演绎，小伙伴们切勿模仿该行为！！！！！！

现在有三个 “黑社会” 熊猫（代指三个后置处理器），他们仨常蹲在路口边上打劫收保护费，他们平常 “作案” 的流程是这样的：老大负责恐吓威胁路人，把路人吓唬住了就带到老二那边收保护费，如果路人不交保护费，则老三直接上去一个酒瓶子把路人抡倒，就像这样：

![img](https://image.ldbmcs.com/E3nab2.jpg)

解释一下这个场景的一些要素哈：此处我们假定老大实现了 `PriorityOrdered` 接口，老二和老三实现了 `Ordered` 接口。按理讲，老大的出手时机一定比老二和老三早（ `PriorityOrdered` 接口的处理时机比 `Ordered` 早）。

老大威胁路人的行为在此处比作正常的 bean 初始化阶段的 `postProcessBeforeInitialization` 方法回调，老三拿酒瓶子抡路人的行为在此处比作 bean 初始化阶段的 `postProcessAfterInitialization` 方法回调。所以我们在这里虚拟的场景是这样：每个路人是一个普通的 bean ，在 bean 执行初始化阶段的回调之前会有 `BeanPostProcessor` 去拦截一下 bean 并作额外处理（也就是收路人的保护费）。

平常每天都是老大先找准了蹲点的地方，埋伏好了之后老二和老三就赶过来，就这样哥仨一直靠收路人的保护费混日子。不过这个场景在某天出现了意外，那天**老三**喝多了，大清早的天还没亮就**带着老二先出发了**，随便找了一个点就埋伏好了，等路人经过就去收他钱。好巧不巧，这天**老大就路过了老三所在的这个点**，老三喝多了啊，连自己老大都不认识了，就去叫老二去收保护费，本来就是天还没亮就被老三叫起来，老二也睡眼惺忪的，就让他老大交钱。老大也懵了啊，我去不会这片地儿还有另一派黑恶势力？可是昨天我刚跟我那两个兄弟喝酒了啊，没钱了咋整。这就尴尬了，老二没看清是老大，就让老三上去收拾了，结果老三一个酒瓶子下去，把老大敲懵了。。。

![img](https://image.ldbmcs.com/BICPbs.jpg)

好，故事到这里停一下，咱讲讲这个情节对应的代码实现。在这种意外场景下，由于**老二和老三在所有** `**BeanPostProcessor**` **列表的前置位**，导致它们（这两个实现了 `Ordered` 接口的后置处理器）先被读取。如果此时初始化后置处理器的代码逻辑是上面的变式，则上面的故事情景就会发生：老二和老三先注册到了 `ApplicationContext` 中，它们已经开始起作用了。之后即便再来老大（实现了 `PriorityOrdered` 接口的后置处理器）的时候，老二和老三把老大当普通路人看待了（即 被后置处理器处理了），于是就把老大揍了，导致结果出现意外（程序出现错误）。

所以到这里，小伙伴们是否理解了为什么不能在循环中顺便初始化 `BeanPostProcessor` 了吧，咱简单总结一下：

**如果** `**BeanPostProcessor**` **的初始化逻辑是一边循环一边初始化，则可能会导致优先级低的** `**BeanPostProcessor**` **干预了优先级高的** `**BeanPostProcessor**` **，从而引发程序的运行情况异常。而正确的做法就是只初始化最高优先级的** `**BeanPostProcessor**` **，其余的都只是记录下全限定名，等所有最高优先级的** `**BeanPostProcessor**` **都初始化完成后，再依次初始化低优先级的** `**BeanPostProcessor**` **（优先级低的** `**BeanPostProcessor**` **可能也需要被优先级高的** `**BeanPostProcessor**` **处理）。**

#### 1.2.2 变式二：如果循环过程中不初始化

既然不能一边循环一边初始化，那为什么不先循环完事了，再依次初始化呢，就像这样子：

```java
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` 方法中看一眼：

```java
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 初始化的动作是最后一行，其余的部分我们不关心：

```java
protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
    // ......

    // Instantiate all remaining (non-lazy-init) singletons.
    beanFactory.preInstantiateSingletons();
}
```

来到 `DefaultListableBeanFactory` 中，看看 `preInstantiateSingletons` 的实现：

```java
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` 方法：

```java
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` 方法中，发现它又是在折腾重载的方法，最终调用的是三参数的方法：

```java
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` 中的），接下来就是这个最复杂的的三参数重载的方法了：

```java
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` 方法的调用方式：

```java
    // 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

```java
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

```java
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

```java
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 对象了！这个方法中共有三个大步骤：

1. 实例化 bean 对象（此时 bean 中所有属性均为空）
2. 属性赋值 & 依赖注入
3. bean 对象的初始化（执行完该步骤后 bean 已经完整）

本章只会讲解这三大步骤的第一步 **实例化 bean 对象** ，而这部分的源码还是很简单的：

```java
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` 方法末尾部分：

```java
    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类型

```java
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 工厂方法创建

```java
    // ......
    // 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的小优化

```java
    // ......
    // 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

```java
    // 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 对象，涉及到的源码如下：

```java
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 实例阶段的生命周期包含三大步骤：**

1. **bean 的实例化**
2. **属性赋值 + 依赖注入**
3. **bean 的初始化生命周期回调**
4. **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 对象创建完成后，就会执行属性赋值 + 依赖注入的步骤。（下一章继续）