解析加载及实例化豆的顺序（零配置)

在使用春天时嘿，比恩之间会有些依赖，比如一个豆甲实例化时需要用到豆b，那么B应该在A之前实例化好。很多时候春天智能地为我们做好了这些工作，但某些情况下可能不是，比如跳羚的@自动配置后注解，手动的指定豆的实例化顺序。

了解春天内豆的解析，加载和实例化顺序机制有助于我们更好的使用春天/跳羚，避免手动的去干预豆的加载过程，搭建更优雅的框架。

春天容器在实例化时会加载容器内所有非延迟加载的单例类型比恩，看如下源码：

公共抽象类抽象应用上下文扩展了DefaultResourceLoader

实现了配置应用程序上下文，处理器Bean {

//刷新春天容器，相当于初始化

公共void刷新()引发了BeansException，IllegalStateException {。

//实例化所有剩余的（非惰性初始化)单例。

完成工厂初始化（工厂);

}

}

公共类defaultlistablebeantfactory扩展了抽象无线能力工厂

实现可配置的可移植工厂，可定义的注册表，可序列化的

/**按注册顺序排列的豆定义名称列表*/

私有易失性列表《String》 beanDefinitionNames=新数组列表《String》(256);

public void preInstantiateSingletons()引发豆异常（

list 《String》 BeanNames=new ArrayList 《String》(这。bean definitionnames)；

用于(字符串bean名称：bean名称){ 0。

getBean(bean名称)；//实例化豆

}

}

}

应用程序上下文内置一个豆工厂对象，作为实际的豆工厂，和豆相关业务都交给豆工厂去处理。

在豆工厂实例化所有非延迟加载的单例豆时，遍历beanDefinitionNames集合，按顺序实例化指定名称的比恩。beanDefinitionNames属性是春天在加载豆类生成的的载入和解析时，为这些豆预先定义好的名称，看如下代码：

公共类defaultlistablebeantfactory扩展了抽象无线能力工厂

实现可配置的可移植工厂，可定义的注册表，可序列化的

public void registerbean定义(字符串beanName，BeanDefinition beanDefinition)

引发BeanDefinitionStoreException {。

这个。BeanDefinitionNames。添加(BeanName)；

}

}

豆工厂在加载一个BeanDefinition(也就是加载豆类)时，将相应的豆名存入beanDefinitionNames属性中，在加载完所有的的载入和解析后，执行豆实例化工作，此时会依据beanDefinitionNames的顺序来有序实例化比恩，也就是说春天容器内豆的加载和实例化是有顺序的，而且近似一致，当然仅是近似。

春天在初始化容器时，会先解析和加载所有的豆类，如果符合要求则通过C

lass生成BeanDefinition，存入BeanFactory中，在加载完所有Bean Class后，开始有序的通过BeanDefinition实例化Bean。

我们先看加载Bean Class过程，零配置下Spring Bean的加载起始于ConfigurationClassPostProcessor的postProcessBeanDefinitionRegistry（BeanDefinitionRegistry）方法，我总结了下其加载解析Bean Class的流程：

配置类可以是Spring容器的起始配置类，也可以是通过@ComponentScan扫描得到的类，也可以是通过@Import引入的类。如果这个类上含有@Configuration，@Component，@ComponentScan，@Import，@ImportResource注解中的一个，或者内部含有@Bean标识的方法，那么这个类就是一个配置类，Spring就会按照一定流程去解析这个类上的信息。

在解析的第一步会校验当前类是否已经被解析过了，如果是，那么需要按照一定的规则处理（@ComponentScan得到的Bean能覆盖@Import得到的Bean，@Bean定义的优先级最高）。

如果未解析过，那么开始解析：

解析内部类，查看内部类是否应该被定义成一个Bean，如果是，递归解析。

解析@PropertySource，也就是解析被引入的Properties文件。

解析配置类上是否有@ComponentScan注解，如果有则执行扫描动作，通过扫描得到的Bean Class会被立即解析成BeanDefinition，添加进beanDefinitionNames属性中。之后查看扫描到的Bean Class是否是一个配置类（大部分情况是，因为标识@Component注解），如果是则递归解析这个Bean Class。

解析@Import引入的类，如果这个类是一个配置类，则递归解析。

解析@Bean标识的方法，此种形式定义的Bean Class不会被递归解析

解析父类上的@ComponentScan，@Import，@Bean，父类不会被再次实例化，因为其子类能够做父类的工作，不需要额外的Bean了。

在1，3，4，6中都有递归操作，也就是在解析一个Bean Class A时，发现其上能够获取到其他Bean Class B信息，此时会递归的解析Bean Class B，在解析完Bean Class B后再接着解析Bean Class A，可能在解析B时能够获取到C，那么也会先解析C再解析B，就这样不断的递归解析。

在第3步中，通过@ComponentScan扫描直接得到的Bean Class会被立即加载入beanDefinitionNames中，但@Import和@Bean形式定义的Bean Class则不会，也就是说正常情况下面@ComponentScan直接得到的Bean其实例化时机比其他两种形式的要早。

通过@Bean和@Import形式定义的Bean Class不会立即加载，他们会被放入一个ConfigurationClass类中，然后按照解析的顺序有序排列，就是图片上的 “将配置类有序排列”。一个ConfigurationClass代表一个配置类，这个类可能是被@ComponentScan扫描到的，则此类已经被加载过了；也可能是被@Import引入的，则此类还未被加载；此类中可能含有@Bean标识的方法。

Spring在解析完了所有Bean Class后，开始加载ConfigurationClass。如果这个ConfigurationClass是被Import的，也就是说在加载@ComponentScan时其未被加载，那么此时加载ConfigurationClass代表的Bean Class。然后加载ConfigurationClass内的@Bean方法。

顺序总结：@ComponentScan 》 @Import 》 @Bean

Bean Class的结构图如上所示，A是配置类的入口，通过A能直接或间接的引入一个模块。

此时启动Spring容器，将A引入容器内。

如果A是通过@ComponentScan扫描到的，那么此时的加载顺序是：

A 》 D 》 F 》 B 》 E 》 G 》 C

如果A是通过@Import形式引入的，那么此时的加载顺讯是：

D 》 F 》 B 》 E 》 G 》 A 》 C

当然以上仅仅代表着加载Bean Class的顺序，实际实例化Bean的顺序和加载顺序大体相同，但还是会有一些差别。

Spring在通过getBean（beanName）形式实例化Bean时，会通过BeanDefinition去生成Bean对象。在这个过程中，如果BeanDefinition的DependsOn不为空，从字面理解就是依赖某个什么，其值一般是某个或多个beanName，也就是说依赖于其他Bean。

此时Spring会将DependsOn指定的这些名称的Bean先实例化，也就是先调用getBean（dependsOn）方法。我们可以通过在Bean Class或者@Bean的方法上标识**@DependsOn**注解，来指定当前Bean实例化时需要触发哪些Bean的提前实例化。

当一个Bean A内部通过@Autowired或者@Resource注入Bean B，那么在实例化A时会触发B的提前实例化，此时会注册A》B的dependsOn依赖关系，实质和@DependsOn一样，这个是Spring自动为我们处理好的。

了解Spring Bean的解析，加载及实例化的顺序机制能够加深对Spring的理解，搭建更优雅简介的Spring框架。