Confusion between @PreDestroy and GracefulShutdownCapable Beans

[KDanisme]

What exactly is the difference between @PreDestroy and GracefulShutdownCapable
From my understanding:

• both will trigger when shutting down the application context
• both will block till the function ends (Im not sure what timeout PreDestroy has nor where it is configured)

The differences I could spot are:

• GracefulShutdownCapable beans can report on number of pending tasks
• GracefulShutdownCapable shutdown function timeouts are globally configurable.
• PreDestroy beans will trigger in more cases, such as refreshable beans

Are my statemes correct? Or am I missing something obvious?

Also, in case I want my beans to gracefully be shutdown and refreshed, do i need both @PreDestroy and GracefulllShutdownCapable?
And in that case, which one runs first?

Thanks!

[TatyOko28]

Your statements: mostly correct, with refinements

Aspect	@PreDestroy	GracefulShutdownCapable
Trigger on context shutdown	✅ Yes	✅ Yes
Blocks until completion	✅ Yes (no built-in timeout)	✅ Yes (with configurable timeout)
Timeout configuration	❌ No timeout by default. Container-specific (e.g., Tomcat's destroyAwaitSeconds).	✅ Yes, via quarkus.shutdown.timeout (or framework equivalent)
Reports pending tasks	❌ No	✅ Yes (isShuttingDown(), getRemainingPendingTasks())
Triggers on bean refresh	✅ Yes (if bean is destroyed during refresh)	❌ Typically no (usually only on application shutdown)
Standard/Jakarta EE	✅ Yes (JSR-250)	❌ No (framework-specific, e.g., Quarkus, Spring Boot Actuator)

What you're missing (important nuances)

1. Timeout behavior

• @PreDestroy: No standard timeout. However, the underlying container may impose one (e.g., Tomcat's destroyAwaitSeconds defaults to 5-10 seconds). If your @PreDestroy method hangs indefinitely, the JVM may not terminate.
• GracefulShutdownCapable: Has a hard timeout (e.g., 30 seconds). If the timeout is reached, the shutdown proceeds anyway (pending tasks may be interrupted or lost).

2. Execution context

• @PreDestroy: Runs on the same thread calling context.close() (or JVM shutdown hook). Blocking here blocks the entire shutdown sequence.
• GracefulShutdownCapable: Often runs on a dedicated executor to allow concurrent graceful shutdown of multiple components.

3. Shutdown ordering

• @PreDestroy: Runs during the destruction phase of the bean lifecycle (after @PostConstruct and @Autowired cleanup).
• GracefulShutdownCapable: Runs earlier, typically during the graceful shutdown phase before beans are destroyed. This allows rejecting new requests while completing in-flight work.

4. Refresh behavior

• @PreDestroy: ✅ Called when a refreshable bean is destroyed during context refresh (e.g., Spring Cloud @RefreshScope). The bean is re-created afterward.
• GracefulShutdownCapable: ❌ Not relevant for refresh. A bean refresh is not a shutdown — the application continues running.

---

Do I need both? Which runs first?

Recommendation: Use both, but with clear separation of concerns

Scenario	Use @PreDestroy	Use GracefulShutdownCapable
Clean up resources (connections, threads, file handles)	✅ Yes	❌ No
Reject new requests + wait for in-flight work to complete	❌ No	✅ Yes
Bean refresh support	✅ Yes	❌ No

Execution order (typical framework like Quarkus / Spring Boot with graceful shutdown enabled)