The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →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
When a Spring Boot application exits normally, Spring’s JVM shutdown hook closes the application context. That closure runs Spring lifecycle cleanup and, for supported embedded web servers, first stops new work from being admitted while active HTTP requests get a configured window to finish. A graceful exit is not guaranteed if the process is forcibly killed or its deployment platform’s termination deadline expires.
What starts Spring Boot shutdown?
Each SpringApplication registers a JVM shutdown hook. When the JVM exits orderly—such as after receiving a termination signal that it can handle—the hook closes the application context. Context closure gives Spring-managed components a chance to stop and clean up.
Standard lifecycle callbacks can participate, including DisposableBean and methods annotated with @PreDestroy. A forced termination, such as SIGKILL, does not give ordinary shutdown cleanup a chance to run. Spring’s current graceful-shutdown guidance also cautions that an IDE may stop an application immediately if it does not send a proper SIGTERM. Spring Boot: Graceful Shutdown · Spring Boot: SpringApplication
Recommended Free Tools
What happens while the application context closes?
Closing the context triggers Spring’s lifecycle stop processing. Spring Boot performs graceful web-server shutdown in the earliest phase of stopping SmartLifecycle beans. This ordering lets the server stop admitting work before later shutdown work proceeds.
#1 Best Overall
For supported embedded servers, existing requests are allowed a timeout window to complete, while new requests are not permitted. This does not automatically drain every kind of background work: application-specific message consumers, executors, and other long-running tasks need suitable lifecycle handling and timeouts of their own.
What do clients see during graceful shutdown?
The intended outcome is that new requests are refused while in-flight requests get time to finish. The exact refusal behavior is server-dependent; do not assume every implementation returns the same HTTP status or handles every persistent connection identically. Spring’s current reference notes that persistent connections can affect whether a server continues accepting requests.
| Embedded server | Behavior described in Spring Boot 3.3.13 documentation |
|---|---|
| Jetty | Stops accepting requests at the network layer. |
| Reactor Netty | Stops accepting requests at the network layer. |
| Tomcat | Stops accepting requests at the network layer. |
| Undertow | Can accept new connections but respond with HTTP 503. |
These distinctions are specific to the Spring Boot 3.3.13 documentation; they are not performance comparisons. The current unversioned reference lists Jetty, Reactor Netty, and Tomcat as supporting graceful shutdown. Current Spring Boot reference: Graceful Shutdown · Spring Boot 3.3.13 reference: Graceful Shutdown
Which Spring Boot settings control the shutdown window?
For the current reference’s listed embedded servers, graceful shutdown is enabled by default. The application phase timeout is controlled by spring.lifecycle.timeout-per-shutdown-phase. Set it to suit the work that must finish during each shutdown phase; Spring’s 20s example illustrates duration syntax, not a universal recommendation.
To disable graceful web shutdown, the current reference documents server.shutdown=immediate. The Spring Boot 3.3.13 documentation also shows explicitly enabling graceful mode with server.shutdown=graceful, alongside a 20s timeout example. Check the documentation for the version you deploy rather than treating an example as a version-independent requirement.
server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=20sThe timeout is a per-shutdown-phase setting, not a promise that every request or task will finish. Work that exceeds the available timeout can be interrupted when the process must exit.
Rank #4
How does Kubernetes change the shutdown sequence?
Spring’s Kubernetes deployment guidance describes several shutdown activities happening concurrently. As a pod is terminated, routing changes and application shutdown can overlap, leaving a window in which traffic may still reach the application. A preStop delay can give routing changes time to propagate; Kubernetes then sends SIGTERM to the container.
Kubernetes’ documented default termination grace period is 30 seconds. If the container is still running when that total period expires, Kubernetes sends SIGKILL. Increase terminationGracePeriodSeconds when the application needs more time, and coordinate that total budget with Spring’s lifecycle timeout while leaving room for routing and other cleanup overhead. The Spring timeout alone does not guarantee a graceful pod termination. Spring Boot deployment guidance: Kubernetes
Is the exit code part of graceful request draining?
No. Exit status and request draining are separate concerns. An ExitCodeGenerator can provide the code used by SpringApplication.exit; Spring’s regular lifecycle callbacks remain the mechanism for cleaning up managed components. Spring Boot: SpringApplication
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.
