云原生時代的Spring Boot-魔扣目錄

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

但隨著云原生時代的到來，Spring Boot應(yīng)用或者說是Java應(yīng)用卻暴露出了一些問題，其中比較突出的有：

啟動慢
應(yīng)用內(nèi)存占用多

其中啟動慢的主要原因：代碼編譯。

當然對于Spring Boot來說，Bean實例注入也會花費一定的時間，但花費時間相比編譯會小的多。大家可以通過開啟延遲初始化試試。

spring:
  main:
    lazy-initialization: true

Spring Boot 2.2開始支持。

個人本地開啟延遲初始化之后，啟動能快了1~2秒，整個啟動時間10秒左右。

測試機配置：i7-6500U 2.50@GHz 內(nèi)存:16G

內(nèi)存占用多主要是內(nèi)存占用后不會歸還操作系統(tǒng)，這個正在逐步改善：

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

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

2017年9月，Java 9發(fā)布，在Java 9中引入了AOT（Ahead-of-Time Compilation）。

AOT在內(nèi)部使用是通過GraalVM來生成代碼的。

但對于普通用戶而言通過Java的AOT去編譯Spring程序還是不可行的。

那么有沒有一種比較優(yōu)雅的解決方案呢？既能使用Spring Boot又能像Golang一樣啟動快、內(nèi)存占用低？

有朋友可能想到了Quarkus、Micronaut，但這兩個框架如果是從頭開始開發(fā)，可以考慮一下，但還是要注意兩點：

需要去學(xué)習(xí)使用
某些庫有可能不支持

其實，Java想要解決云原生時代的問題，目前的方案基本都是基于GraalVM來的，不管是Quarkus還是Micronaut都是。

那么，Spring Boot有沒有類似的方案呢？

答案是有的。

在
spring-projects-experimental Organizations下有這么一個項目：spring-graalvm-native

目前已發(fā)布到0.7.0 release，不過從github的文檔中可以看到這個項目的狀態(tài)仍然是alpha，也就是說目前用到生產(chǎn)中還是為時過早。

希望能早日spring-graalvm-native能早日發(fā)布生產(chǎn)可用版本吧。

graalvm+AOT如此美好？

其實，GraalVM目前來看還是有一些局限的：

Not Supported

Dynamic Class Loading/Unloading
Runtime Bytecode Generation *
InvokeDynamic Bytecode and Method Handles
……

Require Configuration

Resource Access
Reflection
Dynamic Proxy（JDK，not CGLIB）
JNI (Java Native Interface)
……

更詳細限制可以看：

https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md

同時，由于提前編譯無法像JIT那樣獲取到運行時的信息，所以在做Profile-Guided Optimization，PGO時，會更麻煩。

具體做法：
https://www.graalvm.org/docs/release-notes/19_2/

JIT會做的典型的PGO1：

type-feedback optimization：主要針對多態(tài)的面向?qū)ο蟪绦騺碜鰞?yōu)化。根據(jù)profile收集到的receiver type信息來把原本多態(tài)的虛方法調(diào)用點（virtual method call site）或?qū)傩栽L問點（property access site）根據(jù)類型來去虛化（devirtualize）。
single-value profiling：這個相對少見一些。它的思路是有些參數(shù)、函數(shù)返回值可能在一次運行中只會遇到一個具體值。如果是這樣的話可以把那個具體值給記錄下來，然后在JIT編譯時把它當作常量來做優(yōu)化，于是常見的常量相關(guān)優(yōu)化（常量折疊、條件常量傳播等）就可以針對一個靜態(tài)意義上本來不是常量的值來做了。branch-profile-based code scheduling：主要目的是把“熱”的（頻繁執(zhí)行的）代碼路徑集中放在一起，而把“冷”的（不頻繁執(zhí)行的）代碼路徑放到別的地方。AOT編譯的話常常會利用一些靜態(tài)的啟發(fā)條件來猜測哪些路徑比較熱，或者讓用戶指定哪些路徑比較熱（例如likely()/unlikely()宏），而JIT搭配PGO的話可以有比較準確的路徑熱度信息，對應(yīng)可以做的優(yōu)化也就更吻合實際執(zhí)行情況，于是效果會更好。
profile-guided inlining heuristics：根據(jù)profile信息得知函數(shù)調(diào)用點的熱度，從而影響內(nèi)聯(lián)決策——對某個調(diào)用點，到底值不值得把目標函數(shù)內(nèi)聯(lián)進來。
implicit exception：隱式異常，例如Java/C#的空指針異常檢查，又例如Java/C#的除以零檢查。這些異常如果在某塊代碼里從來沒有發(fā)生過，就可以用更快的方式來實現(xiàn)，而不必生成顯式檢查代碼。但如果在某塊代碼經(jīng)常發(fā)生這種異常，則顯式檢查會更快。

附錄：

JIT會做的典型的PGO

https://www.zhihu.com/question/52572852??

個人思考：

其實，通過openjdk jeps及spring boot的一些實驗性的項目可以看出，Java正在實現(xiàn)一些新的特性：比如本文提到的AOT,Loom來解決Java的一些痛點。

但這些新的特性具體什么時候能用于生產(chǎn)還是一個未知數(shù)。

相對于Golang，在使用Java的過程中，我個人感覺有以下幾個痛點：