一张图帮你记忆，Spring Boot 应用在启动阶段执行代码的几种方式

前言

有时候我们需要在应用启动时执行一些代码片段，这些片段可能是仅仅是为了记录 log，也可能是在启动时检查与安装证书 ，诸如上述业务要求我们可能会经常碰到

Spring Boot 提供了至少 5 种方式用于在应用启动时执行代码。我们应该如何选择？本文将会逐步解释与分析这几种不同方式

CommandLineRunner

CommandLineRunner

Spring 应用成功启动之后

@Slf4j
@Component
@Order(2)
public class MyCommandLineRunner implements CommandLineRunner {

@Override
public void run(String... args) throws Exception {
log.info("MyCommandLineRunner order is 2");
if (args.length > 0){
for (int i = 0; i < args.length; i++) {
log.info("MyCommandLineRunner current parameter is: {}", args[i]);
}
}
}
}

当 Spring Boot 在应用上下文中找到

CommandLineRunner

run()

通过如下 maven 命令生成 jar 包:

mvn clean package

通过终端命令启动应用，并传递参数:

java -jar springboot-application-startup-0.0.1-SNAPSHOT.jar --foo=bar --name=rgyb

查看运行结果:

到这里我们可以看出几个问题:

1. 命令行传入的参数并没有被解析，而只是显示出我们传入的字符串内容

   --foo=bar

   ，

   --name=rgyb

   ，我们可以通过

   ApplicationRunner

   解析，我们稍后看
2. 在重写的

   run()

   方法上有

   throws Exception

   标记，Spring Boot 会将

   CommandLineRunner

   作为应用启动的一部分，如果运行

   run()

   方法时抛出 Exception，应用将会终止启动
3. 我们在类上添加了

   @Order(2)

   注解，当有多个

   CommandLineRunner

   时，将会按照

   @Order

   注解中的数字从小到大排序 (数字当然也可以用复数)

小结

如果我们只是想简单的获取以空格分隔的命令行参数，那

MyCommandLineRunner

ApplicationRunner

上面提到，通过命令行启动并传递参数，

MyCommandLineRunner

ApplicationRunner

@Component
@Slf4j
@Order(1)
public class MyApplicationRunner implements ApplicationRunner {

@Override
public void run(ApplicationArguments args) throws Exception {
log.info("MyApplicationRunner order is 1");
log.info("MyApplicationRunner Current parameter is {}:", args.getOptionValues("foo"));
}
}

重新打 jar 包，运行如下命令:

java -jar springboot-application-startup-0.0.1-SNAPSHOT.jar --foo=bar,rgyb

运行结果如下:

到这里我们可以看出:

1. 同

   MyCommandLineRunner

   相似，但

   ApplicationRunner

   可以通过 run 方法的

   ApplicationArguments

   对象解析出命令行参数，并且每个参数可以有多个值在里面，因为

   getOptionValues

   方法返回 List 数组
2. 在重写的

   run()

   方法上有

   throws Exception

   标记，Spring Boot 会将

   CommandLineRunner

   作为应用启动的一部分，如果运行

   run()

   方法时抛出 Exception，应用将会终止启动

3. ApplicationRunner

   也可以使用

   @Order

   注解进行排序，从启动结果来看，它与

   CommandLineRunner

   共享 order 的顺序，稍后我们通过源码来验证这个结论

小结

如果我们想获取复杂的命令行参数时，我们可以使用

ApplicationRunner

ApplicationListener

如果我们不需要获取命令行参数时，我们可以将启动逻辑绑定到 Spring 的

ApplicationReadyEvent

@Slf4j
@Component
@Order(0)
public class MyApplicationListener implements ApplicationListener<ApplicationReadyEvent> {

@Override
public void onApplicationEvent(ApplicationReadyEvent applicationReadyEvent) {
log.info("MyApplicationListener is started up");
}
}

运行程序查看结果:

到这我们可以看出:

1. ApplicationReadyEvent

   当且仅当 在应用程序就绪之后才被触发，甚至是说上面的 Listener 要在本文说的所有解决方案都执行了之后才会被触发，最终结论请稍后看
2. 代码中我用

   Order(0)

   来标记，显然 ApplicationListener 也是可以用该注解进行排序的，按数字大小排序，应该是最先执行。但是，这个顺序仅用于同类型的 ApplicationListener 之间的排序，与前面提到的

   ApplicationRunners

   和

   CommandLineRunners

   的排序并不共享

小结

如果我们不需要获取命令行参数，我们可以通过

ApplicationListener<ApplicationReadyEvent>

如果你看过我之前写的 Spring Bean 生命周期三部曲:

• Spring Bean 生命周期之缘起
• Spring Bean 生命周期之缘尽
• Spring Aware 到底是什么？

那么你会对下面两种方式非常熟悉了

@PostConstruct

创建启动逻辑的另一种简单解决方案是提供一种在 bean 创建期间由 Spring 调用的初始化方法。我们要做的就只是将

@PostConstruct

@Component
@Slf4j
@DependsOn("myApplicationListener")
public class MyPostConstructBean {

@PostConstruct
public void testPostConstruct(){
log.info("MyPostConstructBean");
}
}

查看运行结果:

从上面运行结果可以看出:

1. Spring 创建完 bean之后 (在启动之前)，便会立即调用

   @PostConstruct

   注解标记的方法，因此我们无法使用

   @Order

   注解对其进行自由排序，因为它可能依赖于

   @Autowired

   插入到我们 bean 中的其他 Spring bean。
2. 相反，它将在依赖于它的所有 bean 被初始化之后被调用，如果要添加人为的依赖关系并由此创建一个排序，则可以使用

   @DependsOn

   注解（虽然可以排序，但是不建议使用，理由和

   @Order

   一样）

小结

@PostConstruct

InitializingBean

与

@PostConstruct

InitializingBean

@Component
@Slf4j
public class MyInitializingBean implements InitializingBean {

@Override
public void afterPropertiesSet() throws Exception {
log.info("MyInitializingBean.afterPropertiesSet()");
}
}

查看运行结果:

从上面的运行结果中，我们得到了和

@PostConstruct

小结

如果我们使用构造函数注入，则这两种解决方案都是等效的

源码分析

请打开你的 IDE (重点代码已标记注释):

MyCommandLineRunner

ApplicationRunner

打开

SpringApplication.java

callRunners

private void callRunners(ApplicationContext context, ApplicationArguments args) {
List<Object> runners = new ArrayList<>();
//从上下文获取 ApplicationRunner 类型的 bean
runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());

//从上下文获取 CommandLineRunner 类型的 bean
runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());

//对二者进行排序，这也就是为什么二者的 order 是可以共享的了
AnnotationAwareOrderComparator.sort(runners);

//遍历对其进行调用
for (Object runner : new LinkedHashSet<>(runners)) {
if (runner instanceof ApplicationRunner) {
callRunner((ApplicationRunner) runner, args);
}
if (runner instanceof CommandLineRunner) {
callRunner((CommandLineRunner) runner, args);
}
}
}

强烈建议完整看一下

SpringApplication.java

总结

最后画一张图用来总结这几种方式（高清大图请查看原文：https://dayarch.top/p/spring-boot-execute-on-startup.html）

灵魂追问

1. 上面程序运行结果，

   afterPropertiesSet

   方法调用先于

   @PostConstruct

   方法，但这和我们在 Spring Bean 生命周期之缘起 中的调用顺序恰恰相反，你知道为什么吗？

2. MyPostConstructBean

   通过

   @DependsOn("myApplicationListener")

   依赖了 MyApplicationListener，为什么调用结果前者先与后者呢？
3. 为什么不建议

   @Autowired

   形式依赖注入

在写 Spring Bean 生命周期时就有朋友问我与之相关的问题，显然他们在概念上有一些含混，所以，仔细理解上面的问题将会帮助你加深对 Spring Bean 生命周期的理解