【Spring启动过程分析】启动流程简介
https://blog.csdn.net/moshenglv/article/details/53517343
-
首先，对于一个
web应用，其部署在web容器(tomcat)中，web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的spring IoC容器提供宿主环境； -
spring容器启动流程
-
定位
在spring中，使用统一的资源表现方式Resource，定位到spring配置文件。 -
加载
在加载这个过程中，主要工作是读取spring配置文件，解析配置文件中的内容，将这些信息转换成为Spring内容可以理解、使用的BeanDefinition。 -
注册
加载过配置文件后，就将BeanDefinition信息注册到BeanDefinitionRegistry接口中，通常情况下Spring容器的实现类都实现这个接口。
-
其次，在web.xml中会提供有contextLoaderListener。在web容器启动时，会触发容器初始化事件，此时 contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，spring会初始化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext，这是一个接口类，确切的说，其实际的实现类是 XmlWebApplicationContext：spring的IoC容器，（定位）其对应的Bean定义的配置由web.xml中的 context-param标签指定，（加载）读取并解析spring配置文件，将这些信息转换成为Spring内容可以理解、使用的BeanDefinition。在这个IoC容器初始化完毕后，spring以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE为属性Key，将其存储到ServletContext中，便于获取；（注册）加载过配置文件后，就将BeanDefinition信息注册到BeanDefinitionRegistry接口中，通常情况下Spring容器的实现类都实现这个接口。在加载完所有Bean Class后，开始有序的通过BeanDefinition实例化Bean。
- 再次，
contextLoaderListener监听器初始化完毕后，开始初始化web.xml中配置的Servlet，这里是DispatcherServlet，这个servlet实际上是一个标准的前端控制器，用以转发、匹配、处理每个servlet请求。DispatcherServlet上下文在初始化的时候会建立自己的IoC上下文，用以持有spring mvc相关的bean。在建立DispatcherServlet自己的IoC上下文时，会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE 先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文。有了这个 parent上下文之后，再初始化自己持有的上下文。这个DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到，大概的工作就是初始化处理器映射、视图解析等。这个servlet自己持有的上下文默认实现类也是 mlWebApplicationContext。初始化完毕后，spring以与servlet的名字相关(此处不是简单的以servlet名为 Key，而是通过一些转换，具体可自行查看源码)的属性为属性Key，也将其存到ServletContext中，以便后续使用。这样每个servlet 就持有自己的上下文，即拥有自己独立的bean空间，同时各个servlet共享相同的bean，即根上下文(第2步中初始化的上下文)定义的那些 bean。
bean实例化的具体过程：
参考
https://blog.csdn.net/qq_27529917/article/details/79329809
ApplicationContext内置一个BeanFactory对象，作为实际的Bean工厂，和Bean相关业务都交给BeanFactory去处理。
（定位）spring容器对应的Bean定义的配置由web.xml中的 context-param标签指定；
（加载）Spring在初始化容器时，会先解析和加载所有的Bean Class，如果符合要求则通过Class生成BeanDefinition；
（注册）在加载完所有Bean Class后，存入BeanFactory中，开始有序的通过BeanDefinition实例化Bean。
配置类可以是Spring容器的起始配置类，也可以是通过@ComponentScan扫描得到的类，也可以是通过@Import引入的类。如果这个类上含有@Configuration，@Component，@ComponentScan，@Import，@ImportResource注解中的一个，或者内部含有@Bean标识的方法，那么这个类就是一个配置类，Spring就会按照一定流程去解析这个类上的信息。
在解析的第一步会校验当前类是否已经被解析过了
-
如果是，那么需要按照一定的规则处理（@ComponentScan得到的Bean能覆盖@Import得到的Bean，@Bean定义的优先级最高）。 -
如果未解析过，那么开始解析：1
解析内部类，查看内部类是否应该被定义成一个Bean，如果是，递归解析。2 解析
@PropertySource，也就是解析被引入的Properties文件。3 解析配置类上是否有@ComponentScan注解，如果有则
执行扫描动作，通过扫描得到的Bean Class会被立即解析成BeanDefinition，添加进beanDefinitionNames属性中。之后查看扫描到的Bean Class是否是一个配置类（大部分情况是，因为标识@Component注解），如果是则递归解析这个Bean Class。4 解析@Import引入的类，如果这个类是一个配置类，则递归解析。
5 解析@Bean标识的方法，此种形式定义的Bean Class不会被递归解析
6 解析父类上的@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