随着业务的发展,笔者项目对应的Spring Boot工程的依赖越来越多。随着依赖数量的增长,Spring 容器需要加载更多组件、解析复杂依赖并执行自动装配,导致项目启动时间显著增长。在日常开发或测试过程中,一旦因为配置变更或者其他热部署不生效的变更时,项目重启就需要等待很长的时间影响代码的交付。加快Spring项目的启动可以更好的投入项目中,提升开发效率。
整体环境介绍:
Spring Boot项目主要启动流程都在org.spring-
framework.boot.SpringApplication#run(java.lang.String...)方法中:
public ConfigurableApplicationContext run(String... args) {
StopWatch stopWatch = new StopWatch();
stopWatch.start();
// Spring上下文
ConfigurableApplicationContext context = null;
FailureAnalyzers analyzers = null;
configureHeadlessProperty();
// 初始化SpringApplicationRunListener监听器
SpringApplicationRunListeners listeners = getRunListeners(args);
listeners.starting();
try {
ApplicationArguments applicationArguments = new DefaultApplicationArguments(
args);
// 环境准备
ConfigurableEnvironment environment = prepareEnvironment(listeners,
applicationArguments);
// 打印banner
Banner printedBanner = printBanner(environment);
// 创建上下文
context = createApplicationContext();
analyzers = new FailureAnalyzers(context);
// 容器初始化
prepareContext(context, environment, listeners, applicationArguments,
printedBanner);
// 刷新容器内容
refreshContext(context);
afterRefresh(context, applicationArguments);
// 结束监听广播
listeners.finished(context, null);
stopWatch.stop();
if (this.logStartupInfo) {
new StartupInfoLogger(this.mainApplicationClass)
.logStarted(getApplicationLog(), stopWatch);
}
return context;
} catch (Throwable ex) {
handleRunFailure(context, listeners, analyzers, ex);
throw new IllegalStateException(ex);
}
}
可以看到在启动流程中,监听器应用在了应用的多个生命周期中。并且Spring Boot中也预留了针对listener的扩展点。我们可以借此实现一个自己的扩展点去监听Spring Boot的每个阶段的启动耗时,实现如下:
@Slf4j
public class MySpringApplicationRunListener implements SpringApplicationRunListener{
private Long startTime;
public MySpringApplicationRunListener(SpringApplication application, String[] args){
}
@Override
public void starting(){
startTime = System.currentTimeMillis();
log.info("MySpringListener启动开始 {}", LocalTime.now());
}
@Override
public void environmentPrepared(ConfigurableEnvironment environment){
log.info("MySpringListener环境准备 准备耗时:{}毫秒", (System.currentTimeMillis() - startTime));
startTime = System.currentTimeMillis();
}
@Override
public void contextPrepared(ConfigurableApplicationContext context){
log.info("MySpringListener上下文准备 耗时:{}毫秒", (System.currentTimeMillis() - startTime));
startTime = System.currentTimeMillis();
}
@Override
public void contextLoaded(ConfigurableApplicationContext context){
log.info("MySpringListener上下文载入 耗时:{}毫秒", (System.currentTimeMillis() - startTime));
startTime = System.currentTimeMillis();
}
@Override
public void finished(ConfigurableApplicationContext context, Throwable exception){
log.info("MySpringListener结束 耗时:{}毫秒", (System.currentTimeMillis() - startTime));
startTime = System.currentTimeMillis();
}
}
接着还需要在classpath/META-INF目录下新建spring.factories文件,并添加如下文件内容:
org.springframework.boot.SpringApplicationRunListener=com.vivo.internet.gameactivity.api.web.MySpringApplicationRunListener
至此,借助Listener机制,我们能够追踪Spring Boot启动各阶段的耗时分布,为后续性能优化提供数据支撑。
contextLoaded事件是在run方法中的prepareContext()结束时调用的,因此contextLoaded事件和finished事件之间仅存在两个语句:refreshContext(context)和afterRefresh
(context,applicationArguements)消耗了285秒的时间,调试一下就能发现主要耗时在refreshContext()中。
refreshContext()最终调用到org.spring-framework.context.support.AbstractApplicationContext#refresh方法中,这个方法主要是beanFactory的预准备、对beanFactory完成创建并进行后置处理、向容器添加bean并且给bean添加属性、实例化所有bean。通过调试发现,finishBeanFactoryInitialization(beanFactory) 方法耗时最久。该方法负责实例化容器中所有的单例 Bean,是启动性能的关键影响点。
Spring Boot也是利用的Spring的加载流程。在Spring中可以实现InstantiationAwareBeanPost-
Processor接口去在Bean的实例化和初始化的过程中加入扩展点。因此我们可以实现该接口并添加自己的扩展点找到处理耗时的Bean。
@Service
public class TimeCostCalBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
private Map<String, Long> costMap = Maps.newConcurrentMap();
@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
if (!costMap.containsKey(beanName)) {
costMap.put(beanName, System.currentTimeMillis());
}
return null;
}
@Override
public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
return true;
}
@Override
public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
return pvs;
}
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (costMap.containsKey(beanName)) {
Long start = costMap.get(beanName);
long cost = System.currentTimeMillis() - start;
// 只打印耗时长的bean
if (cost > 5000) {
System.out.println("bean: " + beanName + "\ttime: " + cost + "ms");
}
}
return bean;
}
}
具体原理就是在Bean开始实例化之前记录时间,在Bean初始化完成后记录结束时间,打印实例化到初始化的时间差获得Bean的加载总体耗时。结果如图:
可以看到有许多耗时在10秒以上的类,接下来可以针对性的做优化。值得注意的是,统计方式为单点耗时计算,未考虑依赖链上下文对整体加载顺序的影响,实际优化还需结合依赖关系分析。
@Bean(name = "singletonDataSource")
public DataSource singletonDataSource(DefaultDataSourceWrapper dataSourceWrapper) throws SQLException {
//先初始化连接
dataSourceWrapper.getMaster().init();
//构建分库分表数据源
String dataSource0 = "ds0";
Map<String, DataSource> dataSourceMap = new HashMap<>();
dataSourceMap.put(dataSource0, dataSourceWrapper.getMaster());
//分库分表数据源
DataSource shardingDataSource = ShardingDataSourceFactory
.createDataSource
(dataSourceMap,shardingRuleConfiguration, prop);
return shardingDataSource;
}
singletonDataSource是一个分库分表的数据源,连接池采用的是Druid
,分库分表组件采用的是公司内部优化后的中间件。通过简单调试代码发现,整个Bean耗时的过程发生在createDataSource方法,该方法中会调用createMetaData方法去获取数据表的元数据,最终运行到loadDefaultTables方法。该方法如下图,会遍历数据库中所有的表。因此数据库中表越多,整体就越耗时。
笔者的测试环境数据库中有很多的分表,这些分表为了和线上保持一致,分表的数量都和线上是一样的。
因此在测试环境启动时,为了加载这些分表会更加的耗时。可通过将分表数量配置化,使测试环境在不影响功能验证的前提下减少分表数量,从而加快启动速度。
activityServiceImpl启动中,主要会进行活动信息的查询初始化,这是一个耗时的操作。类似同样的操作在工程的其他类中也存在。
@Service
public class ActivityServiceImpl implements ActivityService, InitializingBean{
// 省略无关代码
@Override
public void afterPropertiesSet() throws Exception {
initActivity();
}
// 省略无关代码
}
可以通过将afterPropertiesSet()异步化的方式加速项目的启动。
观察Spring源码可以注意到afterPropertiesSet方法是在AbstractAutowireCapableBeanFactory#
invokeInitMethods中调用的。在这个方法中,不光处理了afterPropertiesSet方法,也处理了init-method。
因此我们可以写一个自己的BeanFactory继承AbstractAutowireCapableBeanFactory,将invokeInitMethods方法进行异步化重写。考虑到AbstractAutowireCapableBeanFactory是个抽象类,有额外的抽象方法需要实现,因此继承该抽象类的子类DefaultListableBeanFactory。具体实现代码如下:
public class AsyncInitListableBeanFactory extends DefaultListableBeanFactory{
public AsyncInitBeanFactory(ConfigurableListableBeanFactory beanFactory){
super(beanFactory);
}
@Override
protected void invokeInitMethods(String beanName, Object bean, RootBeanDefinition mbd)throws Throwable {
if (beanName.equals("activityServiceImpl")) {
AsyncTaskExecutor.submitTask(() -> {
try {
super.invokeInitMethods(beanName, bean, mbd);
} catch (Throwable throwable) {
throwable.printStackTrace();
}
});
} else {
super.invokeInitMethods(beanName, bean, mbd);
}
}
}
又因为Spring在refreshContext()方法之前的prepareContext()发放中针对initialize方法提供了接口扩展(applyInitializers())。因此我们可以通过实现该接口并将我们的新的BeanFactory通过反射的方式更新到Spring的初始化流程之前。
public interface ApplicationContextInitializer<C extends ConfigurableApplicationContext> {
/**
* Initialize the given application context.
* @param applicationContext the application to configure
*/
void initialize(C applicationContext);
}
改造后的代码如下,新增AsyncAccelerate-
Initializer类实现ApplicationContextInitializer接口:
本文系作者在时代Java发表,未经许可,不得转载。
如有侵权,请联系nowjava@qq.com删除。