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

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 一张图帮你记忆,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 bean,它将会在应用成功启动之后调用 run() 方法,并传递用于启动应用程序的命令行参数


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


mvn clean package


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


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


查看运行结果:


微信图片_20220510155610.jpg


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


  1. 命令行传入的参数并没有被解析,而只是显示出我们传入的字符串内容 --foo=bar--name=rgyb,我们可以通过 ApplicationRunner 解析,我们稍后看


  1. 在重写的 run() 方法上有 throws Exception 标记,Spring Boot 会将 CommandLineRunner 作为应用启动的一部分,如果运行 run() 方法时抛出 Exception,应用将会终止启动


  1. 我们在类上添加了 @Order(2) 注解,当有多个 CommandLineRunner 时,将会按照 @Order 注解中的数字从小到大排序 (数字当然也可以用复数)


⚠️不要使用 @Order 太多


看到 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


运行结果如下:


微信图片_20220510155740.jpg


到这里我们可以看出:


  1. MyCommandLineRunner 相似,但 ApplicationRunner 可以通过 run 方法的 ApplicationArguments 对象解析出命令行参数,并且每个参数可以有多个值在里面,因为 getOptionValues 方法返回 List 数组


  1. 在重写的 run() 方法上有 throws Exception 标记,Spring Boot 会将 CommandLineRunner 作为应用启动的一部分,如果运行 run() 方法时抛出 Exception,应用将会终止启动


  1. 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");
    }
}


运行程序查看结果:


微信图片_20220510155823.jpg


到这我们可以看出:


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


  1. 代码中我用 Order(0) 来标记,显然 ApplicationListener 也是可以用该注解进行排序的,按数字大小排序,应该是最先执行。但是,这个顺序仅用于同类型的 ApplicationListener 之间的排序,与前面提到的 ApplicationRunnersCommandLineRunners 的排序并不共享


小结


如果我们不需要获取命令行参数,我们可以通过 ApplicationListener 创建一些全局的启动逻辑,我们还可以通过它获取 Spring Boot 支持的 configuration properties 环境变量参数

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





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


@PostConstruct


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


@Component
@Slf4j
@DependsOn("myApplicationListener")
public class MyPostConstructBean {
    @PostConstruct
    public void testPostConstruct(){
        log.info("MyPostConstructBean");
    }
}


查看运行结果:


微信图片_20220510160118.jpg


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


  1. Spring 创建完 bean之后 (在启动之前),便会立即调用 @PostConstruct 注解标记的方法,因此我们无法使用 @Order 注解对其进行自由排序,因为它可能依赖于 @Autowired 插入到我们 bean 中的其他 Spring bean。


  1. 相反,它将在依赖于它的所有 bean 被初始化之后被调用,如果要添加人为的依赖关系并由此创建一个排序,则可以使用 @DependsOn 注解(虽然可以排序,但是不建议使用,理由和 @Order 一样)


小结


@PostConstruct 方法固有地绑定到现有的 Spring bean,因此应仅将其用于此单个 bean 的初始化逻辑;


InitializingBean


@PostConstruct 解决方案非常相似,我们可以实现 InitializingBean 接口,并让 Spring 调用某个初始化方法:


@Component
@Slf4j
public class MyInitializingBean implements InitializingBean {
    @Override
    public void afterPropertiesSet() throws Exception {
        log.info("MyInitializingBean.afterPropertiesSet()");
    }
}


查看运行结果:


微信图片_20220510160257.jpg


从上面的运行结果中,我们得到了和 @PostConstruct 一样的效果,但二者还是有差别的


⚠️ @PostConstructafterPropertiesSet 区别


  1. afterPropertiesSet,顾名思义「在属性设置之后」,调用该方法时,该 bean 的所有属性已经被 Spring 填充。如果我们在某些属性上使用 @Autowired(常规操作应该使用构造函数注入),那么 Spring 将在调用afterPropertiesSet 之前将 bean 注入这些属性。但 @PostConstruct 并没有这些属性填充限制


  1. 所以 InitializingBean.afterPropertiesSet 解决方案比使用 @PostConstruct 更安全,因为如果我们依赖尚未自动注入的 @Autowired 字段,则 @PostConstruct 方法可能会遇到 NullPointerExceptions


小结


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


源码分析


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


MyCommandLineRunnerApplicationRunner 是在何时被调用的呢?


打开 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 的全部代码,Spring Boot 启动过程及原理都可以从这个类中找到一些答案


总结



最后画一张图用来总结这几种方式(高清大图请查看原文:https://dayarch.top/p/spring-...


微信图片_20220510160353.png


灵魂追问


  1. 上面程序运行结果, afterPropertiesSet 方法调用先于 @PostConstruct 方法,但这和我们在 Spring Bean 生命周期之缘起 中的调用顺序恰恰相反,你知道为什么吗?


  1. MyPostConstructBean 通过 @DependsOn("myApplicationListener") 依赖了 MyApplicationListener,为什么调用结果前者先与后者呢?


  1. 为什么不建议 @Autowired 形式依赖注入

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

目录
打赏
0
0
1
1
1
分享
相关文章
Spring Boot 两种部署到服务器的方式
本文介绍了Spring Boot项目的两种部署方式:jar包和war包。Jar包方式使用内置Tomcat,只需配置JDK 1.8及以上环境,通过`nohup java -jar`命令后台运行,并开放服务器端口即可访问。War包则需将项目打包后放入外部Tomcat的webapps目录,修改启动类继承`SpringBootServletInitializer`并调整pom.xml中的打包类型为war,最后启动Tomcat访问应用。两者各有优劣,jar包更简单便捷,而war包适合传统部署场景。需要注意的是,war包部署时,内置Tomcat的端口配置不会生效。
99 17
Spring Boot 两种部署到服务器的方式
【潜意识Java】javaee中的SpringBoot在Java 开发中的应用与详细分析
本文介绍了 Spring Boot 的核心概念和使用场景,并通过一个实战项目演示了如何构建一个简单的 RESTful API。
27 5
Spring AI Alibaba + 通义千问,开发AI应用如此简单!!!
本文介绍了如何使用Spring AI Alibaba开发一个简单的AI对话应用。通过引入`spring-ai-alibaba-starter`依赖和配置API密钥,结合Spring Boot项目,只需几行代码即可实现与AI模型的交互。具体步骤包括创建Spring Boot项目、编写Controller处理对话请求以及前端页面展示对话内容。此外,文章还介绍了如何通过添加对话记忆功能,使AI能够理解上下文并进行连贯对话。最后,总结了Spring AI为Java开发者带来的便利,简化了AI应用的开发流程。
416 0
|
14天前
|
SpringBoot整合Flowable【04】- 通过代码控制流程流转
本文介绍了如何使用Flowable的Java API控制流程流转,基于前文构建的绩效流程模型。首先,通过Flowable-UI导出模型文件并部署到Spring Boot项目中。接着,详细讲解了如何通过代码部署、启动和审批流程,涉及`RepositoryService`、`RuntimeService`和`TaskService`等核心服务类的使用。最后,通过实际操作演示了流程从部署到完成的全过程,并简要说明了相关数据库表的变化。本文帮助读者初步掌握Flowable在实际业务中的应用,后续将深入探讨更多高级功能。
41 0
Spring Core核心类库的功能与应用实践分析
【12月更文挑战第1天】大家好,今天我们来聊聊Spring Core这个强大的核心类库。Spring Core作为Spring框架的基础,提供了控制反转(IOC)和依赖注入(DI)等核心功能,以及企业级功能,如JNDI和定时任务等。通过本文,我们将从概述、功能点、背景、业务点、底层原理等多个方面深入剖析Spring Core,并通过多个Java示例展示其应用实践,同时指出对应实践的优缺点。
67 14
Spring MVC:深入理解与应用实践
Spring MVC是Spring框架提供的一个用于构建Web应用程序的Model-View-Controller(MVC)实现。它通过分离业务逻辑、数据、显示来组织代码,使得Web应用程序的开发变得更加简洁和高效。本文将从概述、功能点、背景、业务点、底层原理等多个方面深入剖析Spring MVC,并通过多个Java示例展示其应用实践,同时指出对应实践的优缺点。
102 2
|
2月前
|
Spring Boot 应用如何实现 JWT 认证?
Spring Boot 应用如何实现 JWT 认证?
97 8
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
76 1
Spring运维之boot项目多环境(yaml 多文件 proerties)及分组管理与开发控制
通过以上措施,可以保证Spring Boot项目的配置管理在专业水准上,并且易于维护和管理,符合搜索引擎收录标准。
66 2

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等