Optimizing SpringBoot Startup Time: Analyzing Bean Scanning and Initialization Bottlenecks

In a SpringBoot project the author discovered that service startup took 6‑7 minutes due to heavy processing in the Bean scanning and injection stages. By using SpringApplicationRunListener and BeanPostProcessor to measure each phase, the most time‑consuming steps were identified as contextLoaded and started , which involve AbstractApplicationContext#refresh and the ConfigurationClassPostProcessor handling of @ComponentScan .

The investigation revealed that scanning large third‑party packages and processing many unnecessary beans caused the slowdown. Two main optimization paths were proposed:

Reduce scan paths by removing broad scanBasePackages entries and explicitly registering required beans via JavaConfig.

Monitor individual bean initialization times with a custom BeanPostProcessor implementation that logs the duration between postProcessBeforeInitialization and postProcessAfterInitialization .

Sample code for the custom listener:

@Slf4j
public class MySpringApplicationRunListener implements SpringApplicationRunListener {
    public MySpringApplicationRunListener(SpringApplication sa, String[] args) {}
    @Override public void starting() { log.info("starting {}", LocalDateTime.now()); }
    @Override public void environmentPrepared(ConfigurableEnvironment env) { log.info("environmentPrepared {}", LocalDateTime.now()); }
    @Override public void contextPrepared(ConfigurableApplicationContext ctx) { log.info("contextPrepared {}", LocalDateTime.now()); }
    @Override public void contextLoaded(ConfigurableApplicationContext ctx) { log.info("contextLoaded {}", LocalDateTime.now()); }
    @Override public void started(ConfigurableApplicationContext ctx) { log.info("started {}", LocalDateTime.now()); }
    @Override public void running(ConfigurableApplicationContext ctx) { log.info("running {}", LocalDateTime.now()); }
    @Override public void failed(ConfigurableApplicationContext ctx, Throwable ex) { log.info("failed {}", LocalDateTime.now()); }
}

After registering the listener in META-INF/spring.factories , the author observed that the majority of the delay occurred between contextLoaded and started , pinpointing the refresh process as the culprit.

To address excessive scanning, the author replaced broad package scans with explicit bean definitions, for example:

@Configuration
public class ThirdPartyBeanConfig {
    @Bean
    public UpmResourceClient upmResourceClient() { return new UpmResourceClient(); }
}

Additionally, the article discusses a cache component issue where removing its scan path caused SpringBoot’s auto‑configuration to create a default RedisCacheManager instead of the intended custom one. The root cause was the @ConditionalOnMissingBean(CacheManager.class) condition being satisfied after the scan path was removed.

To make the cache component robust, the author suggests leveraging SpringBoot’s starter mechanism: add the component’s configuration class to META-INF/spring.factories under EnableAutoConfiguration , allowing it to be auto‑imported without explicit package scanning.

Overall, the article demonstrates a systematic approach to profiling SpringBoot startup, trimming unnecessary classpath scanning, monitoring bean creation costs, and using SpringBoot’s auto‑configuration and starter facilities to achieve a reduction of startup time from around 7 minutes to roughly 40 seconds.