Springboot的工作机制：3 SpringApplication:SpringBoot程序启动的一站式解决方案_commandlinerunner执行时 applicationcontext未初始化完成-CSDN博客

本文链接：https://blog.csdn.net/weixin_44778952/article/details/106551888

文章目录

如果非说SpringBoot微框架提供了点儿自己特有的东西，在核心类层面（除了各种场景下的自动配置一站式插拔模块），也就是SpringApplication了。

SpringApplication将一个典型的Spring应用启动的流程“模板化”（这里是动词），在没有特殊需求的情况下，默认模板化后的执行流程就可以满足需求了；但有特殊需求也没有关系，SpringApplication在合适的流程结点开放了一系列不同类型的扩展点，我们可以通过这些扩展点对SpringBoot程序的启动和关闭过程进行扩展。

最“肤浅”的扩展或配置是SpringApplication通过一系列设置方法（setters）开发的定制方式，比如：

SpringApplication.run(DemoApplication.class,args);
SpringApplication bootstrp=new SpringApplication(Demo-Configuration.class);
bootstrap.setBanner(new Banner(){
	@Override
	public void printBanner(Environment environment,Class<?> aClass ,PrintStream printStream){
		//比如打印一个我们喜欢的ASCII Arts字符画
	}
});
bootstrap.setBannerMode(Banner.Mode.CONSOLE);
//其它定制设置。。。
bootstrap.run(args);

上面代码中设置自定义Banner最简单的方式其实是把ASCII Art字符画放到一个资源文件，然后通过ResourceBanner来加载：bootstrap.setBanner(new ResourceBanner(new ClassPathResource("banner.txt)));

大部分情况下，SpringApplication已经提供了很好的默认设置，所以，我们不再对这些表层进行探究了，因为对表层之下的东西进行探究才是我们的最终目的。

深入探索SpringApplication执行流程

SpringApplication的run方法的实现是我们本次旅程的主要线路，该方法的主要流程答大体可以归纳入下：

如果我们使用的是SpringApplication的静态run方法，那么，这个方法里首先需要创建一个SpringApplication对象实例，然后调用这个创建好的SpringApplication的实例run方法。在SpringApplication实例初始化的时候，它会提前做几件事情：
1. 根据classpath里面是否存在某个特征类（org.springframework.web.context.ConfigurableWebApplicationContext）来决定是否应该创建一个为Web应用会用的ApplicationContext类型，还是应该创建一个标准的Standalone应用使用的ApplicationContext类型。
2. 使用SpringFactoriesLoader在应用的classpath中查找并加载所有可用的ApplicationContextInitializer。
3. 使用SpringFactoriesLoader在应用的classpath中查找并加载所有可用的ApplicationListener。
4. 推断并设置main方法的定义类
SpringApplication实例初始化完成并完成设置后，就开始执行run方法的逻辑了，方法执行伊始，首先通过遍历执行所有通过SpringFactoriesLoader可以查到并加载的SpringApplicationRunListener，调用它们的started()方法，告诉这些SpringApplicationRunListener，“嘿，SpringBoot应用要开始执行咯！”。
创建并配置当前SpringBoot应用将要使用的Environment（包括配置要使用的PropertySource以及Profile）。
遍历调用所有SpringApplicationRunListener的environmentPrepared()方法，告诉它们：“当前SpringBoot应用使用的Environment准备好咯！”。
如果SpringApplication的showBanner属性被设置为true，则打印banner（在SpingBoot 1.3.x 版本，这里应该是基于Banner.Mode决定banner的打印行为）。这一步的逻辑其实可以不关心，我认为唯一的用途就是“好玩”（Just For Fun）。
根据用户是否明确设置了applicationContextClass类型以及初始化阶段的推断结果，决定该为当前SpringBoot应用创建什么类型的ApplicationContext并创建完成，然后根据条件决定是否添加ShutdownHook，决定是否使用自定义的BeanNameGenerator，决定是否使用自定义的ResourceLoader，当然，最重要的，将之前准备好的Environment设置给创建好的ApplicationContext使用。
ApplicationContext创建好之后，SpringApplication会再次借助Spring-FactoriresLoader，查找并加载classpath中所有可用的ApplicationContext-Initializer，然后遍历调用这些ApplicationContextInitializer，然后遍历调用这些ApplicationContextInitializer的initialize(applicationContext)方法来对已经创建好的ApplicationContext进行进一步的处理。
遍历调用所有SpringApplicationRunListener的contextPrepared()方法，通知它们：“SpringBoot应用使用的ApplicationContext准备好啦！”
最核心的一步，将之前通过@EnableAutoConfiguration获取的所有配置以及其他形式的IoC容器配置加载到已经准备完毕的ApplicationContext。
遍历调用所有SpringApplicationRunListener的contextLoaded()方法，告知所有SpringApplicationRunListener，“ApplicationContext 装填完毕！”
调用ApplicationContext的refresh()方法，完成IoC容器可用的最后一道工序。
查找当前ApplicationContext中是否注册有CommandLineRunner，如果有，则遍历执行它们。
正常情况下，遍历执行SpringApplicationRunListener的finished()方法，告知它们：“搞定！”。（如果整个过程出现异常，则依然调用所有SpringApplicationRunListener的finished()方法，只不过这种情况下会将异常信息一并传入处理）。

至此，一个完成的SpringBoot应用启动完毕！
整个过程看起来冗长无比，但其实很多都是一些事件通知的扩展点，如果我们将这些逻辑暂时忽略，那么，其实整个SpringBoot应用启动的逻辑就可以压缩到极其精简的几步，如下图所示：
在这里插入图片描述
前后对比我们就可以发现，其实SpringApplication提供的这些各类扩展点近乎“喧宾夺主”，占据了一个Spring应用启动逻辑的大部分“江山”，除了初始化并准备好ApplicationContext，剩下的大部分工作都是通过这些扩展点完成的，所以，我们有必要对各类扩展点进行剖析，以便在需要的时候信手拈来，为我所用。

SpringApplicationRunListener

SpringApplicationRunListener是一个只有SpringBoot应用的main方法执行过程中接收不同执行时点事件通知的监听者：

public interface SpringApplicationRunListener { 
	void started(); 
	void environmentPrepared( ConfigurableEnvironment environment); 
	void contextPrepared( ConfigurableApplicationContext context); 
	void contextLoaded( ConfigurableApplicationContext context); 
	void finished( ConfigurableApplicationContext context, Throwable exception); 
}

对于我们来说，基本没什么常见的场景需要自己实现一个SpringApplicationRunListener，即使SpringBoot默认也只实现了一个org.springframework.boot.context.event.EventPublishingRunListener，用于在SpringBoot启动的不同时点发布不同的应用事件类型（ApplicationEvent），如果有哪些ApplicationListener对这些应用事件感兴趣，则可以接收并处理。

假设我们真的有场景需要自定义一个SpringApplicationRunListener实现，那么有一点需要注意，即任何一个SpringApplicationRunListener实现类的构造方法（Constructor）需要有两个构造参数，一个构造参数的类型就是我们的org.springframework.boot.SpringApplication，另外一个就是args参数列表的String[]:

public class DemoSpringApplicationRunListener implements SpringApplicationRunListener { 
	@Override 
	public void started() {
		// do whatever you want to do 
	} 
	@Override 
	public void environmentPrepared( ConfigurableEnvironment environment) { 
		// do whatever you want to do 
	} 
	@Override 
	public void contextPrepared( ConfigurableApplicationContext context) { 
		// do whatever you want to do 
	} 
	@Override 
	public void contextLoaded( ConfigurableApplicationContext context) { 
		// do whatever you want to do 
	} 
	@Override 
	public void finished( ConfigurableApplicationContext context, Throwable exception) { 
		// do whatever you want to do 
	} 
}

之后，我们可以通过SpringFactoriesLoader立下的规矩，在当前SpringBoot应用的classpath下的META-INF/spring.factories文件中进行类似如下的配置：

org.springframework.boot.SpringApplicationRunListener=\
com.self.springboot.demo.DemoSpringApplicationRunListener

然后SpringApplication就会在运行的时候调用它啦！

ApplicationListener

ApplicationListener其实是老面孔，属于Spring框架对Java中实现的监听者模式的一种框架实现，这里唯一值得着重强调的是，对于初次接触SpringBoot，但对Spring框架本身又没有过多接触的开发者来说，可能会将这个名字与SpringApplicationRunListener混淆。

关于ApplicationListener我们就不做过多介绍了，如果感兴趣，请参考Spring框架相关的资料和书籍。

如果我们要为SpringBoot应用添加自定义的ApplicationListener，有两种方式：

通过SpringApplication.addListeners(… )或者SpringApplication.setListeners(… )方法添加一个或者多个自定义的ApplicationListener;

借助SpringFactoriesLoader机制，在META-INF/spring.factories文件中添加配置（以下代码是为SpringBoot默认注册的ApplicationListener配置）

org.springframework.context.ApplicationListener=\
org.springframework.boot.builder.ParentContextCloserApplicationListener,\
org.springframework.boot.cloudfoundry.VcapApplicationListener,\
org.springframework.boot.context.FileEncodingApplicationListener,\
org.springframework.boot.context.config.AnsiOutputApplicationListener,\
org.springframework.boot.context.config.ConfigFileApplicationListener,\
org.springframework.boot.context.config.DelegatingApplicationListener,\
org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicat- ionListener,\
org.springframework.boot.logging.ClasspathLoggingApplicationListener,\
org.springframework.boot.logging.LoggingApplicationListener

关于ApplicationListener，我们就说这些。

ApplicationContextInitializer

ApplicationContextInitializer也是Spring框架原有的概念，这个类的主要目的是在ConfigurableApplictaionContext类型(或者子类型)的ApplicationContext的refresh之前，允许我们对ConfigurableApplicationContext的实例做进一步的设置和处理。

实现一个ApplicationContextInitializer很简单，因为它只有一个方法需要实现：

public class DemoApplicationContextInitializer implements ApplicationContextInitializer { 
	@Override 
	public void initialize( ConfigurableApplicationContext applicationContext) { 
		// do whatever you want with applicationContext, 
		// e. g. applicationContext. registerShutdownHook();
	}
}

不过，一般情况下我们基本不会需要自定义一个ApplicationContextInitializer，即使SpringBoot框架默认也只是注册了三个实现：

org. springframework. context. ApplicationContextInitializer=\ 
org. springframework. boot. context. ConfigurationWarningsApplication- ContextInitializer,\ 
org. springframework. boot. context. ContextIdApplicationContextInitia- lizer,\ 
org. springframework. boot. context. config. DelegatingApplicationContex- tInitializer

如果我们真的需要自定义一个ApplicationContextInitializer，那么只要像上面这样，通过SpringFactoriesLoader机制进行配置，或者通过SpringApplication.addInitializers(…) 设置即可。

CommandLineRunner

CommandLineRunner不是Spring框架原有的“宝贝”，它属于SpringBoot应用特定的回调扩展接口：

public interface CommandLineRunner { 
	void run( String... args) throws Exception; 
}

CommandLineRunner需要大家关注的其实就两点：

所有CommandLineRunner的执行时点在SpringBoot应用的ApplicationContext完全初始化开始工作之后（可以认为是main方法执行完成之前最后一步）
只要存在于当前SpringBoot应用的ApplicationContext中的任何CommandLineRunner，都会被加载执行（不管你是手动注册这个CommandLineRunner到IoC容器，还是自动扫描进去的）

与其他几个扩展点接口类型相似，建议CommandLineRunner的实现类使用@org.springframework.core.annotation.Order进行标注或者实现org.springframework.core.Ordered接口，便于对它们的执行顺序进行调整，这其实十分重要，我们不希望顺序不当的CommandLineRunner实现类阻塞了后面其他CommandLineRunner的执行。

CommandLineRunner是很好的扩展接口，大家可以重点关注，我们在后面的扩展和微服务实践章节会再次遇到它。