GraalVM運(yùn)行模式

JIT模式

• JIT（ Just-In-Time ）模式 ，即時(shí)編譯模式
  JIT模式的處理方式滿足兩個(gè)特點(diǎn)：
  ? Write Once,Run Anywhere -> 一次編寫，到處運(yùn)行。
  ? 預(yù)熱之后，通過內(nèi)置的Graal即時(shí)編譯器優(yōu)化熱點(diǎn)代碼，生成比Hotspot JIT更高性能的機(jī)器碼。

• GraalVM的JIT編譯器在編譯過程中使用了即時(shí)優(yōu)化技術(shù)，包括方法內(nèi)聯(lián)、循環(huán)優(yōu)化、逃逸分析等。這些優(yōu)化技術(shù)可以提高代碼的執(zhí)行效率，并且針對不同的應(yīng)用場景進(jìn)行了優(yōu)化，例如對于大型企業(yè)應(yīng)用、嵌入式系統(tǒng)或數(shù)據(jù)密集型應(yīng)用等。
  

AOT模式

• AOT（Ahead-Of-Time）模式 ，提前編譯模式
• 在AOT模式下，GraalVM將Java字節(jié)碼編譯成本地機(jī)器代碼，并生成一個(gè)可執(zhí)行文件，可以直接在目標(biāo)平臺(tái)上運(yùn)行，而無需Java虛擬機(jī)（JVM）。這使得Java應(yīng)用程序可以像傳統(tǒng)的本地應(yīng)用程序一樣啟動(dòng)和執(zhí)行，而無需依賴JVM。但是不具備跨平臺(tái)特性，不同平臺(tái)使用需要單獨(dú)編譯。這種模式生成的文件稱之為Native Image本地鏡像。
• GraalVM的AOT模式為Java應(yīng)用程序提供了更快的啟動(dòng)時(shí)間和更低的內(nèi)存消耗，同時(shí)仍然保持了良好的性能和跨平臺(tái)的特性。這使得Java應(yīng)用程序可以更好地適應(yīng)云原生、嵌入式和邊緣計(jì)算等場景的需求。
  

GraalVM的問題和解決方案

• GraalVM的AOT模式雖然在啟動(dòng)速度、內(nèi)存和CPU開銷上非常有優(yōu)勢，但是使用這種技術(shù)會(huì)帶來幾個(gè)問題：

1. 跨平臺(tái)問題，在不同平臺(tái)下運(yùn)行需要編譯多次,編譯平臺(tái)的依賴庫等環(huán)境要與運(yùn)行平臺(tái)保持一致。
2. 使用框架之后，編譯本地鏡像的時(shí)間比較長，同時(shí)也需要消耗大量的CPU和內(nèi)存。
3. AOT 編譯器在編譯時(shí)，需要知道運(yùn)行時(shí)所有可訪問的所有類。但是Java中有一些技術(shù)在運(yùn)行時(shí)創(chuàng)建類，例如反射、動(dòng)態(tài)代理等。這些技術(shù)在很多框架比如Spring中大量使用，所以框架需要對AOT編譯器進(jìn)行適配解決類似的問題。

---

• 解決方案：

1. 使用公有云的Docker等容器化平臺(tái)進(jìn)行在線編譯，確保編譯環(huán)境和運(yùn)行環(huán)境是一致的，同時(shí)解決編譯資源問題。
2. 使用SpringBoot3等整合GraalVM AOT模式的框架版本

GraalVM企業(yè)級應(yīng)用

傳統(tǒng)架構(gòu)的問題

• 傳統(tǒng)的系統(tǒng)架構(gòu)中，服務(wù)器等基礎(chǔ)設(shè)施的運(yùn)維、安全、高可用等工作都需要企業(yè)自行完成，存在兩個(gè)主要問題：

1. 開銷大，包括人力的開銷、機(jī)房建設(shè)的開銷
2. 資源浪費(fèi)，面對一些突發(fā)的流量沖擊，比如秒殺，必須提前規(guī)劃好容量準(zhǔn)備好大量的服務(wù)器，這些服務(wù)器在其他時(shí)候會(huì)處于閑置的狀態(tài)，造成大量的浪費(fèi)
   

Serverless架構(gòu)

• 隨著虛擬化技術(shù)、云原生技術(shù)的愈發(fā)成熟，云服務(wù)商提供了一套稱為Serverless無服務(wù)器化的架構(gòu)。企業(yè)無需進(jìn)行服務(wù)器的任何配置和部署，完全由云服務(wù)商提供。比較典型的有亞馬遜AWS、阿里云等。
  

函數(shù)計(jì)算

• Serverless架構(gòu)中第一種常見的服務(wù)是函數(shù)計(jì)算（Function as a Service），將一個(gè)應(yīng)用拆分成多個(gè)函數(shù)，每個(gè)函數(shù)會(huì)以事件驅(qū)動(dòng)的方式觸發(fā)。典型代表有AWS的Lambda、阿里云的FC。
  

---

Serverless應(yīng)用場景

• 函數(shù)計(jì)算主要應(yīng)用場景有如下幾種：

1. 小程序、API服務(wù)中的接口，此類接口的調(diào)用頻率不高，使用常規(guī)的服務(wù)器架構(gòu)容易產(chǎn)生資源浪費(fèi)，使用Serverless可以實(shí)現(xiàn)按需付費(fèi)降低成本，同時(shí)支持自動(dòng)伸縮能應(yīng)對流量的突發(fā)情況。
2. 大規(guī)模任務(wù)的處理，比如音視頻文件轉(zhuǎn)碼、審核等，可以利用事件機(jī)制當(dāng)文件上傳后，自動(dòng)觸發(fā)對應(yīng)的任務(wù)。函數(shù)計(jì)算的計(jì)費(fèi)標(biāo)準(zhǔn)中包含CPU和內(nèi)存使用量，使用GraalVM AOT模式編譯本地鏡像可以節(jié)省成本。
   

Serverless應(yīng)用

• 函數(shù)計(jì)算的服務(wù)資源比較受限，比如AWS的Lambda服務(wù)一般無法支持超過15分鐘的函數(shù)執(zhí)行，所以云服務(wù)商提供另外一套方案：基于容器的Serverless應(yīng)用，無需手動(dòng)配置K8s中的Pod、Service等內(nèi)容，只需選擇鏡像就可自動(dòng)生成應(yīng)用服務(wù)。
• 同樣，Serverless應(yīng)用的計(jì)費(fèi)標(biāo)準(zhǔn)中包含CPU和內(nèi)存使用量，所以使用GraalVM AOT模式編譯出來的本地鏡像可以節(jié)省更多的成本。
  

GraalVM內(nèi)存參數(shù)

• 由于GraalVM是一款獨(dú)立的JDK，大部分HotSpot中的虛擬機(jī)參數(shù)都不適用。
  ? 社區(qū)版只能使用串行垃圾回收器（Serial GC），使用串行垃圾回收器的默認(rèn)最大 Java 堆大小會(huì)設(shè)置為物理內(nèi)存大小的 80%，調(diào)整方式為使用 -Xmx最大堆大小。如果希望在編譯期就指定該大小，可以在編譯時(shí)添加參數(shù)-R:MaxHeapSize=最大堆大小。
  ? G1垃圾回收器只能在企業(yè)版中使用，開啟方式為添加–gc=G1參數(shù)，有效降低垃圾回收的延遲。
  ? 另外提供一個(gè)Epsilon GC，開啟方式：–gc=epsilon ，它不會(huì)產(chǎn)生任何的垃圾回收行為所以沒有額外的內(nèi)存、CPU開銷。如果在公有云上運(yùn)行的程序生命周期短暫不產(chǎn)生大量的對象，可以使用該垃圾回收器，以節(jié)省最大的資源。
• -XX:+PrintGC -XX:+VerboseGC 參數(shù)打印垃圾回收詳細(xì)信息