springboot项目启动慢的问题排查方式

时间:2021-07-23 04:13:20

 

springboot项目启动慢的问题排查

springboot项目,随着时间的推移,启动耗时逐步增加,从几分钟慢慢的达到30多分钟,有点恐怖!

项目中用到技术:hibernate、redis、kafka、线程池等,启动慢的环境使用的是mysql数据库!

 

1.最开始查看的启动日志,是在输出:

org.hibernate.id.UUIDHexGenerator : HHH000409: Using org.hibernate.id.UUIDHexGenerator which does not generate IETF RFC 4122 compliant UUID values; consider using org.hibernate.id.UUIDGenerator instead

后停滞,等相当长时间后继续输出:

o.s.s.concurrent.ThreadPoolTaskExecutor : Initializing ExecutorService "taskExecutor"

springboot项目启动慢的问题排查方式

怀疑是创建kafka、线程池等导致耗时,通过去掉相关对象创建,耗时仍无改观!

 

2. 启动项目,打印日志级别改为debug,查看更详细信息

springboot项目启动慢的问题排查方式

springboot项目启动慢的问题排查方式

发现:大量的alter table 增加外键!奇怪,不是第一次启动项目,mysql库中的表早已创建好,为什么每次都要重复alter?

查看mysql相关表发现无外键,表引擎为MyISAM!此引擎不支持外键!

在使用hibernate自动创建表时,mysql中建表使用的MyISAM引擎,查看配置:

springboot项目启动慢的问题排查方式

  • dialect:应使用org.hibernate.dialect.MySQL5InnoDBDialect

这就解释了:为什么orcle环境下没有此问题,而mysql就有,其随着时间的推移,表中数据逐渐增加,在启动时alter table耗时严重!

 

如何优化SpringBoot的项目的启动速度

日常开发SpringBoot项目启动类都用@SpringBootApplication

 

实际上它是下面三个注解的组合

  • @EnableAutoConfiguration: enable Spring Boot"s auto-configuration mechanism
  • @ComponentScan: enable @Component scan on the package where the application is located (see the best practices)
  • @Configuration: allow to register extra beans in the context or import additional configuration classes

启动慢往往跟@ComponentScan和@EnableAutoConfiguration加载的内容太多有关,一种方法是不用这两个注解,通过@import注解精确指定要加载扫描的类,但要加载的类多时又很麻烦,

 

可以用@SpringBootApplication注解下面的属性

  • exclude: Exclude the list of classes from the auto configuration.
  • excludeNames: Exclude the list of fully qualified class names from the auto configuration. This parameter added since spring boot 1.3.0.
  • scanBasePackageClasses: Provide the list of classes that has to be applied for the @ComponentScan.
  • scanBasePackages Provide the list of packages that has to be applied for the @ComponentScan. This parameter added since spring boot 1.3.0.

另外,如果SpringBoot项目启动很慢,可能意味着你要重新拆分微服务。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持服务器之家。

原文链接:https://blog.csdn.net/Jerry_John/article/details/106354154