SpringApplication

SpringApplication 类提供了一种方便的方式来引导从 main() 方法启动的 Spring 应用程序。在许多情况下，您可以委托给静态的 SpringApplication.run(Class, String…​) 方法，如下例所示

  • Java

  • Kotlin

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

	public static void main(String[] args) {
		SpringApplication.run(MyApplication.class, args);
	}

}
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication


@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
	runApplication<MyApplication>(*args)
}

当您的应用程序启动时，您应该看到类似以下的输出

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v4.0.0)

2025-11-20T16:37:28.294Z  INFO 128420 --- [           main] o.s.b.d.f.logexample.MyApplication       : Starting MyApplication using Java 25.0.1 with PID 128420 (/opt/apps/myapp.jar started by myuser in /opt/apps/)
2025-11-20T16:37:28.322Z  INFO 128420 --- [           main] o.s.b.d.f.logexample.MyApplication       : No active profile set, falling back to 1 default profile: "default"
2025-11-20T16:37:31.896Z  INFO 128420 --- [           main] o.s.boot.tomcat.TomcatWebServer          : Tomcat initialized with port 8080 (http)
2025-11-20T16:37:31.952Z  INFO 128420 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2025-11-20T16:37:31.953Z  INFO 128420 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/11.0.14]
2025-11-20T16:37:32.122Z  INFO 128420 --- [           main] b.w.c.s.WebApplicationContextInitializer : Root WebApplicationContext: initialization completed in 3543 ms
2025-11-20T16:37:33.770Z  INFO 128420 --- [           main] o.s.boot.tomcat.TomcatWebServer          : Tomcat started on port 8080 (http) with context path '/'
2025-11-20T16:37:33.799Z  INFO 128420 --- [           main] o.s.b.d.f.logexample.MyApplication       : Started MyApplication in 7.034 seconds (process running for 8.198)
2025-11-20T16:37:33.856Z  INFO 128420 --- [ionShutdownHook] o.s.boot.tomcat.GracefulShutdown         : Commencing graceful shutdown. Waiting for active requests to complete
2025-11-20T16:37:33.915Z  INFO 128420 --- [tomcat-shutdown] o.s.boot.tomcat.GracefulShutdown         : Graceful shutdown complete

默认情况下，会显示 INFO 级别的日志消息，包括一些相关的启动详细信息，例如启动应用程序的用户。如果需要 INFO 以外的日志级别，可以进行设置，如日志级别中所述。应用程序版本是使用主应用程序类包中的实现版本确定的。可以通过将 spring.main.log-startup-info 设置为 false 来关闭启动信息日志记录。这将同时关闭应用程序活动配置文件的日志记录。

要在启动期间添加额外的日志记录，您可以在 SpringApplication 的子类中覆盖 logStartupInfo(boolean)。

启动失败

如果您的应用程序启动失败，注册的 FailureAnalyzer bean 将有机会提供专门的错误消息和具体的解决问题的操作。例如，如果您在端口 8080 上启动一个 Web 应用程序，而该端口已被占用，您应该看到类似以下消息的内容

***************************
APPLICATION FAILED TO START
***************************

Description:

Embedded servlet container failed to start. Port 8080 was already in use.

Action:

Identify and stop the process that is listening on port 8080 or configure this application to listen on another port.
Spring Boot 提供了许多 FailureAnalyzer 实现，您可以添加您自己的。

如果没有失败分析器能够处理异常，您仍然可以显示完整的条件报告，以便更好地了解出了什么问题。为此，您需要启用 debug 属性或为 ConditionEvaluationReportLoggingListener 启用 DEBUG 日志记录。

例如，如果您正在使用 java -jar 运行应用程序，您可以按如下方式启用 debug 属性

$ java -jar myproject-0.0.1-SNAPSHOT.jar --debug

延迟初始化

SpringApplication 允许应用程序延迟初始化。当启用延迟初始化时，bean 会在需要时创建，而不是在应用程序启动期间创建。因此，启用延迟初始化可以减少应用程序启动所需的时间。在 Web 应用程序中，启用延迟初始化将导致许多与 Web 相关的 bean 直到接收到 HTTP 请求时才会被初始化。

延迟初始化的一个缺点是它可能会延迟应用程序问题的发现。如果一个配置错误的 bean 被延迟初始化，那么在启动期间将不再发生故障，并且只有在 bean 初始化时问题才会显现出来。还必须注意确保 JVM 有足够的内存来容纳应用程序的所有 bean，而不仅仅是那些在启动期间初始化的 bean。由于这些原因，默认情况下不启用延迟初始化，建议在启用延迟初始化之前对 JVM 的堆大小进行微调。

延迟初始化可以通过 SpringApplicationBuilder 上的 lazyInitialization 方法或 SpringApplication 上的 setLazyInitialization 方法以编程方式启用。或者，也可以使用 spring.main.lazy-initialization 属性启用，如下例所示

  • 属性

  • YAML

spring.main.lazy-initialization=true
spring:
  main:
    lazy-initialization: true
如果您希望禁用某些 bean 的延迟初始化，同时对应用程序的其余部分使用延迟初始化，则可以使用 @Lazy(false) 注解将它们的延迟属性显式设置为 false。

定制 Banner

可以通过在类路径中添加 banner.txt 文件或将 spring.banner.location 属性设置为此类文件的位置来更改启动时打印的 banner。如果文件的编码不是 UTF-8，您可以设置 spring.banner.charset。

在您的 banner.txt 文件中，您可以使用 Environment 中可用的任何键以及以下任何占位符

表 1. Banner 变量
变量 描述

${application.version}

您的应用程序的版本号，如 MANIFEST.MF 中声明。例如，Implementation-Version: 1.0 会打印为 1.0。

${application.formatted-version}

您的应用程序的版本号，如 MANIFEST.MF 中声明并格式化为显示（用括号括起来并加上 v 前缀）。例如 (v1.0)。

${spring-boot.version}

您正在使用的 Spring Boot 版本。例如 4.0.0。

${spring-boot.formatted-version}

您正在使用的 Spring Boot 版本，格式化为显示（用括号括起来并加上 v 前缀）。例如 (v4.0.0)。

${Ansi.NAME} (或 ${AnsiColor.NAME}, ${AnsiBackground.NAME}, ${AnsiStyle.NAME})

其中 NAME 是 ANSI 转义码的名称。有关详细信息，请参阅 AnsiPropertySource。

${application.title}

您的应用程序的标题，如 MANIFEST.MF 中声明。例如 Implementation-Title: MyApp 会打印为 MyApp。
如果要以编程方式生成 banner，可以使用 SpringApplication.setBanner(…​) 方法。使用 Banner 接口并实现您自己的 printBanner() 方法。

您还可以使用 spring.main.banner-mode 属性来确定 banner 是打印到 System.out (console)、发送到配置的日志记录器 (log) 还是根本不生成 (off)。

打印的 banner 作为单例 bean 注册，名称为：springBootBanner。

application.title、application.version 和 application.formatted-version 属性仅在使用 java -jar 或带有 Spring Boot 启动器的 java -cp 时可用。如果您运行的是未打包的 jar 并使用 java -cp <classpath> <mainclass> 启动它，或者将应用程序作为本地镜像运行，则这些值将无法解析。

要使用 application.* 属性，请使用 java -jar 作为打包的 jar 启动您的应用程序，或使用 java org.springframework.boot.loader.launch.JarLauncher 作为未打包的 jar 启动。这将在构建类路径和启动您的应用程序之前初始化 application.* banner 属性。

定制 SpringApplication

如果 SpringApplication 的默认设置不符合您的喜好，您可以创建一个本地实例并进行定制。例如，要关闭 banner，您可以这样编写

  • Java

  • Kotlin

import org.springframework.boot.Banner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

	public static void main(String[] args) {
		SpringApplication application = new SpringApplication(MyApplication.class);
		application.setBannerMode(Banner.Mode.OFF);
		application.run(args);
	}

}
import org.springframework.boot.Banner
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication

@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
	runApplication<MyApplication>(*args) {
		setBannerMode(Banner.Mode.OFF)
	}
}
传递给 SpringApplication 的构造函数参数是 Spring bean 的配置源。在大多数情况下，它们是对 @Configuration 类的引用，但它们也可以是 @Component 类的直接引用。

也可以通过使用 application.properties 文件来配置 SpringApplication。有关详细信息，请参阅外部化配置。

有关配置选项的完整列表，请参阅 SpringApplication API 文档。

流畅的构建器 API

如果您需要构建 ApplicationContext 层次结构（具有父/子关系的多个上下文），或者如果您更喜欢使用流畅的构建器 API，则可以使用 SpringApplicationBuilder。

SpringApplicationBuilder 允许您将多个方法调用链式连接起来，并包含 parent 和 child 方法，让您创建层次结构，如下例所示

  • Java

  • Kotlin

		new SpringApplicationBuilder().sources(Parent.class)
			.child(Application.class)
			.bannerMode(Banner.Mode.OFF)
			.run(args);
		SpringApplicationBuilder()
			.sources(Parent::class.java)
			.child(Application::class.java)
			.bannerMode(Banner.Mode.OFF)
			.run(*args)
在创建 ApplicationContext 层次结构时存在一些限制。例如，Web 组件必须包含在子上下文中，并且父子上下文使用相同的 Environment。有关完整详细信息，请参阅 SpringApplicationBuilder API 文档。

应用程序可用性

当部署在平台上时，应用程序可以使用 Kubernetes 探针等基础设施向平台提供有关其可用性的信息。Spring Boot 提供了对常用“活跃度（liveness）”和“就绪度（readiness）”可用性状态的开箱即用支持。如果您正在使用 Spring Boot 的“执行器”支持，那么这些状态会作为健康端点组暴露。

此外，您还可以通过将 ApplicationAvailability 接口注入到您自己的 bean 中来获取可用性状态。

活跃度状态

应用程序的“活跃度”状态表示其内部状态是否允许其正常工作，或者在当前失败时是否能够自行恢复。“活跃度”状态损坏意味着应用程序处于无法恢复的状态，基础设施应该重新启动应用程序。

通常，“活跃度”状态不应基于外部检查，例如健康检查。如果这样做，一个失败的外部系统（数据库、Web API、外部缓存）将触发大规模重启和整个平台的级联故障。

Spring Boot 应用程序的内部状态主要由 Spring ApplicationContext 表示。如果应用程序上下文已成功启动，Spring Boot 会假定应用程序处于有效状态。一旦上下文刷新完成，应用程序就被认为是活跃的，请参阅Spring Boot 应用程序生命周期和相关应用程序事件。

就绪度状态

应用程序的“就绪度”状态表示应用程序是否准备好处理流量。失败的“就绪度”状态告诉平台目前不应将流量路由到该应用程序。这通常发生在启动期间，同时 CommandLineRunner 和 ApplicationRunner 组件正在处理，或者在应用程序认为自己太忙而无法处理额外流量的任何时候。

一旦应用程序和命令行运行器被调用，应用程序就被认为是就绪的，请参阅Spring Boot 应用程序生命周期和相关应用程序事件。

预期在启动期间运行的任务应由 CommandLineRunner 和 ApplicationRunner 组件执行，而不是使用 Spring 组件生命周期回调，例如 @PostConstruct。

管理应用程序可用性状态

应用程序组件可以通过注入 ApplicationAvailability 接口并调用其上的方法，随时检索当前的可用性状态。更常见的是，应用程序会希望监听状态更新或更新应用程序的状态。

例如，我们可以将应用程序的“就绪度”状态导出到一个文件，以便 Kubernetes 的“exec Probe”可以查看此文件

  • Java

  • Kotlin

import org.springframework.boot.availability.AvailabilityChangeEvent;
import org.springframework.boot.availability.ReadinessState;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

@Component
public class MyReadinessStateExporter {

	@EventListener
	public void onStateChange(AvailabilityChangeEvent<ReadinessState> event) {
		switch (event.getState()) {
			case ACCEPTING_TRAFFIC -> {
				// create file /tmp/healthy
			}
			case REFUSING_TRAFFIC -> {
				// remove file /tmp/healthy
			}
		}
	}

}
import org.springframework.boot.availability.AvailabilityChangeEvent
import org.springframework.boot.availability.ReadinessState
import org.springframework.context.event.EventListener
import org.springframework.stereotype.Component

@Component
class MyReadinessStateExporter {

	@EventListener
	fun onStateChange(event: AvailabilityChangeEvent<ReadinessState>) {
		when (event.state) {
			ReadinessState.ACCEPTING_TRAFFIC -> {
				// create file /tmp/healthy
			}
			ReadinessState.REFUSING_TRAFFIC -> {
				// remove file /tmp/healthy
			}
		}
	}

}

当应用程序损坏且无法恢复时，我们还可以更新应用程序的状态

  • Java

  • Kotlin

import org.springframework.boot.availability.AvailabilityChangeEvent;
import org.springframework.boot.availability.LivenessState;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Component;

@Component
public class MyLocalCacheVerifier {

	private final ApplicationEventPublisher eventPublisher;

	public MyLocalCacheVerifier(ApplicationEventPublisher eventPublisher) {
		this.eventPublisher = eventPublisher;
	}

	public void checkLocalCache() {
		try {
			// ...
		}
		catch (CacheCompletelyBrokenException ex) {
			AvailabilityChangeEvent.publish(this.eventPublisher, ex, LivenessState.BROKEN);
		}
	}

}
import org.springframework.boot.availability.AvailabilityChangeEvent
import org.springframework.boot.availability.LivenessState
import org.springframework.context.ApplicationEventPublisher
import org.springframework.stereotype.Component

@Component
class MyLocalCacheVerifier(private val eventPublisher: ApplicationEventPublisher) {

	fun checkLocalCache() {
		try {
			// ...
		} catch (ex: CacheCompletelyBrokenException) {
			AvailabilityChangeEvent.publish(eventPublisher, ex, LivenessState.BROKEN)
		}
	}

}

Spring Boot 提供了带有执行器健康端点的 Kubernetes HTTP 探针，用于“活跃度”和“就绪度”。您可以在专门章节中获取有关在 Kubernetes 上部署 Spring Boot 应用程序的更多指导。

应用程序事件和监听器

除了通常的 Spring 框架事件，例如 ContextRefreshedEvent，SpringApplication 还会发送一些额外的应用程序事件。

有些事件实际上是在 ApplicationContext 创建之前触发的，因此您不能将这些事件的监听器注册为 @Bean。您可以使用 SpringApplication.addListeners(…​) 方法或 SpringApplicationBuilder.listeners(…​) 方法注册它们。

如果您希望这些监听器自动注册，无论应用程序是如何创建的，您可以在您的项目中添加一个 META-INF/spring.factories 文件，并使用 ApplicationListener 键引用您的监听器，如下例所示

org.springframework.context.ApplicationListener=com.example.project.MyListener

应用程序事件按以下顺序发送，随着应用程序的运行

  1. 在运行开始时发送 ApplicationStartingEvent，但在注册监听器和初始化器之外的任何处理之前。

  2. 当在上下文中使用的 Environment 已知但在上下文创建之前，发送 ApplicationEnvironmentPreparedEvent。

  3. 当 ApplicationContext 准备好并且 ApplicationContextInitializers 已被调用但任何 bean 定义尚未加载之前，发送 ApplicationContextInitializedEvent。

  4. 在刷新开始之前，但在 bean 定义加载之后，发送 ApplicationPreparedEvent。

  5. 在上下文刷新之后，但在任何应用程序和命令行运行器被调用之前，发送 ApplicationStartedEvent。

  6. 紧接着发送一个 AvailabilityChangeEvent，其中包含 LivenessState.CORRECT，表示应用程序被认为是活跃的。

  7. 在任何应用程序和命令行运行器被调用之后，发送 ApplicationReadyEvent。

  8. 紧接着发送一个 AvailabilityChangeEvent，其中包含 ReadinessState.ACCEPTING_TRAFFIC，表示应用程序已准备好处理请求。

  9. 如果在启动时出现异常，则发送 ApplicationFailedEvent。

上述列表仅包含与 SpringApplication 相关的 SpringApplicationEvent。除了这些事件之外，在 ApplicationPreparedEvent 之后和 ApplicationStartedEvent 之前还会发布以下事件

您通常不需要使用应用程序事件，但了解它们的存在会很有用。在内部，Spring Boot 使用事件来处理各种任务。
事件监听器不应运行可能耗时的任务，因为它们默认在同一线程中执行。请考虑改用应用程序和命令行运行器。

应用程序事件通过使用 Spring Framework 的事件发布机制发送。该机制的一部分确保发布到子上下文中的监听器的事件也会发布到任何祖先上下文中的监听器。因此，如果您的应用程序使用 SpringApplication 实例的层次结构，监听器可能会收到相同类型应用程序事件的多个实例。

为了让您的监听器能够区分其上下文的事件和后代上下文的事件，它应该请求注入其应用程序上下文，然后将注入的上下文与事件的上下文进行比较。可以通过实现 ApplicationContextAware 或（如果监听器是一个 bean）通过使用 @Autowired 来注入上下文。

Web 环境

SpringApplication 尝试代表您创建正确类型的 ApplicationContext。用于确定 WebApplicationType 的算法如下

这意味着如果您在同一个应用程序中同时使用 Spring MVC 和 Spring WebFlux 中的新 WebClient，则默认会使用 Spring MVC。您可以通过调用 setWebApplicationType(WebApplicationType) 轻松覆盖此行为。

还可以通过调用 setApplicationContextFactory(…​) 来完全控制使用的 ApplicationContext 类型。

在使用 JUnit 测试中的 SpringApplication 时，通常需要调用 setWebApplicationType(WebApplicationType.NONE)。

访问应用程序参数

如果您需要访问传递给 SpringApplication.run(…​) 的应用程序参数，可以注入 ApplicationArguments bean。ApplicationArguments 接口提供了对原始 String[] 参数以及解析后的 option 和 non-option 参数的访问，如下例所示

  • Java

  • Kotlin

import java.util.List;

import org.springframework.boot.ApplicationArguments;
import org.springframework.stereotype.Component;

@Component
public class MyBean {

	public MyBean(ApplicationArguments args) {
		boolean debug = args.containsOption("debug");
		List<String> files = args.getNonOptionArgs();
		if (debug) {
			System.out.println(files);
		}
		// if run with "--debug logfile.txt" prints ["logfile.txt"]
	}

}
import org.springframework.boot.ApplicationArguments
import org.springframework.stereotype.Component

@Component
class MyBean(args: ApplicationArguments) {

	init {
		val debug = args.containsOption("debug")
		val files = args.nonOptionArgs
		if (debug) {
			println(files)
		}
		// if run with "--debug logfile.txt" prints ["logfile.txt"]
	}

}
Spring Boot 还会在 Spring Environment 中注册一个 CommandLinePropertySource。这让您也可以使用 @Value 注解注入单个应用程序参数。

使用 ApplicationRunner 或 CommandLineRunner

如果需要在 SpringApplication 启动后运行一些特定的代码，您可以实现 ApplicationRunner 或 CommandLineRunner 接口。这两个接口的工作方式相同，都提供了一个 run 方法，该方法在 SpringApplication.run(…​) 完成之前被调用。

此契约非常适合在应用程序启动后但在开始接受流量之前运行的任务。

CommandLineRunner 接口以字符串数组形式提供对应用程序参数的访问，而 ApplicationRunner 使用前面讨论的 ApplicationArguments 接口。以下示例展示了一个带有 run 方法的 CommandLineRunner

  • Java

  • Kotlin

import org.springframework.boot.CommandLineRunner;
import org.springframework.stereotype.Component;

@Component
public class MyCommandLineRunner implements CommandLineRunner {

	@Override
	public void run(String... args) {
		// Do something...
	}

}
import org.springframework.boot.CommandLineRunner
import org.springframework.stereotype.Component

@Component
class MyCommandLineRunner : CommandLineRunner {

	override fun run(vararg args: String) {
		// Do something...
	}

}

如果定义了多个 CommandLineRunner 或 ApplicationRunner bean 并且必须以特定顺序调用，您可以另外实现 Ordered 接口或使用 Order 注解。

应用程序退出

每个 SpringApplication 都会向 JVM 注册一个关闭钩子，以确保 ApplicationContext 在退出时优雅地关闭。所有标准的 Spring 生命周期回调（例如 DisposableBean 接口或 @PreDestroy 注解）都可以使用。

此外，bean 可以实现 ExitCodeGenerator 接口，如果它们希望在调用 SpringApplication.exit() 时返回特定的退出码。然后，此退出码可以传递给 System.exit() 以将其作为状态码返回，如下例所示

  • Java

  • Kotlin

import org.springframework.boot.ExitCodeGenerator;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class MyApplication {

	@Bean
	public ExitCodeGenerator exitCodeGenerator() {
		return () -> 42;
	}

	public static void main(String[] args) {
		System.exit(SpringApplication.exit(SpringApplication.run(MyApplication.class, args)));
	}

}
import org.springframework.boot.ExitCodeGenerator
import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.context.annotation.Bean

import kotlin.system.exitProcess

@SpringBootApplication
class MyApplication {

	@Bean
	fun exitCodeGenerator() = ExitCodeGenerator { 42 }

}

fun main(args: Array<String>) {
	exitProcess(SpringApplication.exit(
		runApplication<MyApplication>(*args)))
}

此外，ExitCodeGenerator 接口可以由异常实现。当遇到此类异常时，Spring Boot 会返回由实现的 getExitCode() 方法提供的退出码。

如果存在多个 ExitCodeGenerator，则使用生成的第一个非零退出码。要控制生成器调用的顺序，可以另外实现 Ordered 接口或使用 Order 注解。

管理功能

可以通过指定 spring.application.admin.enabled 属性来启用应用程序的管理相关功能。这会将 SpringApplicationAdminMXBean 暴露在平台 MBeanServer 上。您可以使用此功能远程管理您的 Spring Boot 应用程序。此功能对于任何服务包装器实现也可能很有用。

如果您想知道应用程序正在哪个 HTTP 端口上运行，请获取键为 local.server.port 的属性。

应用程序启动跟踪

在应用程序启动期间，SpringApplication 和 ApplicationContext 执行许多与应用程序生命周期、bean 生命周期甚至处理应用程序事件相关的任务。借助 ApplicationStartup，Spring Framework 允许您使用 StartupStep 对象跟踪应用程序启动序列。此数据可以用于分析目的，或者只是为了更好地了解应用程序的启动过程。

您可以在设置 SpringApplication 实例时选择一个 ApplicationStartup 实现。例如，要使用 BufferingApplicationStartup，您可以这样编写

  • Java

  • Kotlin

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup;

@SpringBootApplication
public class MyApplication {

	public static void main(String[] args) {
		SpringApplication application = new SpringApplication(MyApplication.class);
		application.setApplicationStartup(new BufferingApplicationStartup(2048));
		application.run(args);
	}

}
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup
import org.springframework.boot.runApplication

@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
	runApplication<MyApplication>(*args) {
		applicationStartup = BufferingApplicationStartup(2048)
	}
}

Spring Framework 提供了第一个可用的实现 FlightRecorderApplicationStartup。它将 Spring 特定的启动事件添加到 Java Flight Recorder 会话中，旨在分析应用程序并将其 Spring 上下文生命周期与 JVM 事件（如分配、GC、类加载等）关联起来。配置完成后，您可以通过启用 Flight Recorder 运行应用程序来记录数据

$ java -XX:StartFlightRecording:filename=recording.jfr,duration=10s -jar demo.jar

Spring Boot 附带了 BufferingApplicationStartup 变体；此实现旨在缓冲启动步骤并将其排入外部指标系统。应用程序可以在任何组件中请求类型为 BufferingApplicationStartup 的 bean。

Spring Boot 还可以配置为暴露一个 startup 端点，该端点将此信息作为 JSON 文档提供。

虚拟线程

虚拟线程需要 Java 21 或更高版本。为了获得最佳体验，强烈建议使用 Java 24 或更高版本。要启用虚拟线程，请将 spring.threads.virtual.enabled 属性设置为 true。

在为您的应用程序启用此选项之前，您应该考虑阅读官方 Java 虚拟线程文档。在某些情况下，应用程序可能会因为“固定虚拟线程”而导致吞吐量降低；此页面还解释了如何使用 JDK Flight Recorder 或 jcmd CLI 检测此类情况。

如果启用了虚拟线程，配置线程池的属性将不再起作用。这是因为虚拟线程是在 JVM 范围内的平台线程池上调度的，而不是在专用的线程池上。
虚拟线程的一个副作用是它们是守护线程。如果 JVM 的所有线程都是守护线程，JVM 将退出。当您依赖 @Scheduled bean 来保持应用程序运行等情况时，这种行为可能会成为问题。如果您使用虚拟线程，调度器线程是一个虚拟线程，因此也是一个守护线程，不会保持 JVM 运行。这不仅影响调度，也可能发生在其他技术中。为了在所有情况下保持 JVM 运行，建议将属性 spring.main.keep-alive 设置为 true。这确保了即使所有线程都是虚拟线程，JVM 也能保持运行。
© . This site is unofficial and not affiliated with VMware.