Spring Boot毫無疑問是 Java 后端開發的第一大框架，基于Spring Boot有著一套完整的工具鏈，各種各樣的starter。對于日常業務開發而言，可以說是輪子很全。

但隨著微服務和云原生時代的流行，Spring Boot應用卻暴露出了一些問題，其中比較突出的有：

• 啟動慢
• 應用內存占用多
• 云原生應用對啟動速度的要求比較高。當需要進行水平擴展時，要求這些新的實例必須在足夠短的時間內完成啟動，從而盡快的處理新增的請求。
• 云原生應用要求在運行時占用盡可能少的資源。盡可能的減少單個實例占用的資源，就意味著可以用同樣的成本，支持更多的訪問請求。
• 云原生應用要求更小的打包體積。云原生應用以容器鏡像的形式打包。應用鏡像的尺寸越大，所需要的存儲空間也會越大，推送和拉取鏡像所耗費的時間也會更長。

其實我們都比較清楚大部分的啟動時間是由于 Spring 需要加載各種 Bean 導致啟動速度下降的

一、延遲初始化Bean

一般在 SpringBoot 中都擁有很多的耗時任務，比如數據庫建立連接、初始線程池的創建等等，我們可以延遲這些操作的初始化，來達到優化啟動速度的目的。Spring Boot 2.2 版本后引入
spring.main.lazy-initialization屬性，配置為 true 會將所有 Bean 延遲初始化。

個人本地開啟延遲初始化之后，啟動能快了1~2秒。

二、創建掃描索引

Spring5 之后提供了spring-context-indexer功能，可以通過在編譯時創建一個靜態候選列表來提高大型應用程序的啟動性能。

先看官方的解釋：

在項目中使用了@Indexed之后，編譯打包的時候會在項目中自動生成META-INT/spring.components文件。

當Spring應用上下文執行ComponentScan掃描時，META-INT/spring.components將會被CandidateComponentsIndexLoader 讀取并加載，轉換為CandidateComponentsIndex對象，這樣的話@ComponentScan不在掃描指定的package，而是讀取CandidateComponentsIndex對象，從而達到提升性能的目的.

我們只需要將依賴引入，然后在啟動類上使用@Indexed注解即可。這樣在程序編譯打包之后會生成
META-INT/spring.components文件，當執行@ComponentScan掃描類時，會讀取索引文件，提高掃描速度。

 

其他技巧：

1、減少@ComponentScan @SpringBootApplication掃描類時候的范圍

2、關閉 Spring Boot 的 JMX監控，設置spring.jmx.enabled=false

3、設置JVM參數 -noverify ，不對類進行驗證

4、對非必要啟動時加載的Bean，延遲加載5、使用Spring Boot的全局懶加載一

5、AOPQ切面盡量不使用注解方式，這會導致啟動時掃描全部方法7、關閉endpoint的一些監控功能

6、排除項目多余的依賴jar

7、swagger掃描接口時，指定只掃描某個路徑下的類10、Feign 客戶端接口的掃描縮小包掃描范圍

到這啟動速度應該算是優化的比較極致了， 但是內存占用大依然是問題

三、 升級jdk17

當然jdk也在這方面做了很大的努力：

內存占用多主要是內存占用后不會歸還操作系統，這個正在逐步改善：

• G1 JDK12及之后 已支持
• ZGC JDK13及之后 已支持

由于Java語言的特性及Spring Boot的一些實現方式，決定了即便是開啟了G1/ZGC的未使用內存及時歸還操作系統，Spring Boot的內存占用，仍然遠大于Golang這種編譯型語言。

所以，Java想要解決云原生時代的問題，目前的方案基本都是基于GraalVM來的，不管是Quarkus（夸克）還是Micronaut都是。

那么，Spring Boot有沒有類似的方案呢？：spring-graalvm-native

四、升級SpringBoot3

spring-graalvm-native是springBoo6/SpringBoot3 非常重大的一個特性，支持使用 GraalVM 將 SpringBoot 的應用程序編譯成本地可執行的鏡像文件，可以顯著提升啟動速度、峰值性能以及減少內存使用。