java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > spring boot应用优化

优化spring boot应用后6s内启动内存减半

作者:kl

这篇文章主要为大家介绍了优化spring boot后应用6s内启动内存减半的优化示例,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步早日升职加薪

前言

taptap-developer是一个spring boot框架驱动的纯Grpc服务,所以,只用了四步,移除了web和spring cloud相关的模块后,启动速度就稳稳的保持在了6s内。除了启动速度提升外,在服务待机状态下,内存锐减了50%左右,从500M左右的内存占用,缩减到了250M不到。

分析日志

日志是一个应用的门面,在未深入了解一个应用的架构前,通过启动的日志输出基本可以分析出这个应用的大概的技术构成。在分析日志之前,在强调一点,这个应用是一个纯Grpc的服务。如上图贴出的日志,是未优化前的系统日志输出,从上到下有四个红色箭头指向,是本次日志分析的关键信息,下面就这四个关键信息,分别分析下。然后总结出常见的优化方法

优化点一:关于SPRING DATA REPOSITORY SCANNING

Spring Data repository是一个高度抽象的数据访问层接口,常见的实现有redis、jdbc、jpa、MongoDB、elasticsearch等等。实现一个Spring-data-xxx包,需要实现

org.springframework.data.repository.core.support.RepositoryFactorySupport抽象类

然后在!/META-INF/spring.factories文件中定义好实现类。spring容器启动时,会扫描加载factories的信息。如果一个项目里有被扫描到有多个spring-data-xxx的实现,启动时日志就会打印

Multiple Spring Data modules found, entering strict repository configuration mode!

优化:看到这个日志,我们就需要检查下项目中是否用到了这些功能,比如引入了spring-data-redis,其实只用到了其携带的jedis,而且jedis实例可能还是自己实例化的,这个时候就可以禁用repository的功能。参考配置如下:

spring.data.redis.repositories.enabled=false

Spring Data repository有三种内置的初始化模式,分别对应如下:

优化:这里可以根据业务特点,选择延迟加载,

参考配置spring.data.jpa.repositories.bootstrap-mode=lazy

Spring Data repository会扫描项目中的实现了repository接口的类,默认情况下会盲扫所有的jar包,

日志输出:Finished Spring Data repository scanning in 148ms. Found 0 repository interfaces.

打印出了扫描repository接口的耗时情况。

优化:

这里可以通过@EnableRedisRepositories(basePackages = "com.taptap")指定扫描的路径

可以显著提升扫描加载的速度

优化点二:关于WEBAPPLICATIONCONTEXT

在spring中,WebApplicationContext是ApplicationContext的增强,由spring-web-mvc实现,增加了servlet、session等web相关的内容。

从日志Initializing Spring embedded WebApplicationContext可以看出,我们初始化了一个web容器,而纯Grpc服务用不到Web的容器上下文,所以移除如下依赖即可

优化:

移除implementation('org.springframework.boot:spring-boot-starter-web')

优化点三:关于SERVLET容器

spring-web-mvc是基于java web标准servlet设计架构的。而servlet是由servlet容器来驱动的,常见的servlet有tocmat、jetty、undertow等。从日志中可看出,我们启动了一个8081的servlet容器。这个不应该出现在纯Grpc的服务中,所以,直接移除即可。

优化:

移除implementation 'org.springframework.boot:spring-boot-starter-undertow'

优化点四:关于ARCHAIUS配置组件

从最后一个箭头指向的日志信息可以分析出,项目引入了archaius配置加载组件,所以项目在启动时,archaius会尝试去加载默认策略的配置源。而我们整体的技术栈,配置中心统一采用了apollo,所以可以直接移除,最后通过分析定位,archaius不是单独引入的,是随着spring-cloud-starter-netflix-hystrix一同引入,这个组件是spring-cloud-netflix微服务框架最常用的,但是在这边,目前所有的微服务都是直接注册到k8s容器的,所有服务的熔断、限流、负载均衡都下沉到了容器基数设施平台,所以应用层面虽然引入了这个包,其实没有实际作用,所以最后移除spring cloud相关组件

优化:

移除implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'和

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-hystrix'组件、

附优化后的日志输出:

系统资源的变化

优化前的

优化后的

最后,基于资源监控图,从三个维度总结下,优化后的资源占用情况:

资源名称优化前优化后
内存500M左右250M左右
总线程数10778
装载类1292210041

以上就是优化spring boot应用后6s内启动内存减半的详细内容,更多关于spring boot应用优化的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文