7 Proven Techniques to Slash Spring Boot Startup Time by 70%
Learn seven practical strategies—including lazy initialization, precise component scanning, JVM tuning, auto‑configuration pruning, dependency slimming, delayed datasource connections, and AOT/layered compilation—to dramatically reduce Spring Boot application startup time, memory usage, and class loading, with real‑world performance comparisons.
1. Lazy Initialization: Smart On‑Demand Loading
Practice:
# application.properties
spring.main.lazy-initialization=trueOptimization principle:
Delay initialization of all beans until first use
Reduce I/O and dependency resolution at startup
Notes:
// Disable lazy init for specific beans
@Bean
@Lazy(false)
public CriticalBean criticalBean() {
return new CriticalBean();
}Effect:
E‑commerce app startup: 8.2s → 5.1s (‑38%)
Microservice gateway: 12s → 7.3s (‑39%)
2. Precise Component Scan: Stop Blind Scanning
Optimization:
@SpringBootApplication(
scanBasePackages = {"com.your.package.service", "com.your.package.controller"}
)Advanced tip:
// Exclude external packages and repositories
@ComponentScan(excludeFilters = {
@Filter(type = FilterType.REGEX, pattern = "com.external.*"),
@Filter(type = FilterType.ANNOTATION, classes = Repository.class)
})Typical case:
Financial system excluded 20 unnecessary auto‑config classes
Startup reduced from 6.5s → 4.2s (‑35%)
3. JVM Parameter Tuning: Hidden Startup Switch
Recommended parameters:
java -XX:TieredStopAtLevel=1 \
-Xverify:none \
-XX:+AlwaysPreTouch \
-XX:MetaspaceSize=128m \
-XX:MaxMetaspaceSize=128m \
-jar your-app.jarParameter meanings:
-XX:TieredStopAtLevel=1 – disables C2 compilation (dev)
-Xverify:none – skips bytecode verification (trusted env)
-noverify – same as above (JDK8‑)
-XX:+AlwaysPreTouch – pre‑allocates memory (prod)
-XX:MetaspaceSize=128m – avoids frequent metaspace expansion (metadata‑heavy apps)
Measured effect:
Logistics system startup: 9s → 5.4s (‑40%)
4. Auto‑Configuration Slimming
Diagnostic:
@SpringBootApplication
public class MyApp {
public static void main(String[] args) {
SpringApplication app = new SpringApplication(MyApp.class);
app.setBannerMode(Banner.Mode.OFF);
// Print auto‑configuration report
app.setAdditionalProfiles("debug");
app.run(args);
}
}Exclude unnecessary auto‑config:
@EnableAutoConfiguration(exclude = {
DataSourceAutoConfiguration.class,
HibernateJpaAutoConfiguration.class,
RabbitAutoConfiguration.class
})Case:
IoT platform excluded 15 auto‑config classes, startup 7.8s → 4.6s (‑41%)
5. Class‑Loading Optimization
Analysis tool:
# Use JDK built‑in tool
java -verbose:class -jar your-app.jar | grep "loaded"Strategy: Trim dependencies, use Maven jar index.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>Effect:
Social app class‑load time 2.3s → 1.1s (‑52%)
6. Database Connection Optimization
Lazy datasource:
@Configuration
public class LazyDataSourceConfig {
@Bean
@Lazy
public DataSource dataSource() {
return DataSourceBuilder.create().build();
}
}Connection pool tuning (HikariCP):
spring.datasource.hikari.initialization-fail-timeout=30000
spring.datasource.hikari.connection-timeout=5000
spring.datasource.hikari.maximum-pool-size=5Special handling:
// Ensure data init after startup
@Bean
public CommandLineRunner initData(MyRepository repo) {
return args -> {
// data operations after start
};
}Case:
CRM system DB‑related startup 4.2s → 1.3s (‑69%)
7. Compilation Optimization: AOT and Layered Compilation
7.1 GraalVM Native Image
# Install GraalVM
gu install native-image
# Build native image
mvn -Pnative packageEffect: API gateway startup 6s → 0.05s (‑99%)
7.2 Layered Compilation
<code# Development fast compile
-Dspring.aot.enabled=false -XX:TieredStopAtLevel=1
# Production full optimization
-Dspring.aot.enabled=true -XX:TieredStopAtLevel=4</code>Effect: Payment service cold start 8s → 2.3s (‑71%)
Comprehensive Case: E‑commerce Platform
Before optimization:
Startup 14.6 s
Memory 1.2 GB
Classes loaded 8,732
Steps applied:
Lazy init (‑3.2 s)
Precise component scan (‑2.8 s)
JVM tuning (‑1.9 s)
Exclude 12 auto‑config classes (‑2.1 s)
Trim dependencies (‑1.3 s)
Lazy DB connection (‑0.9 s)
Layered compilation (‑2.4 s)
After optimization:
Startup 4.3 s (‑70.5%)
Memory 680 MB (‑43%)
Classes loaded 5,211 (‑40%)
Startup Optimization Checklist
Enable lazy initialization
Configure component scan range precisely
Optimize JVM startup parameters
Exclude unnecessary auto‑configuration
Analyze and slim dependencies
Delay non‑critical resource connections
Consider AOT or layered compilation
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architect
Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
