Analyzing the SpringBoot run Method: From Startup to Execution

This article aims to give a clear, top‑down view of the run method in SpringBoot, helping readers grasp the overall startup logic without getting lost in low‑level details.

SpringBoot is a lightweight framework built on top of Spring that simplifies configuration, provides an embedded web container, and enables developers to create stand‑alone, production‑grade applications with minimal boilerplate.

To build a basic SpringBoot project you need only three steps: provide a main class (e.g., LearnSpringBootApplication ), annotate it with @SpringBootApplication , and call SpringApplication.run(...) . The following code demonstrates a minimal starter class:

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

/**
 * SpringBoot application entry point
 */
@SpringBootApplication
public class LearnSpringBootApplication {
    public static void main(String[] args) {
        // Launch SpringBoot
        SpringApplication.run(LearnSpringBootApplication.class, args);
    }
}

The run method is overloaded. The overload that receives a single primary source simply delegates to the var‑args version, which constructs a SpringApplication instance and invokes its own run method:

public static ConfigurableApplicationContext run(Class
primarySource, String... args) {
    return run(new Class
[]{primarySource}, args);
}

public static ConfigurableApplicationContext run(Class
[] primarySources, String[] args) {
    return new SpringApplication(primarySources).run(args);
}

Creating a SpringApplication involves setting a ResourceLoader , deducing the WebApplicationType , loading initializers and listeners from META-INF/spring.factories , and recording the primary source class for later component scanning.

The core of SpringApplication.run(String... args) performs several actions: it parses command‑line arguments, prepares the ConfigurableEnvironment , prints the banner, creates the application context, registers exception reporters, prepares the context (including applying initializers), refreshes the context, and finally invokes any post‑refresh callbacks.

public ConfigurableApplicationContext run(String... args) {
    listeners.starting();
    ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
    ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
    configureIgnoreBeanInfo(environment);
    Banner printedBanner = printBanner(environment);
    ConfigurableApplicationContext context = createApplicationContext();
    // ... omitted for brevity ...
    refreshContext(context);
    afterRefresh(context, applicationArguments);
    return context;
}

The refreshContext step triggers the full Spring container lifecycle, loading bean definitions, applying BeanFactoryPostProcessor s, registering BeanPostProcessor s, and ultimately starting the embedded web server if the application is of type Servlet or Reactive .

In summary, the run method’s backbone consists of three essential aspects: automatic configuration, Spring container creation, and web container startup. Understanding this high‑level flow equips developers to dive deeper into any specific component of the SpringBoot startup process.