Springboot初始化流程解析

以上是一个最简单的Springboot程序（2.0.3版本）示例，也是我们最通用的写法，但其中其实封装这一系列复杂的功能 *** 作，让我们开始逐步进行分析。

首先这里最重要的必然是注解 @SpringBootApplication

@SpringBootApplication 注解由几个注解复合组成，其中最主要的就是 @SpringBootConfiguration 、 @EnableAutoConfiguration 和 @ComponentScan 这三个。

其中的 @ComponentScan 是spring的原生注解， @SpringBootConfiguration 虽然是springboot中的注解，但其实质就是包装后的 @Configuration ，仍然是spring中的注解，用于代替xml的方式管理配置bean

@EnableAutoConfiguration 的定义如上，这里最重要的注解是 @Import （ @AutoConfigurationPackage 注解的实现也是基于 @Import ），借助 @Import 的帮助，将所有符合自动配置条件的bean定义加载到IoC容器中。关于 @EnableAutoConfiguration 注解后续涉及到时会再详细说明。这里我们先回到启动类的 run 方法从头分析初始化流程。

可以看到'run'方法最终调用的是 new SpringApplication(primarySources).run(args) ，这里首先创建了 SpringApplication 对象，然后调用其 run 方法

这里主要是为 SpringApplication 对象进行初始化，这里要专门提一下的是 webApplicationType 和 getSpringFactoriesInstances 。

它用来标识我们的应用是什么类型的应用，来看一下 deduceWebApplicationType() 方法的实现

其返回值是 WebApplicationType 类型的枚举类，其值有 NONE 、 SERVLET 、 REACTIVE 三种，分别对应非WEB应用，基于servlet的WEB应用和基于reactive的WEB应用。

这里的核心是 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 方法，来看一下

重点关注一下 loadSpringFactories(classLoader) 做了什么

这里的 FACTORIES_RESOURCE_LOCATION 定义为 META-INF/spring.factories ，因此该方法会扫描所有包下的该文件，将其解析成map对象并缓存到 cache 中以避免重复加载，springboot包下该文件的部分片段如下

从这里可以看出， setInitializers((Collection) getSpringFactoriesInstances( ApplicationContextInitializer.class)) 和 setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class))分别对应设置的是上述这些类。

解析完成后调用 createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names) 处理解析结果，生成对应的实例，源码如下

这里的核心是通过 ClassUtils.forName(name, classLoader) 方法，以反射的方式生成类实例 instanceClass 。由此可以看出 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 的作用就是将 META-INF/spring.factories 中配置的内容进行实例化的工厂方法类，具备很强的扩展性，与SPI机制有异曲同工

的效果。

看完 SpringApplication 的初始化，接着跳回 run 方法继续分析

这里挑其中比较重要的几个方法进行分析

通过 getOrCreateEnvironment() 方法创建容器环境

可以看到 environment 存在则不会重复创建，当应用类型为servlet时创建的是 StandardServletEnvironment 对象，否则创建 StandardEnvironment 对象。

接着来看 configureEnvironment(environment, applicationArguments.getSourceArgs())

configurePropertySources(environment, args) 加载启动命令行的配置属性，来看一下实现

这里的 MutablePropertySources 对象用于存储配置集合，其内部维护了一个 CopyOnWriteArrayList 类型的list对象，当默认配置存在时，会向该list的尾部插入一个 new MapPropertySource("defaultProperties", this.defaultProperties) 对象。

接着来看 configureProfiles(environment, args)

这里主要做的事情就是获取 environment.getActiveProfiles() 的参数设置到 environment 中，即 spring.profiles.active 对应的环境变量。

最后来看一下 listeners.environmentPrepared(environment)

这里的 listeners 就是之前通过 META-INF/spring.factories 注册的所有listeners，后面我们先以其中最重要的 ConfigFileApplicationListener 做为例子进行分析，接着来看 listener.environmentPrepared(environment)

可以看到这里创建了一个 ApplicationEnvironmentPreparedEvent 类型的事件，并且调用了 multicastEvent 方法，通过该方法最终会调用到listener的 onApplicationEvent 方法，触发事件监听器的执行。

接下来具体看一下 ConfigFileApplicationListener 的 onApplicationEvent 方法做了什么

可以看到当监听到 ApplicationEnvironmentPreparedEvent 类型的事件时，调用 onApplicationEnvironmentPreparedEvent( (ApplicationEnvironmentPreparedEvent) event) 方法

可以看到这里通过 loadPostProcessors() 方法加载了 META-INF/spring.factories 中的所有 EnvironmentPostProcessor 类到list中，同时把 ConfigFileApplicationListener 自己也添加进去了。接着遍历list中所有对象，并执行 postProcessEnvironment 方法，于是接着来看该方法

这里的核心是 new Loader(environment, resourceLoader).load() ，这里的 Loader 是一个内部类，用于处理配置文件的加载，首先看一下其构造方法

可以看到这里的 resourceLoader 又是通过 SpringFactoriesLoader 进行加载，那么来看看 META-INF/spring.factories 中定义了哪些 resourceLoader

从名字就可以看出来， PropertiesPropertySourceLoader 和 YamlPropertySourceLoader 分别用于处理.properties和.yml类型的配置文件。

接着来看看 load() 方法做了什么

initializeProfiles() 进行了 profiles 的初始化，默认会添加 null 和 default 到 profiles 中， null 对应配置文件application.properties和application.yml， default 对应配置文件application-default.yml和application-default.properties，这里的 null 会被优先处理，由于后处理的会覆盖先处理的，因此其优先级最低。

接着来看 load(profile, this::getPositiveProfileFilter, addToLoaded(MutablePropertySources::addLast, false)) 方法

这里重点是通过 getSearchLocations() 获取配置文件的路径，默认会获得4个路径

接着会遍历这些路径，拼接配置文件名称，选择合适的yml或者properties解析器进行解析，最后将结果添加到 environment 的 propertySources 中。

可以看到这里也是根据 webApplicationType 的取值，分别创建不同的返回类型。

这里的 sources 装的就是我们的启动类，然后通过 load(context, sources.toArray(new Object[0])) 方法进行加载

来看一下 loader 是如何被加载的

经过一系列调用之后最终由 load(Class<?>source) 方法执行，这里比较有趣的是当Groovy存在时居然是优先调用Groovy的方式进行加载，否则才走 this.annotatedReader.register(source) 方法将启动类注册到 beanDefinitionMap 中。

这个 refresh() 方法相当重要，尤其是 invokeBeanFactoryPostProcessors(beanFactory) ，这是实现spring-boot-starter-*(mybatis、redis等)自动化配置的关键部分，后续再详细讲解。

至此Springboot的启动流程已经大体分析完了，也了解了配置文件和启动类分别是是如何被加载的，但仍有两个问题待解，一是Springboot的核心思想约定大于配置是如何做到的，二是Springboot的各种spring-boot-starter-*是如何发挥作用的，这两个问题留待后续文章继续分析。

库卡机器人的初始化程序指的是将机器人控制器的系统恢复到出厂设置的程序。初始化程序是一种高风险的 *** 作，因为它会删除所有控制器上的数据和设置，并将其恢复到出厂设置。因此，在执行初始化程序之前，请务必备份所有重要的程序、数据和设置，以免造成数据丢失或无法恢复的损失。

以下是初始化库卡机器人控制器的步骤：

将机器人控制器的电源关闭，并将所有外设断电。

将控制器的主电源开关设为“ON”。

按住控制器正面面板上的“系统”和“菜单”按键。

同时按下“电源”开关，然后松开。

在屏幕上出现“INITIALIZATION MODE”字样时，按下“确认”键。

接着屏幕上会显示“INITIALIZATION NOW”，按下“确认”键。

初始化过程需要一定的时间，请等待屏幕上显示“INITIALIZATION COMPLETE”字样。

初始化完成后，按下“确认”键，控制器将自动重新启动。

初始化完成后，您需要重新安装库卡机器人控制器上的所有程序，并重新设置所有参数和配置。

需要注意的是，执行初始化程序是一项高风险的 *** 作，请务必在备份所有重要数据和设置后再进行。如果您有任何问题或疑问，请参考库卡机器人控制器的用户手册，或者联系库卡机器人的技术支持团队。

---