運(yùn)維讓我優(yōu)化SpringBoot啟動(dòng)速度，我是這么干的！
Spring Boot毫無(wú)疑問(wèn)是 Java 后端開(kāi)發(fā)的第一大框架，基于Spring Boot有著一套完整的工具鏈，各種各樣的starter。對(duì)于日常業(yè)務(wù)開(kāi)發(fā)而言，可以說(shuō)是輪子很全。
但隨著微服務(wù)和云原生時(shí)代的流行，Spring Boot應(yīng)用卻暴露出了一些問(wèn)題，其中比較突出的有：
- 啟動(dòng)慢
- 應(yīng)用內(nèi)存占用多
- 云原生應(yīng)用對(duì)啟動(dòng)速度的要求比較高。當(dāng)需要進(jìn)行水平擴(kuò)展時(shí)，要求這些新的實(shí)例必須在足夠短的時(shí)間內(nèi)完成啟動(dòng)，從而盡快的處理新增的請(qǐng)求。
- 云原生應(yīng)用要求在運(yùn)行時(shí)占用盡可能少的資源。盡可能的減少單個(gè)實(shí)例占用的資源，就意味著可以用同樣的成本，支持更多的訪問(wèn)請(qǐng)求。
- 云原生應(yīng)用要求更小的打包體積。云原生應(yīng)用以容器鏡像的形式打包。應(yīng)用鏡像的尺寸越大，所需要的存儲(chǔ)空間也會(huì)越大，推送和拉取鏡像所耗費(fèi)的時(shí)間也會(huì)更長(zhǎng)。
其實(shí)我們都比較清楚大部分的啟動(dòng)時(shí)間是由于 Spring 需要加載各種 Bean 導(dǎo)致啟動(dòng)速度下降的
一、延遲初始化Bean
一般在 SpringBoot 中都擁有很多的耗時(shí)任務(wù)，比如數(shù)據(jù)庫(kù)建立連接、初始線程池的創(chuàng)建等等，我們可以延遲這些操作的初始化，來(lái)達(dá)到優(yōu)化啟動(dòng)速度的目的。Spring Boot 2.2 版本后引入
spring.main.lazy-initialization屬性，配置為 true 會(huì)將所有 Bean 延遲初始化。
spring:
main:
lazy-initialization: true個(gè)人本地開(kāi)啟延遲初始化之后，啟動(dòng)能快了1~2秒。
環(huán)境 | 配置 | (十次平均值)啟動(dòng)速度 |
springboot2+jdk1.8 | ≈10.3s | |
延遲初始化Bean | ≈8.63s |
二、創(chuàng)建掃描索引
Spring5 之后提供了spring-context-indexer功能，可以通過(guò)在編譯時(shí)創(chuàng)建一個(gè)靜態(tài)候選列表來(lái)提高大型應(yīng)用程序的啟動(dòng)性能。
先看官方的解釋?zhuān)?/p>
在項(xiàng)目中使用了@Indexed之后，編譯打包的時(shí)候會(huì)在項(xiàng)目中自動(dòng)生成META-INT/spring.components文件。
當(dāng)Spring應(yīng)用上下文執(zhí)行ComponentScan掃描時(shí)，META-INT/spring.components將會(huì)被CandidateComponentsIndexLoader 讀取并加載，轉(zhuǎn)換為CandidateComponentsIndex對(duì)象，這樣的話@ComponentScan不在掃描指定的package，而是讀取CandidateComponentsIndex對(duì)象，從而達(dá)到提升性能的目的.
我們只需要將依賴(lài)引入，然后在啟動(dòng)類(lèi)上使用@Indexed注解即可。這樣在程序編譯打包之后會(huì)生成
META-INT/spring.components文件，當(dāng)執(zhí)行@ComponentScan掃描類(lèi)時(shí)，會(huì)讀取索引文件，提高掃描速度。
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-indexer</artifactId>
<optional>true</optional>
</dependency>@Indexed
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
環(huán)境 | 配置 | (十次平均值)啟動(dòng)速度 |
springboot2+jdk1.8 | ≈10.3s | |
+延遲初始化Bean | ≈8.63s | |
+創(chuàng)建掃描索引 | ≈7.7s |
其他技巧：
1、減少@ComponentScan @SpringBootApplication掃描類(lèi)時(shí)候的范圍
2、關(guān)閉 Spring Boot 的 JMX監(jiān)控，設(shè)置spring.jmx.enabled=false
3、設(shè)置JVM參數(shù) -noverify ，不對(duì)類(lèi)進(jìn)行驗(yàn)證
4、對(duì)非必要啟動(dòng)時(shí)加載的Bean，延遲加載5、使用Spring Boot的全局懶加載一
5、AOPQ切面盡量不使用注解方式，這會(huì)導(dǎo)致啟動(dòng)時(shí)掃描全部方法7、關(guān)閉endpoint的一些監(jiān)控功能
6、排除項(xiàng)目多余的依賴(lài)jar
7、swagger掃描接口時(shí)，指定只掃描某個(gè)路徑下的類(lèi)10、Feign 客戶端接口的掃描縮小包掃描范圍
到這啟動(dòng)速度應(yīng)該算是優(yōu)化的比較極致了， 但是內(nèi)存占用大依然是問(wèn)題
三、 升級(jí)jdk17
當(dāng)然jdk也在這方面做了很大的努力：
內(nèi)存占用多主要是內(nèi)存占用后不會(huì)歸還操作系統(tǒng)，這個(gè)正在逐步改善：
- G1 JDK12及之后 已支持
- ZGC JDK13及之后 已支持
由于Java語(yǔ)言的特性及Spring Boot的一些實(shí)現(xiàn)方式，決定了即便是開(kāi)啟了G1/ZGC的未使用內(nèi)存及時(shí)歸還操作系統(tǒng)，Spring Boot的內(nèi)存占用，仍然遠(yuǎn)大于Golang這種編譯型語(yǔ)言。
所以，Java想要解決云原生時(shí)代的問(wèn)題，目前的方案基本都是基于GraalVM來(lái)的，不管是Quarkus（夸克）還是Micronaut都是。
那么，Spring Boot有沒(méi)有類(lèi)似的方案呢？：spring-graalvm-native
四、升級(jí)SpringBoot3
spring-graalvm-native是springBoo6/SpringBoot3 非常重大的一個(gè)特性，支持使用 GraalVM 將 SpringBoot 的應(yīng)用程序編譯成本地可執(zhí)行的鏡像文件，可以顯著提升啟動(dòng)速度、峰值性能以及減少內(nèi)存使用。
