經過多年的演進，Java語言的功能和性能都在不斷地發展和提高，但是冷啟動開銷較大的問題長期存在，難以從根本上解決。本文先討論冷啟動問題的根本原因，然后介紹一種新近提出的徹底解決Java冷啟動問題的技術方案——Java靜態編譯技術。

什么是冷啟動？

所謂冷啟動問題是指Java應用并不是即起即用的，而需要經過虛擬機初始化后才能達到可用狀態，再經過程序預熱才能達到最佳性能。圖1給出了Java程序的運行時性能隨運行時間（實際上是代碼重復執行次數）的變化示意圖。

圖 1 Java程序運行時性能演化示意圖

橫坐標是程序運行時間，時間越長代表程序中代碼被重復執行的次數越多；縱坐標是程序的響應時間，響應越快代表運行時性能越好。

可以看出程序響應能力分成了四個部分：第一個階段為無窮大，因為程序啟動時需要首先初始化Java虛擬機，然后初始化應用程序，在這個階段應用是不會有響應的。隨后經過解釋執行、C1實時編譯和C2實時編譯，應用的響應時間才從高、中到了低，最終進入穩定執行階段。前三個階段就是冷啟動，也可以看作程序預熱，最后一個階段為穩定執行，此時的程序運行時性能最好。

在傳統的單機或者服務器部署的場景中，冷啟動問題并不明顯，一來是應用執行時間足夠長，冷啟動問題就被淡化了；二來人們還可以提前將服務預熱準備好，以最好的狀態迎接用戶的服務請求。

但是在云原生Serverless應用的場景中，首次請求必須經過無響應階段，才會落在響應時間高的為位置，后續請求也會落在高的階段，只有經過足夠多的請求后才會逐漸落入穩定階段。冷啟動問題使得Java在Serverless場景下無法與Node.js、Go等具有快速啟動優勢的的語言的競爭中，落于下風。

---

冷啟動問題的根本原因

當我們執行一個Java應用程序時，看似是從主函數（Java可執行應用程序的入口是主函數）開始的，但實際需要在JVM初始化后才會調用Java主函數開始執行應用程序。

我們將圖 1展示的抽象模型進一步細化，可以得到如圖 2所示的Java程序的執行生命周期模型：Java程序可以分為VM初始化（VM init）、應用初始化（App init）、應用預熱（App active warmup）、應用穩定（App active steady）和關閉（shutdown）這5個階段。

圖 2??Java應用程序的運行生命周期示意圖

圖2的橫坐標代表應用執行的時間順序，縱坐標代表CPU利用率，各個顏色的區域代表該行為的CPU使用率，紅色區域的VM表示JVM、青色的CL代表類加載（Class Loading），白色的是實時編譯（Just In Time，JIT），黃色的代表垃圾回收（GC），淺綠色代表解釋執行應用程序，綠色代表執行經過JIT編譯的應用代碼。

從圖2中可以看到各個階段中花費時間最多的行為是什么，但這里的使用情況并不是按實際比例繪制的，而是只反映整體趨勢的示意，因為具體的數據會隨應用不同而變化。

從圖 2可以看到Java程序的運行生命周期是：首先啟動JVM，執行各種VM的初始化動作；然后調用Java程序的主函數進入應用初始化，此時才會開始通過解釋執行方式運行Java代碼，隨著Java代碼運行而同時開始的還有GC，JIT會在出現熱點函數時才開始；當程序初始化完成后，開始執行應用程序的業務代碼，此時才算進入了程序執行的預熱階段，這個階段會有大量的類加載和JIT編譯行為；當程序被充分預熱后，就進入了運行時性能最好的穩定階段，此時的理想狀態是只有應用本身和GC在運行，其他的行為都已漸漸退出；最后是關閉應用，各個行為次第結束。

---

Java 語言最初被認為是一種解釋型語言，因為 Java 源代碼并非被先編譯為與機器平臺相關的匯編代碼再執行，而是先編譯為與平臺無關的字節碼（bytecode），然后由 JVM 解釋執行。

解釋執行是由 JVM 將字節碼逐條翻譯為匯編代碼，然后執行的過程。經過解釋的代碼缺少編譯優化，因此運行時性能較低。不過解釋執行非常靈活，可以支持諸如動態類加載這樣的動態特性。Java 可以在運行時解釋執行一段在編譯時尚不存在的代碼，這種特性對于編譯執行類型的語言來說是難以想象的。

為了解決運行時性能低的問題，Java 引入了實時編譯技術（JIT，Just In time），在運行時將熱點函數編譯為匯編代碼，當程序再次運行到經過實時編譯的函數時，就可以執行經過編譯和優化的匯編代碼，而不再需要解釋執行了。由于編譯是在運行時進行的，因此 JIT 編譯器可以獲得代碼實際運行的路徑、熱點和變量值等信息，基于此可以做出非常激進的編譯優化，從而獲得執行效率更高的代碼。

OpenJDK使用的JIT編譯器分為C1和C2，前者編譯優化較少，但是編譯所消耗資源也較少；后者編譯得到的代碼性能最好，但是編譯消耗的資源也較多。

現在的Java程序基本都是采用解釋執行加JIT執行的混合模式，當函數執行次數較少時解釋執行，而當函數的執行次數超過一定閾值后再JIT執行，從而實現了熱點函數JIT 執行、非熱點函數解釋執行的效果。

不過既然JIT帶來了非常顯著的性能優勢，為什么不全部采用JIT方式呢？因為編譯優化本身是需要占用系統資源的資源密集型運算，它會影響應用程序的運行時性能，在實踐中甚至出現過JIT線程占用過多資源，導致應用程序不能執行的狀況。此外，如果代碼執行的次數較少，編譯優化代碼造成的性能損失可能會大于編譯執行帶來的性能提升。

所以冷啟動問題的原因有兩點：一是Java的虛擬機模型機制，二是從解釋執行到JIT執行的分層次執行模型。這兩點在當前的Java模型下是無法更改的，它們都是Java運行時的基石。

---

如何解決冷啟動問題

但這個問題并不是無解，我們可以換個角度思路思考。Java虛擬機的主要作用是提供跨平臺能力，以支持與平臺無關的Java字節碼可以在不同的操作系統中運行。解釋執行、JIT執行等問題都是由此衍生而來的。如果我們并不需要跨平臺能力，是不是可以將Java程序直接編譯為目標平臺的機器碼，然后提供必要的運行時支持，讓它以操作系統原生程序的形式運行呢？如此一來就徹底解決了冷啟動問題。

答案是肯定的，這就是Java的靜態編譯技術。

Java靜態編譯是指將Java程序的字節碼在單獨的離線階段編譯為匯編代碼，其輸入為Java的字節碼，輸出為操作系統本地原生程序。“靜態”是相對傳統Java程序的動態性而言的，因為傳統Java程序是在運行時動態地解釋執行和JIT編譯，而靜態編譯需要在執行前就靜態地完成程序的編譯。目前由Oracle開發的高性能跨語言運行時框架開源項目GraalVM中就提供了Java靜態編譯所需的編譯工具鏈、編譯框架、編譯器和運行時等全套支持，并且已經達到了生產可用的程度。

GraalVM的靜態編譯的基本原則是封閉性假設（closed world assumption），要求編譯器在編譯時必須掌握運行時所需的全部信息，換句話說，就是運行時不能出現任何編譯時未知的內容。這是因為應用程序的可達范圍在靜態編譯時被限定了，因為沒有了類加載器、解釋器等組件，不能在運行時解析和執行任何動態引入的類。

與傳統Java運行模型相比，GraalVM的靜態編譯運行模型有兩大特點：

一是靜態編譯后的可執行程序已經是本地程序，而且自包含了輕量級運行時支持，因此不再額外需要Java虛擬機。沒有了JVM，自然也就消除了圖 1中的響應時間無窮大階段，使得應用程序達到即起即用的狀態。另外，因為JVM的運行也需要消耗一部分內存，去掉JVM后應用程序的內存占用也大幅降低。

二是靜態編譯后的程序也經過了眾多的編譯優化，運行時不再需要經過解釋執行和JIT編譯，既避免了解釋執行的低效，也避免了JIT編譯的CPU開銷，還解決了傳統Java執行模型中無法充分預熱，始終存在解釋執行的問題，因此可以保證應用程序始終以穩定的性能執行，不會出現性能波動。

這兩個基本特點解決了Java程序冷啟動問題—JVM初始化的開銷和從解釋執行到JIT編譯執行的開銷，因此靜態編譯后的Java程序可以獲得極速啟動的效果。

圖 3 給出了OpenJDK和靜態編譯后的Java程序的性能對比示意，其中藍色線條為OpenJDK的運行時性能變化情況，紅色線條為社區版GraalVM靜態編譯后的程序運行時性能變化情況，可以看到經過社區版GraalVM的靜態編譯后的Java應用的性能穩定地處于OpenJDK的C1編譯器的水平。而商業版的GraalVM靜態編譯甚至可以使程序達到C2編譯器的編譯后的性能水平。

圖 3 OpenJDK與GraalVM靜態編譯的Java程序性能對比示意圖

由此可見，Java靜態編譯技術能夠徹底解決Java冷啟動問題，使得Java語言在云原生應用的浪潮中繼續保持強大的競爭力，可謂是Java語言的“大殺器”了。

在評論區留言你對本文的觀點

CSDN云計算將選出三名優質留言送出

《GraalVM與Java靜態編譯：原理與應用》一本

截至1月17日14:00點

往期推薦

低代碼發展專訪系列之八：低代碼平臺能夠打破企業「應用孤島」現象嗎？

Medusa又一個開源的替代品

用了HTTPS，沒想到還是被監控了

快速搭建實驗環境：使用 Terraform 部署 Proxmox 虛擬機

點分享

點收藏

點點贊

點在看

總結

以上是生活随笔為你收集整理的性能提升一个数量级，大杀器来了！| 文内福利的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。