Spring Bean Lifecycle in Boot 4: @PostConstruct, InitializingBean, SmartLifecycle and Shutdown Order

Versions. Spring Boot 4.1.1 and Spring Framework 7.0.9 (both poms were published to Maven Central on 20 August 2026), on Java 25 (LTS, Temurin 25.0.4.1). The callback-order run uses SpringApplication without a web server; the shutdown scenarios start a real Boot web application on a random port and send it an HTTP request that is still running when the context is closed.

Every callback for one bean, printed in the order they ran

public class KitchenSink implements BeanNameAware, BeanFactoryAware, ApplicationContextAware,
        InitializingBean, DisposableBean, SmartInitializingSingleton, SmartLifecycle {

    @PostConstruct
    void postConstruct() {
        Trace.log("@PostConstruct");
    }

    @Override
    public void afterPropertiesSet() {
        Trace.log("InitializingBean.afterPropertiesSet");
    }

@Configuration
public class LifecycleConfig {

    @Bean
    static TracingPostProcessor tracingPostProcessor() {
        return new TracingPostProcessor();
    }

    @Bean
    Dependency dependency() {
        return new Dependency();
    }

    @Bean(initMethod = "customInit", destroyMethod = "customDestroy")
    KitchenSink kitchenSink() {
        return new KitchenSink();
    }
}

constructor
setter injection (@Autowired setDependency)
BeanNameAware.setBeanName("kitchenSink")
BeanFactoryAware.setBeanFactory
ApplicationContextAware.setApplicationContext
BeanPostProcessor.postProcessBeforeInitialization
@PostConstruct
InitializingBean.afterPropertiesSet
@Bean(initMethod = "customInit")
BeanPostProcessor.postProcessAfterInitialization
SmartInitializingSingleton.afterSingletonsInstantiated
SmartLifecycle.start (phase 2147483647)
ContextRefreshedEvent
ApplicationStartedEvent
ApplicationRunner.run
ApplicationReadyEvent

Going deeper

• Reference: Spring Framework – Customizing the Nature of a Bean (lifecycle callbacks, aware interfaces)
• Reference: Spring Framework – @PostConstruct and @PreDestroy
• Source: LifecycleTest.java (fullOrderUnderSpringBoot writes the transcript)
• Previous in this series: constructor, setter and field injection, which explains why the constructor runs before the setter and field injection you see at the top of the list

@PostConstruct means “this bean is wired”, not “the application is ready”

public class FailingInit {

    @PostConstruct
    void warmUp() {
        throw new IllegalStateException("cache warm-up failed");
    }
}

context started: false
top exception : org.springframework.beans.factory.BeanCreationException
top message   : Error creating bean with name 'failingInit': Invocation of init method failed
root cause    : java.lang.IllegalStateException: cache warm-up failed

Doing slow or fallible work in @PostConstruct makes start-up slow and fragile. A network call to a service that is down turns into an application that will not start. Sometimes that is exactly what you want (fail fast on a missing configuration value), and sometimes it is a rolling deployment that cannot complete. Decide on purpose, not by default.

Going deeper

• Reference: Spring Framework – Initialization Callbacks
• Source: LifecycleTest.java (failingPostConstructStopsStartup)
• Related on this site: Spring Boot 4 on Kubernetes: probes and graceful shutdown for how start-up and readiness relate in a deployment

@PostConstruct runs before the proxy exists

public class AsyncMailer {

    @PostConstruct
    void init() {
        Trace.log("@PostConstruct sees this = " + getClass().getName() + ", isAopProxy(this) = "
                + AopUtils.isAopProxy(this));
    }

    @Async
    public void send() {
    }

    @org.springframework.context.annotation.Configuration
    @EnableAsync
    public static class Config {
    }
}

@PostConstruct sees this = com.ankurm.corebeans.lifecycle.AsyncMailer, isAopProxy(this) = false
the bean other code receives : com.ankurm.corebeans.lifecycle.AsyncMailer$$SpringCGLIB$$0

The fix is not to call proxied methods from init code. If start-up work needs a transaction, an async call or a cache, do it from a hook that runs after the container has finished building beans (SmartInitializingSingleton, ApplicationRunner, or a SmartLifecycle.start) and call it through another bean, so that the call goes through the proxy. This is the same proxy-bypass as the self-invocation trap described in the AOP and transaction articles linked below; init code is just a place people meet it without a second bean in sight.

Going deeper

• Related on this site: Spring AOP: pointcuts, advice types and why your aspect is not firing (self-invocation and proxies)
• Related on this site: @Transactional: propagation, isolation and silent failures
• Related on this site: Spring Boot 4 @Async, executors and virtual threads
• Source: LifecycleTest.java (postConstructRunsOnTheRawTarget)

A BeanPostProcessor is a bean that edits other beans, so declare it static

 1  org.springframework.context.support.ApplicationContextAwareProcessor
 2  org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor
 3  org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker
 4  com.ankurm.corebeans.lifecycle.TracingPostProcessor
 5  org.springframework.context.annotation.CommonAnnotationBeanPostProcessor
 6  org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor
 7  org.springframework.context.support.ApplicationListenerDetector

public class TracingPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (beanName.equals("kitchenSink")) {
            Trace.log("BeanPostProcessor.postProcessBeforeInitialization");
        }
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (beanName.equals("kitchenSink")) {
            Trace.log("BeanPostProcessor.postProcessAfterInitialization");
        }
        return bean;
    }
}

public class NonStaticProcessorConfig {

    @Bean
    BeanPostProcessor quietProcessor() {
        return new BeanPostProcessor() {
        };
    }

    @Bean
    Dependency plainBean() {
        return new Dependency();
    }
}

2026-09-24T10:28:59.979+05:30  WARN 3358 --- [core-beans] [           main] trationDelegate$BeanPostProcessorChecker : Bean 'nonStaticProcessorConfig' of type [com.ankurm.corebeans.lifecycle.NonStaticProcessorConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [quietProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.

Read that WARN. It looks like noise. It means that the configuration class it names, and anything it produces, may miss advice that every other bean gets: proxies for @Transactional, @Async or security annotations. Symptoms appear far from the cause, as a method that silently runs without its transaction.

Going deeper

• Reference: Spring Framework – Container Extension Points (BeanPostProcessor, BeanFactoryPostProcessor, and the ordering rules)
• Related on this site: Spring AOP and why an aspect does not fire; most “not proxied” bugs are a bean that a post-processor never saw
• Source: LifecycleTest.java (beanPostProcessorsInABootContext, nonStaticBeanPostProcessorWarns)

Shutdown mirrors start-up, and the event comes first

=== ctx.close() ===
ContextClosedEvent
SmartLifecycle.stop
@PreDestroy
DisposableBean.destroy
@Bean(destroyMethod = "customDestroy")

Two things this transcript does not show. First, the test closes the context by calling close(). A deployed application closes because the process receives SIGTERM, and Spring Boot registers a JVM shutdown hook that calls the same code; that is documented on the Boot graceful shutdown page linked below and is not exercised here. Second, prototype beans never reach a destroy callback at all, because the container does not keep them; the scopes article measures that, with the transcript to prove it.

Going deeper

• Reference: Spring Framework – Destruction Callbacks
• Reference: Spring Boot – Graceful Shutdown (how the JVM shutdown hook and the timeout fit together)
• Previous in this series: Spring bean scopes

SmartLifecycle gives you an order for starting and stopping, and it is a number

    @Override
    public int getPhase() {
        return phase;
    }

    @Override
    public void start() {
        running.set(true);
        Trace.log("start " + name + " (phase " + phase + ")");
    }

    /** Blocking variant: Spring's default stop(Runnable) calls this, then the callback, on its own thread. */
    @Override
    public void stop() {
        sleep(stopMillis);
        running.set(false);
        Trace.log("stop  " + name + " (phase " + phase + ")");
    }

    void smartLifecyclePhases() {
        try (var t = new Transcript("11-smartlifecycle-phases.txt",
                "Three SmartLifecycle beans registered in the order 300, 100, 200")) {
            var ctx = new org.springframework.context.annotation.AnnotationConfigApplicationContext();
            ctx.registerBean("workerC", PhasedWorker.class, () -> new PhasedWorker("C", 300, 0, false));
            ctx.registerBean("workerA", PhasedWorker.class, () -> new PhasedWorker("A", 100, 0, false));
            ctx.registerBean("workerB", PhasedWorker.class, () -> new PhasedWorker("B", 200, 0, false));
            ctx.refresh();
            t.line("=== refresh() ===");
            Trace.drain().forEach(e -> t.line("%s", e));
            ctx.close();
            t.line("=== close() ===");
            var stops = Trace.drain();
            stops.forEach(e -> t.line("%s", e));
            assertThat(stops.get(0)).contains("phase 300");
            assertThat(stops.get(2)).contains("phase 100");
        }
    }

=== refresh() ===
start A (phase 100)
start B (phase 200)
start C (phase 300)
=== close() ===
stop  C (phase 300)
stop  B (phase 200)
stop  A (phase 100)

public class PlainLifecycle implements Lifecycle {

    private boolean running;

    @Override
    public void start() {
        running = true;
        Trace.log("PlainLifecycle.start");
    }

    @Override
    public void stop() {
        running = false;
        Trace.log("PlainLifecycle.stop");
    }

    @Override
    public boolean isRunning() {
        return running;
    }
}

after refresh() : events=[] isRunning=false
after start()   : events=[PlainLifecycle.start] isRunning=true

Going deeper

• Reference: SmartLifecycle Javadoc (Framework 7.0.9) (phase rules, isAutoStartup, stop(Runnable))
• Reference: Spring Framework – Startup and Shutdown Callbacks
• Source: PhasedWorker.java and LifecycleTest.java (smartLifecyclePhases, plainLifecycleIsNotAutoStarted)

Beans in the same phase stop one after another unless stop(Runnable) returns at once

    public void stop(Runnable callback) {
        if (!asyncStop) {
            SmartLifecycle.super.stop(callback);
            return;
        }
        Thread.ofVirtual().start(() -> {
            sleep(stopMillis);
            running.set(false);
            Trace.log("stop  " + name + " (phase " + phase + ", async callback)");
            callback.run();
        });
    }

stop(Runnable) blocks (the default)  : close() took >= 1100 ms (sequential)
stop(Runnable) returns immediately   : close() took < 800 ms (concurrent)

A stop(Runnable) that never calls its callback makes shutdown wait for the full timeout. The container cannot tell that the bean has finished or is stuck.

    public void stop(Runnable callback) {
        // forgot to call callback.run()
    }

close() returned after roughly the timeout: true
2026-09-24T10:28:58.263+05:30  INFO 3358 --- [core-beans] [           main] o.s.c.support.DefaultLifecycleProcessor  : Shutdown phase 2147483647 ends with 1 bean still running after timeout of 500ms: [neverStops]

spring.lifecycle.timeout-per-shutdown-phase    type=java.time.Duration                       default=30s
spring.threads.virtual.enabled                 type=java.lang.Boolean                        default=False
server.shutdown                                type=org.springframework.boot.web.server.Shutdown default=graceful

Going deeper

• Reference: Spring Boot – Graceful Shutdown (the timeout property)
• Related on this site: Spring Boot 4 on Kubernetes: probes, graceful shutdown, CPU limits and HPA
• Source: NeverStops.java, LifecycleTest.java (sameScopeBlockingVersusAsyncStop, shutdownPhaseTimeout)

Graceful shutdown is a SmartLifecycle too, and your phase decides whether the requests are finished

phase          bean name                          class
2147483647     earlyWorker                        EarlyWorker
2147482623     webServerGracefulShutdown          WebServerGracefulShutdownLifecycle
2147481599     webServerStartStop                 WebServerStartStopLifecycle
1073741823     applicationTaskExecutor            ThreadPoolTaskExecutor
1000           lateWorker                         LateWorker
-2147483647    springBootLoggingLifecycle         Lifecycle

SmartLifecycle.DEFAULT_PHASE = 2147483647

/** Leaves getPhase() at its default, which is Integer.MAX_VALUE. */
@Component
public class EarlyWorker implements SmartLifecycle {

/** Phase 1000: far below the web server's phases, so it stops after the server has drained. */
@Component
public class LateWorker implements SmartLifecycle {

    private volatile boolean running;

    @Override
    public int getPhase() {
        return 1000;
    }

    @Override
    public void start() {
        running = true;
    }

    @Override
    public void stop() {
        running = false;
        Trace.log("LateWorker.stop   (phase " + getPhase() + "): requests still in flight = "
                + SlowController.IN_FLIGHT.get());
    }

    @Override
    public boolean isRunning() {
        return running;
    }
}

    @GetMapping("/slow")
    public String slow(@RequestParam long ms) throws InterruptedException {
        IN_FLIGHT.incrementAndGet();
        try {
            Thread.sleep(ms);
            COMPLETED.incrementAndGet();
            return "finished after " + ms + " ms, virtual thread = " + Thread.currentThread().isVirtual();
        } finally {
            IN_FLIGHT.decrementAndGet();
        }
    }

EarlyWorker.stop  (phase 2147483647): requests still in flight = 1
LateWorker.stop   (phase 1000): requests still in flight = 0
the client saw: HTTP 200: finished after 1500 ms, virtual thread = true

settings                                     the client saw                                       close() blocked                  handler ran to the end
-------------------------------------------- ---------------------------------------------------- -------------------------------- ----------------------
server.shutdown=graceful, virtual threads    HTTP 200: finished after 1500 ms, virtual thread = true >= 1 s (waited for the request)  yes
server.shutdown=graceful, platform threads   HTTP 200: finished after 1500 ms, virtual thread = false >= 1 s (waited for the request)  yes
server.shutdown=immediate, virtual threads   FAILED: connection dropped, no response              >= 1 s (waited for the request)  yes

A note on that middle column. The text “>= 1 s (waited for the request)” is a generic label the test prints whenever close() took at least a second. It appears on the immediate row too, where the request was not waited for by the client. I did not investigate why close() still took that long under immediate, and I would not read anything into it beyond “took at least a second”. The column that carries the finding is the second one.

    private static Result runAndClose(String shutdownMode, boolean virtualThreads) throws Exception {
        ConfigurableApplicationContext ctx = new SpringApplicationBuilder(ShutdownApp.class)
                .web(WebApplicationType.SERVLET)
                .properties("server.port=0", "logging.level.root=OFF", "spring.main.banner-mode=off",
                        "server.shutdown=" + shutdownMode,
                        "spring.threads.virtual.enabled=" + virtualThreads,
                        "spring.lifecycle.timeout-per-shutdown-phase=10s")
                .run();
        int port = Integer.parseInt(ctx.getEnvironment().getProperty("local.server.port"));
        HttpClient client = HttpClient.newHttpClient();
        CompletableFuture<String> pending = client
                .sendAsync(HttpRequest.newBuilder(URI.create("http://localhost:" + port + "/slow?ms=1500")).build(),
                        HttpResponse.BodyHandlers.ofString())
                .thenApply(r -> "HTTP " + r.statusCode() + ": " + r.body())
                .exceptionally(e -> "FAILED: connection dropped, no response");
        long deadline = System.currentTimeMillis() + 5000;
        while (SlowController.IN_FLIGHT.get() == 0 && System.currentTimeMillis() < deadline) {
            Thread.sleep(10);
        }
        assertThat(SlowController.IN_FLIGHT.get()).isEqualTo(1);
        long begin = System.nanoTime();
        ctx.close();
        long closeMs = (System.nanoTime() - begin) / 1_000_000;
        String response = pending.get();
        int completed = SlowController.COMPLETED.get();
        SlowController.COMPLETED.set(0);
        return new Result(response, closeMs, completed);
    }

Going deeper

• Reference: Spring Boot – Graceful Shutdown
• Related on this site: Spring Boot 4 @Async, executors and virtual threads
• Related on this site: Spring Boot 4 on Kubernetes: probes and graceful shutdown
• Source: GracefulShutdownTest.java (inFlightRequestDuringClose, workerPhasesAgainstTheWebServer)

Which hook, and when

Should you even care? For a typical application made of controllers, services and repositories, you may never write a SmartLifecycle. Boot’s defaults already drain in-flight web requests on shutdown, and the measured runs above show the client getting its answer. The parts most worth remembering are the cheap ones: @PostConstruct is not “ready” and does not see the proxy, a non-static BeanPostProcessor is a bug the container warns you about, and a default-phase lifecycle bean stops before the web server has finished its requests. If you own background threads, a queue consumer or a scheduled poller, choose a phase deliberately. Which number to choose is a judgment call: the runs show that 1000 falls after the web server drained and the default falls before, and nothing more.

Going deeper

• Previous in this series: Dependency injection: constructor, setter, field, @Autowired resolution and bean scopes
• Interview preparation: Top 50 Spring Boot 4 Interview Questions and Answers (2026); the lifecycle order is a standard question

Further reading

• Companion repository for this article: asmhatre/spring-boot-demo, core-beans module
• Other articles in this series: Constructor vs Setter vs Field injection, @Autowired Explained, Spring Bean Scopes
• On this site: Spring Boot 4 @Async, executors and virtual threads, Kubernetes probes and graceful shutdown, Spring AOP: why an aspect is not firing, @Transactional propagation and isolation
• Official reference: Spring Framework – Customizing the Nature of a Bean
• Official reference: Spring Framework – Container Extension Points
• Official reference: Spring Boot – Graceful Shutdown
• Official Javadoc: SmartLifecycle (Framework 7.0.9)