iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SpringApplication.run(MyApplication.class, args) coordinates a startup lifecycle; it is not a single command that instantly starts a server. Spring Boot prepares arguments and configuration, creates and refreshes an application context, runs startup callbacks, then marks the application ready and returns the context. For a web application, server initialization happens during context refresh—before startup runners finish and before readiness is announced.
This walkthrough follows the Spring Boot 4.1.1 reference documentation and the 4.1.1 source sequence surfaced for this topic. Treat the implementation ordering as a map of that release, not a guarantee that every internal call stays identical across versions. The API page available for this topic is for 4.2.0-M2, a milestone; version-specific details from it are not mixed into this stable-version account.
How the call enters the lifecycle
Java and Kotlin entry points
A Java application commonly calls SpringApplication.run(MyApplication.class, args) from main. Kotlin can use runApplication<MyApplication>(*args). The static Java helper applies Spring Boot’s default settings and returns the running ConfigurableApplicationContext. To customize startup before running it, create a SpringApplication, set the desired options, and call its instance run method.
Bootstrap support and listeners
In the Spring Boot 4.1.1 source sequence, startup begins by creating bootstrap support, invoking bootstrap registry initializers, configuring headless mode, discovering run listeners, and notifying them that startup is beginning. These are framework setup steps around the application, before the main context is created; they are not the same thing as creating application beans.
#1 Best Overall
How arguments and configuration are prepared
Spring Boot creates an ApplicationArguments object from the supplied arguments and prepares the Environment before it creates the application context. The arguments are available in two useful forms: as parsed options and non-option arguments through ApplicationArguments, and as a command-line property source that can participate in configuration. Profiles and property sources can also be customized through SpringApplication configuration.
That order matters: configuration is established before the context is selected and prepared, so the context and the beans it loads can use the prepared environment. If an early listener needs to observe environment preparation, register it through SpringApplication’s listener mechanisms; a listener declared as a bean cannot observe events published before the context exists.
How Spring Boot chooses an application context
Spring Boot infers the application type from the classpath unless the application explicitly overrides the type or context factory. The documented default distinction is:
Recommended Free Tools
| Classpath condition | Inferred context |
|---|---|
| Spring MVC is present | Servlet web application context |
| Spring MVC is absent and Spring WebFlux is present | Reactive web application context |
| Neither web stack is present | Regular annotation-config application context |
The 4.1.1 source sequence places banner printing before context creation. The banner is visible startup output, not evidence that the context has refreshed or that the application can accept traffic.
What happens while the context is prepared
The primary source is usually the main configuration class, but supported source forms also include classes, packages, XML, and Groovy. During preparation, Spring Boot associates the environment with the context, applies initializers and listeners, loads bean definitions, and publishes lifecycle events. This is a useful description of the phase, not a claim that every internal operation has one immutable order in all releases.
ApplicationContextInitializedEventis published after initializers have run and before bean definitions are loaded.ApplicationPreparedEventis published after bean definitions have been loaded and before context refresh.
Why context refresh is the major boundary
Spring Boot asks the context to refresh. The API summary describes refresh as loading singleton beans, while web-server initialization for a web application also occurs as part of this refresh interval. The exact internals of refresh belong to Spring Framework and are not reduced here to a fixed sequence of internal method calls.
For a web application, the documented event order places WebServerInitializedEvent and ContextRefreshedEvent after ApplicationPreparedEvent and before ApplicationStartedEvent. In practical terms, server setup happens before Spring Boot announces the started milestone, but that still does not mean startup runners have completed or readiness has been granted.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Started is not the same as ready
After refresh, Spring Boot publishes ApplicationStartedEvent and changes liveness to CORRECT. It then invokes registered ApplicationRunner and CommandLineRunner beans. If those callbacks return successfully, Spring Boot publishes ApplicationReadyEvent, changes readiness to ACCEPTING_TRAFFIC, and completes the run call by returning the context.
| Milestone | What has happened | What it means |
|---|---|---|
| Context refreshed | Context refresh completed; for a web context, server initialization occurs in this interval. | Startup has reached the liveness boundary. |
| Runners completed | Application and command-line runner callbacks returned successfully. | Startup work represented by those callbacks has finished. |
| Application ready | ApplicationReadyEvent is published and readiness becomes ACCEPTING_TRAFFIC. |
Spring Boot has reached its readiness boundary. |
Choosing a runner
| Runner | Input | Choose it when |
|---|---|---|
ApplicationRunner |
ApplicationArguments |
You want Spring Boot’s parsed argument abstraction. |
CommandLineRunner |
Raw String[] |
The original command-line strings are sufficient. |
Both run after context refresh and before readiness. If more than one runner must execute in a defined order, use Ordered or @Order. Put required initialization here only when the service should not be considered ready until it has finished.
Which events occur, and when
The Spring Boot 4.1.1 reference gives this lifecycle order for the main application events:
Rank #4
ApplicationStartingEventApplicationEnvironmentPreparedEventApplicationContextInitializedEventApplicationPreparedEventApplicationStartedEvent- Liveness
AvailabilityChangeEvent ApplicationReadyEvent- Readiness
AvailabilityChangeEvent
WebServerInitializedEvent and ContextRefreshedEvent occur between ApplicationPreparedEvent and ApplicationStartedEvent. If startup throws, Spring Boot can also publish ApplicationFailedEvent.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Events published before the context exists cannot be observed by bean-based listeners in that context. Register listeners through SpringApplication or its documented automatic listener registration mechanism when they must observe early events. By default, listeners run on the publishing thread, so long-running listener work can extend startup rather than happening in the background.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What startup failures look like
A failure can interrupt the sequence before the context is returned. A web server that cannot bind because its port is already in use is one documented example of a startup error. Registered FailureAnalyzer implementations can turn some failures into a description and suggested action, but not every failure has an analyzer. If a condition-related problem needs more context, starting with --debug can display the conditions report; that report is not a diagnosis for every kind of startup failure.
Spring Boot registers a shutdown hook by default so the context can close gracefully when the process shuts down. That is separate from successful startup: if startup fails, there may be no running context to return.
How to observe startup rather than guess from logs
A banner or a single log line cannot describe the whole startup lifecycle. Spring Boot’s ApplicationStartup and StartupStep instrumentation can collect startup-step information. The reference describes BufferingApplicationStartup for buffering steps and FlightRecorderApplicationStartup for correlating Spring lifecycle events with JVM events such as allocation, garbage collection, and class loading. Startup-step information can also be exposed through a startup endpoint when configured. These facilities help identify where time is spent; they do not promise a universal reduction in startup time.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The lifecycle at a glance
main → bootstrap and listeners → arguments and Environment → context selection and preparation → refresh → started and live → runners → ready and accepting traffic → returned context
For a web context, WebServerInitializedEvent and ContextRefreshedEvent fall inside the refresh-to-started interval. A startup exception branches out of this sequence and may be analyzed by a FailureAnalyzer. Application type, framework version, extension points, and user-defined listeners can affect what an application observes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
