1.SpringBoot的源码CommandLineRunner和ApplicationRunner源码分析
2.Spring Boot小记

SpringBoot的CommandLineRunner和ApplicationRunner源码分析

       深入探究SpringBoot中的ApplicationRunner和CommandLineRunner接口。这两个接口在启动SpringBoot应用时起到关键作用，分析下面将对它们进行源码分析。源码

       首先，分析让我们聚焦于ApplicationRunner接口，源码专门广告的网站源码其内部定义了一个名为run的分析英雄联盟防封源码方法，无需额外参数，源码源码如下所示，分析展示了接口的源码基本框架。

       接着，分析审视CommandLineRunner接口，源码同样地，分析它也仅定义了一个run方法，源码主图板块源码公式同样没有额外参数，分析源码内容在此。源码接口设计简洁，旨在支持特定逻辑的正规卡易信源码执行。

       为了更直观地理解这些接口的运行，让我们通过实际项目进行演示。具体操作是将SpringBoot项目打包为JAR文件并执行。

       在项目执行过程中，冒险岛117源码观察并分析代码，可以揭示更多关于ApplicationRunner和CommandLineRunner接口如何在实际应用中运作的细节。

       接下来，以ApplicationRunnerDemo和CommandLineRunnerDemo为例，深入探讨接口的使用。首先，审视ApplicationRunnerDemo类，了解如何定义实现ApplicationRunner接口的实例并注入应用上下文。然后，通过CommandLineRunnerDemo类，进一步探索实现CommandLineRunner接口的实例，关注参数传递的机制以及接口执行的时机。

       至此，参数传递、参数解析以及获取参数的过程已经清晰呈现。此外，ApplicationRunner和CommandLineRunnerDemo的执行时机也已明确阐述，为理解SpringBoot启动过程中的关键逻辑提供了深入洞察。

Spring Boot小记

        1、ApplicationContextInitializer，在Spring上下文被刷新之前进行初始化的操作。这个时候已经创建了ApplicationContext ，但是没有refresh()，ApplicationContextInitializer对ApplicationContext进行初始话操作。

        2、SpringApplicationRunListener，对ApplicationContext的运行各个时期的事件进行广播，时事件能够被ApplicationListener所监听到。

        3、Runner，Spring上下文后置处理 Runners可以是两个接口的实现类： org.springframework.boot.ApplicationRunner org.springframework.boot.CommandLineRunner 其实没有什么不同之处，除了接口中的run方法接受的参数类型是不一样的以外。一个是封装好的ApplicationArguments类型，另一个是直接的String不定长数组类型。因此根据需要选择相应的接口实现即可。

        SpringBoot启动的时候，不论调用什么方法，都会构造一个SpringApplication的实例，然后调用这个实例的run方法，这样就表示启动SpringBoot。

        在run方法调用之前，也就是构造SpringApplication的时候会进行初始化的工作，初始化的时候会做以下几件事：

        SpringApplication构造完成之后调用run方法，启动SpringApplication，run方法执行的时候会做以下几件事：

        在@SpringBootApplication标签中引入了EnableAutoConfigurationImportSelector，其中调用了selectImports()方法，方法中调用org.springframework.boot.autoconfigure.EnableAutoConfigurationImportSelector#getCandidateConfigurations方法，使用SpringFactoryLoader把META-INF文件夹中的spring.factories文件中EnableAutoConfiguration为key的文件加载了。 加载的文件全部都是java config配置文件（有默认配置），利用@Conditional(Class<? extends Condition>[]) 标签，对相应的bean进行选择性的加载。

        比较基本而且重要的一个类，运行加载了MATE-INF中的spring.factories 文件

        @Conditional标签是全部Conditional相关标签的根源。 源码中Conditional标签使用的是ConditionEvaluator来解析，如下 org.springframework.context.annotation.AnnotatedBeanDefinitionReader#registerBean(java.lang.Class<?>, java.lang.String, java.lang.Class<? extends java.lang.annotation.Annotation>...) org.springframework.context.annotation.ConditionEvaluator#shouldSkip(org.springframework.core.type.AnnotatedTypeMetadata, org.springframework.context.annotation.ConfigurationCondition.ConfigurationPhase)

        在初始化AnnotationConfigApplicationContext的时候，对ConfigurationClassPostProcessor、AutowiredAnnotationBeanPostProcessor等类进行了注册。如下

        ConfigurationClassPostProcessor是一个BeanFactoryPostProcessor，所以会对BeanDefinitionRegistry或者BeanDefinition创建之后进行后置加工（refresh方法中，已经创建了BeanFactory，具体到运行到哪里看源码）。

        import解析原理根据的是ConfigurationClassPostProcessor，ConfigurationClassPostProcessor的加载过程参考上面 主要分析为啥@import标签是引入配置的但是却能够调用Selector的方法 org.springframework.context.annotation.ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry org.springframework.context.annotation.ConfigurationClassPostProcessor#processConfigBeanDefinitions org.springframework.context.annotation.ConfigurationClassParser#parse(java.util.Set<org.springframework.beans.factory.config.BeanDefinitionHolder>) org.springframework.context.annotation.ConfigurationClassParser#processDeferredImportSelectors 接着如下，调用了selectImports方法