Spring Boot Startup Performance
Long startup hurts deploy velocity and Kubernetes rolling updates. Audit auto-configuration, prefer constructor injection, and consider AOT / native compilation for cold-start-sensitive workloads.
Deep dive
Where time goes
-Dspring-boot.run.arguments=--debug or the startup actuator endpoint pinpoint the slowest auto-configs. Common culprits: ClassPathScanning over wide packages, JPA entity scanning, eager @Bean creation that pulls in a JDBC pool before the DB is reachable.
Levers
- Narrow
@SpringBootApplication(scanBasePackages = ...). - Mark non-critical beans
@Lazy. - Use
spring.jpa.open-in-view=false(and understand why). - Spring AOT / GraalVM native-image for sub-second cold starts (Lambda, scale-to-zero).
Real-world example
From productionA team had 45-second startups blocking blue/green deploys. startup actuator showed 18 s in Hibernate entity scanning across a fat shared library. Limiting @EntityScan to one package cut startup to 12 s. Native-image experiments brought it under 200 ms but doubled build time — kept for the scale-to-zero edge service only.
Interview questions
1 senior-levelQ1How would you diagnose slow Spring Boot startup?▾
Enable the startup actuator or -Ddebug, capture a BufferingApplicationStartup trace, and look at the longest steps. Common: classpath scanning, JPA entity scanning, eager DB pool warmup. Fix by narrowing scans, lazy beans, or AOT.
Common mistakes
Putting
@ComponentScan("com")at the root.Loading config from remote services synchronously at startup with no timeout.
Trade-offs
Native-image cuts startup dramatically but loses some reflection-heavy library support and adds build complexity.
Lazy beans hide misconfiguration until first request.