背景

耗時問題排查

觀察 SpringBoot 啟動 run 方法

監控 Bean 注入耗時

優化方案

如何解決掃描路徑過多？

如何解決 Bean 初始化高耗時？

新的問題

SpringBoot 自動化裝配，讓人防不勝防

使用 starter 機制，開箱即用

背景

公司 SpringBoot 項目在日常開發過程中發現服務啟動過程異常緩慢，常常需要6-7分鐘才能暴露端口，嚴重降低開發效率。通過 SpringBoot 的 SpringApplicationRunListener 、BeanPostProcessor 原理和源碼調試等手段排查發現，在 Bean 掃描和 Bean 注入這個兩個階段有很大的性能瓶頸。

通過 JavaConfig 注冊 Bean， 減少 SpringBoot 的掃描路徑，同時基于 Springboot 自動配置原理對第三方依賴優化改造，將服務本地啟動時間從7min 降至40s 左右的過程。 本文會涉及以下知識點：

基于 SpringApplicationRunListener 原理觀察 SpringBoot 啟動 run 方法；

基于 BeanPostProcessor 原理監控 Bean 注入耗時；

SpringBoot Cache 自動化配置原理；

SpringBoot 自動化配置原理及 starter 改造；

耗時問題排查

SpringBoot 服務啟動耗時排查，目前有2個思路：

排查 SpringBoot 服務的啟動過程；

排查 Bean 的初始化耗時；

觀察 SpringBoot 啟動 run 方法

該項目使用基于 SpringBoot 改造的內部微服務組件 XxBoot 作為服務端實現，其啟動流程與 SpringBoot 類似，分為 ApplicationContext 構造和 ApplicationContext 啟動兩部分，即通過構造函數實例化 ApplicationContext 對象，并調用其 run 方法啟動服務：

publicclassApplication{
publicstaticvoidmain(String[]args){
SpringApplication.run(Application.class,args);
}
}

publicstaticConfigurableApplicationContextrun(Class[]primarySources,String[]args){
returnnewSpringApplication(primarySources).run(args);
}

ApplicationContext 對象構造過程，主要做了自定義 Banner 設置、應用類型推斷、配置源設置等工作，不做特殊擴展的話，大部分項目都是差不多的，不太可能引起耗時問題。通過在 run 方法中打斷點，啟動后很快就運行到斷點位置，也能驗證這一點。接下就是重點排查 run 方法的啟動過程中有哪些性能瓶頸？SpringBoot 的啟動過程非常復雜，慶幸的是 SpringBoot 本身提供的一些機制，將 SpringBoot 的啟動過程劃分了多個階段，這個階段劃分的過程就體現在 SpringApplicationRunListener 接口中，該接口將 ApplicationContext 對象的 run 方法劃分成不同的階段：

publicinterfaceSpringApplicationRunListener{
//run方法第一次被執行時調用，早期初始化工作
voidstarting();
//environment創建后，ApplicationContext創建前
voidenvironmentPrepared(ConfigurableEnvironmentenvironment);
//ApplicationContext實例創建，部分屬性設置了
voidcontextPrepared(ConfigurableApplicationContextcontext);
//ApplicationContext加載后，refresh前
voidcontextLoaded(ConfigurableApplicationContextcontext);
//refresh后
voidstarted(ConfigurableApplicationContextcontext);
//所有初始化完成后，run結束前
voidrunning(ConfigurableApplicationContextcontext);
//初始化失敗后
voidfailed(ConfigurableApplicationContextcontext,Throwableexception);
}

目前，SpringBoot 中自帶的 SpringApplicationRunListener 接口只有一個實現類：EventPublishingRunListener，該實現類作用：通過觀察者模式的事件機制，在 run 方法的不同階段觸發 Event 事件，ApplicationListener 的實現類們通過監聽不同的 Event 事件對象觸發不同的業務處理邏輯。

?

通過自定義實現 ApplicationListener 實現類，可以在 SpringBoot 啟動的不同階段，實現一定的處理，可見SpringApplicationRunListener 接口給 SpringBoot 帶來了擴展性。

?

這里我們不必深究實現類 EventPublishingRunListener 的功能，但是可以通過 SpringApplicationRunListener 原理，「添加一個自定義的實現類，在不同階段結束時打印下當前時間，通過計算不同階段的運行時間，就能大體定位哪些階段耗時比較高」 ，然后重點排查這些階段的代碼。先看下 SpringApplicationRunListener 的實現原理，其劃分不同階段的邏輯體現在 ApplicationContext 的 run 方法中：

publicConfigurableApplicationContextrun(String...args){
...
//加載所有SpringApplicationRunListener的實現類
SpringApplicationRunListenerslisteners=getRunListeners(args);
//調用了starting
listeners.starting();
try{
ApplicationArgumentsapplicationArguments=newDefaultApplicationArguments(args);
//調用了environmentPrepared
ConfigurableEnvironmentenvironment=prepareEnvironment(listeners,applicationArguments);
configureIgnoreBeanInfo(environment);
BannerprintedBanner=printBanner(environment);
context=createApplicationContext();
exceptionReporters=getSpringFactoriesInstances(SpringBootExceptionReporter.class,newClass[]{ConfigurableApplicationContext.class},context);
//內部調用了contextPrepared、contextLoaded
prepareContext(context,environment,listeners,applicationArguments,printedBanner);
refreshContext(context);
afterRefresh(context,applicationArguments);
stopWatch.stop();
if(this.logStartupInfo){
newStartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(),stopWatch);
}
//調用了started
listeners.started(context);
callRunners(context,applicationArguments);
}
catch(Throwableex){
//內部調用了failed
handleRunFailure(context,ex,exceptionReporters,listeners);
thrownewIllegalStateException(ex);
}
try{
//調用了running
listeners.running(context);
}
catch(Throwableex){
handleRunFailure(context,ex,exceptionReporters,null);
thrownewIllegalStateException(ex);
}
returncontext;
}

run 方法中 getRunListeners(args) 通過 SpringFactoriesLoader 加載 classpath 下 META-INF/spring.factotries 中配置的所有 SpringApplicationRunListener 的實現類，通過反射實例化后，存到局部變量 listeners 中，其類型為 SpringApplicationRunListeners；然后在 run 方法不同階段通過調用 listeners 的不同階段方法來觸發 SpringApplicationRunListener 所有實現類的階段方法調用。

因此，只要編寫一個 SpringApplicationRunListener 的自定義實現類，在實現接口不同階段方法時，打印當前時間；并在 META-INF/spring.factotries 中配置該類后，該類也會實例化，存到 listeners 中；在不同階段結束時打印結束時間，以此來評估不同階段的執行耗時。在項目中添加實現類 MySpringApplicationRunListener ：

@Slf4j
publicclassMySpringApplicationRunListenerimplementsSpringApplicationRunListener{
//這個構造函數不能少，否則反射生成實例會報錯
publicMySpringApplicationRunListener(SpringApplicationsa,String[]args){
}
@Override
publicvoidstarting(){
log.info("starting{}",LocalDateTime.now());
}
@Override
publicvoidenvironmentPrepared(ConfigurableEnvironmentenvironment){
log.info("environmentPrepared{}",LocalDateTime.now());
}
@Override
publicvoidcontextPrepared(ConfigurableApplicationContextcontext){
log.info("contextPrepared{}",LocalDateTime.now());
}
@Override
publicvoidcontextLoaded(ConfigurableApplicationContextcontext){
log.info("contextLoaded{}",LocalDateTime.now());
}
@Override
publicvoidstarted(ConfigurableApplicationContextcontext){
log.info("started{}",LocalDateTime.now());
}
@Override
publicvoidrunning(ConfigurableApplicationContextcontext){
log.info("running{}",LocalDateTime.now());
}
@Override
publicvoidfailed(ConfigurableApplicationContextcontext,Throwableexception){
log.info("failed{}",LocalDateTime.now());
}
}

「這邊 (SpringApplication sa, String[] args) 參數類型的構造函數不能少」 ，因為源碼中限定了使用該參數類型的構造函數反射生成實例。

在 resources 文件下的 META-INF/spring.factotries 文件中配置上該類：

>基于SpringCloudAlibaba+Gateway+Nacos+RocketMQ+Vue&Element實現的后臺管理系統+用戶小程序，支持RBAC動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
>
>*項目地址：
>*視頻教程：

#RunListeners
org.springframework.boot.SpringApplicationRunListener=
com.xxx.ad.diagnostic.tools.api.MySpringApplicationRunListener

?

run 方法中是通過 getSpringFactoriesInstances 方法來獲取 META-INF/spring.factotries 下配置的 SpringApplicationRunListener 的實現類，其底層是依賴 SpringFactoriesLoader 來獲取配置的類的全限定類名，然后反射生成實例；這種方式在 SpringBoot 用的非常多，如 EnableAutoConfiguration、ApplicationListener、ApplicationContextInitializer 等。

?

重啟服務，觀察 MySpringApplicationRunListener 的日志輸出，發現主要耗時都在 contextLoaded 和 started 兩個階段之間，在這兩個階段之間調用了2個方法：refreshContext 和 afterRefresh 方法，而 refreshContext 底層調用的是 AbstractApplicationContext#refresh，Spring 初始化 context 的核心方法之一就是這個 refresh。

Spring 初始化 context

至此基本可以斷定，高耗時的原因就是在初始化 Spring 的 context，然而這個方法依然十分復雜，好在 refresh 方法也將初始化 Spring 的 context 的過程做了整理，并詳細注釋了各個步驟的作用：

初始化 Spring

通過簡單調試，很快就定位了高耗時的原因：

在 invokeBeanFactoryPostProcessors(beanFactory) 方法中，調用了所有注冊的 BeanFactory 的后置處理器；

其中，ConfigurationClassPostProcessor 這個后置處理器貢獻了大部分的耗時；

查閱相關資料，該后置處理器相當重要，主要負責@Configuration、@ComponentScan、@Import、@Bean 等注解的解析；

繼續調試發現，主要耗時都花在主配置類的 @ComponentScan 解析上，而且主要耗時還是在解析屬性 basePackages；

basePackages

即項目主配置類上 @SpringBootApplication 注解的 scanBasePackages 屬性：

scanBasePackages

通過該方法 JavaDoc、查看相關代碼，大體了解到該過程是在遞歸掃描、解析 basePackages 所有路徑下的 class，對于可作為 Bean 的對象，生成其 BeanDefinition；如果遇到 @Configuration 注解的配置類，還得遞歸解析其 @ComponentScan。 至此，服務啟動緩慢的原因就找到了：

作為數據平臺，我們的服務引用了很多第三方依賴服務，這些依賴往往提供了對應業務的完整功能，所以提供的 jar 包非常大；

掃描這些包路徑下的 class 非常耗時，很多 class 都不提供 Bean，但還是花時間掃描了；

每添加一個服務的依賴，都會線性增加掃描的時間；

弄明白耗時的原因后，我有2個疑問：

是否所有的 class 都需要掃描，是否可以只掃描那些提供 Bean 的 class？

掃描出來的 Bean 是否都需要？我只接入一個功能，但是注入了所有的 Bean，這似乎不太合理？

監控 Bean 注入耗時

第二個優化的思路是監控所有 Bean 對象初始化的耗時，即每個 Bean 對象實例化、初始化、注冊所花費的時間，有沒有特別耗時 Bean 對象？同樣的，我們可以利用 SpringBoot 提供了 BeanPostProcessor 接口來監控 Bean 的注入耗時，BeanPostProcessor 是 Spring 提供的 Bean 初始化前后的 IOC 鉤子，用于在 Bean 初始化的前后執行一些自定義的邏輯：

publicinterfaceBeanPostProcessor{
//初始化前
defaultObjectpostProcessBeforeInitialization(Objectbean,StringbeanName)throwsBeansException{
returnbean;
}
//初始化后
defaultObjectpostProcessAfterInitialization(Objectbean,StringbeanName)throwsBeansException{
returnbean;
}
}

對于 BeanPostProcessor 接口的實現類，其前后置處理過程體現在 AbstractAutowireCapableBeanFactory#doCreateBean，這也是 Spring 中非常重要的一個方法，用于真正實例化 Bean 對象，通過 BeanFactory#getBean 方法一路 Debug 就能找到。在該方法中調用了 initializeBean 方法：

protectedObjectinitializeBean(StringbeanName,Objectbean,@NullableRootBeanDefinitionmbd){
...
ObjectwrappedBean=bean;
if(mbd==null||!mbd.isSynthetic()){
//應用所有BeanPostProcessor的前置方法
wrappedBean=applyBeanPostProcessorsBeforeInitialization(wrappedBean,beanName);
}
try{
invokeInitMethods(beanName,wrappedBean,mbd);
}
catch(Throwableex){
thrownewBeanCreationException(
(mbd!=null?mbd.getResourceDescription():null),
beanName,"Invocationofinitmethodfailed",ex);
}
if(mbd==null||!mbd.isSynthetic()){
//應用所有BeanPostProcessor的后置方法
wrappedBean=applyBeanPostProcessorsAfterInitialization(wrappedBean,beanName);
}
returnwrappedBean;
}

通過 BeanPostProcessor 原理，在前置處理時記錄下當前時間，在后置處理時，用當前時間減去前置處理時間，就能知道每個 Bean 的初始化耗時，下面是我的實現：

@Component
publicclassTimeCostBeanPostProcessorimplementsBeanPostProcessor{
privateMapcostMap=Maps.newConcurrentMap();

@Override
publicObjectpostProcessBeforeInitialization(Objectbean,StringbeanName)throwsBeansException{
costMap.put(beanName,System.currentTimeMillis());
returnbean;
}
@Override
publicObjectpostProcessAfterInitialization(Objectbean,StringbeanName)throwsBeansException{
if(costMap.containsKey(beanName)){
Longstart=costMap.get(beanName);
longcost=System.currentTimeMillis()-start;
if(cost>0){
costMap.put(beanName,cost);
System.out.println("bean:"+beanName+"	time:"+cost);
}
}
returnbean;
}
}

BeanPostProcessor 的邏輯是在 Beanfactory 準備好后處理的，就不需要通過 SpringFactoriesLoader 加載了，直接 @Component 注入即可。

重啟服務，通過以上方法排查 Bean 初始化過程，還真的有所發現：

Bean 初始化過程

這個 Bean 初始化耗時43s，具體看下這個 Bean 的初始化方法，發現會從數據庫查詢大量配置元數據，并更新到 Redis 緩存中，所以初始化非常慢：

初始化方法

另外，還發現了一些非項目自身服務的service、controller對象，這些 Bean 來自于第三方依賴：UPM服務，項目中并不需要：

第三方依賴

其實，原因上文已經提到：我只接入一個功能，但我注入了該服務路徑下所有的 Bean，也就是說，服務里注入其他服務的、對自身無用的 Bean。

優化方案

如何解決掃描路徑過多？

想到的解決方案比較簡單粗暴：梳理要引入的 Bean，刪掉主配置類上掃描路徑，使用 JavaConfig 的方式顯式手動注入。以 UPM 的依賴為例，「之前的注入方式」 是，項目依賴其 UpmResourceClient 對象，Pom 已經引用了其 Maven 坐標，并在主配置類上的 scanBasePackages 中添加了其服務路徑："com.xxx.ad.upm"，通過掃描整個服務路徑下的 class，找到 UpmResourceClient 并注入，因為該類注解了 @Service，因此會注入到服務的 Spring 上下文中，UpmResourceClient 源碼片段及主配置類如下：

UpmResourceClient



UpmResourceClient

使用 JavaConfig 的改造方式是：不再掃描 UPM 的服務路徑，而是主動注入。刪除"com.xxx.ad.upm"，并在服務路徑下添加以下配置類：

@Configuration
publicclassThirdPartyBeanConfig{
@Bean
publicUpmResourceClientupmResourceClient(){
returnnewUpmResourceClient();
}
}

?

Tips：如果該 Bean 還依賴其他 Bean，則需要把所依賴的 Bean 都注入； 針對 Bean 依賴情況復雜的場景梳理起來就比較麻煩了，所幸項目用到的服務 Bean 依賴關系都比較簡單，一些依賴關系復雜的服務，觀察到其路徑掃描耗時也不是很高，就不處理了。

?

同時，通過 JavaConfig 按需注入的方式，就不存在冗余 Bean 的情況了，也有利于降低服務的內存消耗；解決了上面的引入無關的 upmService、upmController 的問題。

如何解決 Bean 初始化高耗時？

Bean 初始化耗時高，就需要 case by case 地處理了，比如項目中遇到的初始化配置元數據的問題，可以考慮通過將該任務提交到線程池的方式異步處理或者懶加載的方式來解決。

新的問題

完成以上優化后，本地啟動時間從之前的 7min 左右降低至 40s，效果還是非常顯著的。本地自測通過后，便發布到預發進行驗證，驗證過程中，有同學發現項目接入的 Redis 緩存組件失效了。該組件接入方式與上文描述的接入方式類似，通過添加掃描服務的根路徑"com.xxx.ad.rediscache"，注入對應的 Bean 對象；查看該緩存組件項目的源碼，發現該路徑下有一個 config 類注入了一個緩存管理對象 CacheManager，其實現類是 RedisCacheManager：

CacheManager

緩存組件代碼片段：

RedisCacheManager

本次優化中，我是通過 「每次刪除一條掃描路徑，啟動服務后根據啟動日志中 Bean 缺失錯誤的信息，來逐個梳理、添加依賴的 Bean，保證服務正常啟動」 的方式來改造的，而刪除"com.xxx.ad.rediscache"后啟動服務并無異常，因此就沒有進一步的操作，直接上預發驗證了。這就奇怪了，既然不掃描該組件的業務代碼根路徑，也就沒有執行注入該組件中定義的 CacheManager 對象，為啥用到緩存的地方沒有報錯呢？

嘗試在未添加掃描路徑的情況下，從 ApplicationContext 中獲取 CacheManager 類型的對象看下是否存在？結果發現確實存在 RedisCacheManager 對象：

RedisCacheManager

其實，前面的分析并沒有錯，刪除掃描路徑后生成的 RedisCacheManager 并不是緩存組件代碼中配置的，而是 SpringBoot 的自動化配置生成的，也就是說該對象并不是我們想要的對象，是不符合預期的，下文介紹其原因。

SpringBoot 自動化裝配，讓人防不勝防

查閱 SpringBoot Cache 相關資料，發現 SpringBoot Cache 做了一些自動推斷和注入的工作，原來是 SpringBoot 自動化裝配的鍋呀，接下來就分析下 SpringBoot Cache 原理，明確出現以上問題的原因。

SpringBoot 自動化配置，體現在主配置類上復合注解 @SpringBootApplication 中的@EnableAutoConfiguration 上，該注解開啟了 SpringBoot 的自動配置功能。該注解中的@Import(AutoConfigurationImportSelector.class) 通過加載 META-INF/spring.factotries 下配置一系列 *AutoConfiguration 配置類，根據現有條件推斷，盡可能地為我們配置需要的 Bean。這些配置類負責各個功能的自動化配置，其中用于 SpringBoot Cache 的自動配置類是 CacheAutoConfiguration，接下來重點分析這個配置類就行了。

CacheAutoConfiguration

?

@SpringBootApplication 復合注解中集成了三個非常重要的注解：@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan，其中 @EnableAutoConfiguration 就是負責開啟自動化配置功能；SpringBoot 中有多 @EnableXXX 的注解，都是用來開啟某一方面的功能，其實現原理也是類似的：通過 @Import 篩選、導入滿足條件的自動化配置類。

?

可以看到 CacheAutoConfiguration 上有許多注解，重點關注下@Import({CacheConfigurationImportSelector.class})，CacheConfigurationImportSelector 實現了 ImportSelector 接口，該接口用于動態選擇想導入的配置類，這個 CacheConfigurationImportSelector 用來導入不同類型的 Cache 的自動配置類：

CacheConfigurationImportSelector

通過調試 CacheConfigurationImportSelector 發現，根據 SpringBoot 支持的緩存類型(CacheType)，提供了10種 cache 的自動配置類，按優先級排序，最終只有一個生效，而本項目中恰恰就是 RedisCacheConfiguration，其內部提供的是 RedisCacheManager，和引入第三方緩存組件一樣，所以造成了困惑：

RedisCacheManager

看下 RedisCacheConfiguration 的實現：

RedisCacheConfiguration

這個配置類上有很多條件注解，當這些條件都滿足的話，這個自動配置類就會生效，而本項目恰恰都滿足，同時項目主配置類上還加上了 @EnableCaching，開啟了緩存功能，即使緩存組件沒生效，SpringBoot 也會自動生成一個緩存管理對象；

即：緩存組件服務掃描路徑存在的話，緩存組件中的代碼生成緩存管理對象，@ConditionalOnMissingBean(CacheManager.class) 失效；掃描路徑不存在的話，SpringBoot 通過推斷，自動生成一個緩存管理對象。

這個也很好驗證，在 RedisCacheConfiguration 中打斷點，不刪除掃描路徑是走不到這邊的SpringBoot 自動裝配過程的(緩存組件顯式生成過了)，刪除了掃描路徑是能走到的(SpringBoot 自動生成)。

?

上文多次提到@Import，這是 SpringBoot 中重要注解，主要有以下作用：1、導入 @Configuration 注解的類；2、導入實現了 ImportSelector 或 ImportBeanDefinitionRegistrar 的類；3、導入普通的 POJO。

?

使用 starter 機制，開箱即用

了解緩存失效的原因后，就有解決的辦法了，因為是自己團隊的組件，就沒必要通過 JavaConfig 顯式手動導入的方式改造，而是通過 SpringBoot 的 starter 機制，優化下緩存組件的實現，可以做到自動注入、開箱即用。 只要改造下緩存組件的代碼，在 resources 文件中添加一個 META-INF/spring.factotries 文件，在下面配置一個 EnableAutoConfiguration 即可，這樣項目在啟動時也會掃描到這個 jar 中的 spring.factotries 文件，將 XxxAdCacheConfiguration 配置類自動引入，而不需要掃描"com.xxx.ad.rediscache"整個路徑了：

#EnableAutoConfigurations
org.springframework.boot.autoconfigure.EnableAutoConfiguration=
com.xxx.ad.rediscache.XxxAdCacheConfiguration

審核編輯：劉清