紅魔電競平板評測：大屏幕硬實(shí)力
前言：三年的疫情因?yàn)橐暇W(wǎng)課的原因激活了平板市場，如今網(wǎng)課的時(shí)代已經(jīng)過去，大家的生活都恢復(fù)到了正軌，這也就意味著，真正考驗(yàn)平板電腦生存的環(huán)境來了。也就是面對著這種殘酷的
圖 1：Java 程序運(yùn)行過程
上述過程既給 Java 程序帶來了其他編程語言不具備的優(yōu)勢，比如跨平臺，易上手等。但同時(shí)也給 Java 程序帶來了一些性能問題，比如啟動速度慢和運(yùn)行時(shí)內(nèi)存占用高等。
圖 1 中 Java 程序啟動運(yùn)行詳細(xì)過程如下圖 2 所示：
圖 2：Java 程序的啟動過程分析[1]
一個(gè) Java 應(yīng)用啟動過程首先需要加載該應(yīng)用程序?qū)?yīng)的 JVM 虛擬機(jī)軟件程序到內(nèi)存中，如上圖紅色部分描述所示。然后 JVM 虛擬機(jī)再加載對應(yīng)的應(yīng)用程序到內(nèi)存中，該過程對應(yīng)上圖中的淺藍(lán)色類加載（Class Load，CL）部分。在類加載過程中，應(yīng)用程序就會開始被解釋執(zhí)行，對應(yīng)上圖中淺綠色部分。解釋執(zhí)行過程 JVM 對垃圾對象進(jìn)行回收，對應(yīng)上圖中的黃色部分。隨著程序的運(yùn)行的深入，JVM 會采用及時(shí)編譯（Just In Time，JIT）技術(shù)對執(zhí)行頻率較高的代碼進(jìn)行編譯優(yōu)化，以便提升應(yīng)用程序運(yùn)行速度。JIT 過程對應(yīng)上圖中的白色部分。經(jīng)過 JIT 編譯優(yōu)化后的代碼對應(yīng)圖中深綠色部分。
經(jīng)過上述分析，不難看出，一個(gè) Java 程序從啟動到達(dá)到被JIT動態(tài)編譯優(yōu)化會經(jīng)過 VM init，App init 和 App active 幾個(gè)階段，相比于其他一些編譯型語言，其冷啟動問題比較嚴(yán)重。
除了冷啟動問題，從上述分析中不難看出，一個(gè) Java 程序運(yùn)行過程中，什么都不做首先就需要加載一個(gè) JVM 虛擬機(jī)，該操作一般占用一定內(nèi)存。另外，由于 Java 程序是先解釋執(zhí)行字節(jié)碼，然后再做 JIT 編譯優(yōu)化。
由于相比于一些編譯型語言其將編譯優(yōu)化的動作后置到運(yùn)行時(shí)，因此非常容易出現(xiàn)實(shí)際加載的代碼比實(shí)際需要運(yùn)行的代碼多很多的情況，造成了一些無效內(nèi)存占用情況。綜上所述就是為什么很多人常詬病 Java 程序運(yùn)行內(nèi)存占用高的幾點(diǎn)主要原因。
既然，先解釋執(zhí)行再動態(tài)編譯的 Java 傳統(tǒng)程序運(yùn)行方式存在上述諸多問題，那有沒有一些方式可以讓 Java 程序也跟其他程序語言，比如 C/C++ 一樣，先編譯后執(zhí)行解決上述問題呢？
答案是肯定的，提前編譯（Ahead-of-Time Compilation，AOT Compilation）或者叫靜態(tài)編譯在 Java 領(lǐng)域很早就被提了出來。其核心思想就是將 Java 程序的編譯階段提前到程序啟動前，然后在編譯階段進(jìn)行代碼編譯優(yōu)化，讓程序啟動既巔峰，消除冷啟動，降低運(yùn)行時(shí)內(nèi)存開銷。
Java 領(lǐng)域靜態(tài)編譯的實(shí)現(xiàn)技術(shù)有很多，其中最具代表性的還屬 Oracle 推出的 GraalVM 開源高性能多語言運(yùn)行時(shí)平臺[2]。看到這里有的讀者可能會問：“高性能多語言運(yùn)行時(shí)平臺是什么？它跟靜態(tài)編譯本身有什么關(guān)系？”。
圖 3：GraalVM 多語言運(yùn)行時(shí)平臺
如上圖 3 所示，GraalVM 中通過提供 Truffle 解釋器實(shí)現(xiàn)框架，讓開發(fā)人員可以使用 Truffle 提供的 API 快速實(shí)現(xiàn)特定語言的解釋器從而實(shí)現(xiàn)對上圖中各種編程語言所寫的程序都能進(jìn)行編譯運(yùn)行的效果，從而成為一個(gè)多語言運(yùn)行時(shí)平臺。GraalVM 實(shí)現(xiàn)靜態(tài)編譯能力的編譯器就是 GraalVM JIT Compiler。靜態(tài)編譯框架和運(yùn)行時(shí)由 Substrate VM 子項(xiàng)目實(shí)現(xiàn)，兼容 OpenJDK 運(yùn)行時(shí)實(shí)現(xiàn)，提供了原生鏡像程序運(yùn)行時(shí)的異常處理、同步調(diào)度、線程管理、內(nèi)存管理等功能。
因此，GraalVM 不僅可以作為一個(gè)多語言運(yùn)行時(shí)平臺，而且由于其中提供的 GraalVM JIT Compiler 靜態(tài)編譯器，其可用來對 Java 程序進(jìn)行靜態(tài)編譯。
說完靜態(tài)編譯和 GraalVM 之間的關(guān)系，有的讀者可能會好奇，基于 GraalVM 的靜態(tài)編譯與常規(guī)的 JVM 解釋執(zhí)行方式有哪些區(qū)別？基于靜態(tài)編譯的 Java 程序相比于目前應(yīng)用廣泛的 JVM 運(yùn)行時(shí)編譯 Java 程序整個(gè)從代碼編寫到編譯執(zhí)行的區(qū)別如下圖 4 所示：
圖 4：靜態(tài)編譯與傳統(tǒng) JVM 運(yùn)行過程對比
相比于 JVM 運(yùn)行時(shí)方式，靜態(tài)編譯在運(yùn)行之前會先對程序解析編譯，然后生成一個(gè)跟運(yùn)行時(shí)環(huán)境強(qiáng)相關(guān)的 native image 可執(zhí)行文件，最后直接執(zhí)行該文件即可啟動程序進(jìn)行執(zhí)行。
說到這里可能有的讀者又好奇，上圖 4 中的靜態(tài)編譯過程到底會對 Java 程序做哪些解析操作？靜態(tài)編譯后的可執(zhí)行程序垃圾回收問題怎么解決？如下圖 5 所示，其描述了 GraalVM 靜態(tài)編譯技術(shù)實(shí)現(xiàn)中編譯過程的輸入與輸出內(nèi)容。
圖 5：靜態(tài)編譯輸入輸出
圖 5 中左側(cè)前三個(gè)輸入內(nèi)容 Applicaton，Libraries 和 JDK 是一個(gè) Java 程序編譯運(yùn)行必備的三部分，不必多說。而 Substrate VM 就是 GraalVM 中實(shí)現(xiàn)靜態(tài)編譯的核心部分，在整個(gè)靜態(tài)編譯過程中扮演了重要作用。
其中在靜態(tài)分析過程中，如上圖 5 中間部分中所繪制，Substrate VM 通過上下文不敏感的指向分析（Points-to Analysis）來對應(yīng)用程序做靜態(tài)分析，其可以在不需要運(yùn)行程序的情況下，基于源程序分析給出所有可能的可達(dá)函數(shù)列表然后作為后續(xù)編譯階段的輸入對程序進(jìn)行靜態(tài)編譯。該過程由于靜態(tài)分析的局限性，無法覆蓋 Java 中的反射、動態(tài)代理、JNI 調(diào)用等動態(tài)特性。這也造成了很多的 Java 框架由于在實(shí)現(xiàn)過程中使用了大量的上述特性，因此，都難以直接基于 Substrate VM 完成對自身所有代碼的靜態(tài)分析，需要通過額外的外部配置[3]來解決靜態(tài)分析本身的不足。
例如像 Spring 社區(qū)因此開發(fā)了 AOT Engine[4]如下圖 6 所示來幫助解決 Spring 項(xiàng)目對其中的反射，動態(tài)代理等內(nèi)容進(jìn)行靜態(tài)分析處理并將其轉(zhuǎn)換為 Substrate VM 能在編譯階段可識別的內(nèi)容，確保對 Spring 應(yīng)用可基于 Substrate VM 順利完成靜態(tài)編譯。
圖 6：Spring AOT Engine
在靜態(tài)分析完成后，基于靜態(tài)分析結(jié)果的可達(dá)函數(shù)列表，調(diào)用上文介紹的 GraalVM 中的 GraalVM JIT Compiler 編譯器將應(yīng)用程序編譯為與目標(biāo)平臺強(qiáng)相關(guān)的本地代碼以完成編譯過程。
編譯完成后，就會進(jìn)入到上圖 5 右側(cè) Native 可執(zhí)行文件生成階段。在該過程中，Substrate VM 會將靜態(tài)編譯階段確定和初始化的內(nèi)容以及跟 Substrate VM 運(yùn)行時(shí)以及 JDK 庫中的數(shù)據(jù)一起保存到最終可執(zhí)行文件的 Image Heap 中。其中 Substrate VM 運(yùn)行時(shí)就為最終可執(zhí)行文件提供了運(yùn)行過程中所需的垃圾回收、異常處理等能力。對于垃圾回收這塊，在一開始的 GraalVM 社區(qū)版中僅提供了 Serial GC。企業(yè)版中提供了能力更強(qiáng)的 G1 GC。不過在最新的社區(qū)版中 GraalVM 團(tuán)隊(duì)也引入了 G1 GC[5]以便為廣大開發(fā)者提供更強(qiáng)大的靜態(tài)編譯使用能力。
上節(jié)，簡單介紹了靜態(tài)編譯技術(shù)以及其本身的局限性以后，很多外部社區(qū)開發(fā)者這時(shí)可能會疑問，一個(gè) Java 開源項(xiàng)目如何快速進(jìn)行靜態(tài)編譯適配？對于這個(gè)問題，其實(shí)最核心要解決的本質(zhì)問題就是將開源框架中的 GraalVM 無法識別和處理的動態(tài)內(nèi)容轉(zhuǎn)換為其可識別的內(nèi)容即可。因此該問題由于不同框架情況不一樣，因此解決方式也會有一些差異。例如在 Spring 中，針對其自身框架開發(fā)的 AOT Engine 可以解決其框架提供的通過 @Configuration 注解注冊類初始化過程無法在靜態(tài)編譯階段被識別、提前在靜態(tài)編譯期生成原本在運(yùn)行階段才能生成的動態(tài)代理類解決直接靜態(tài)編譯代理類無法被有效生成等問題[6]從而實(shí)現(xiàn) Spring 應(yīng)用的靜態(tài)編譯適配。
對于很多基于 Spring 實(shí)現(xiàn)的開源框架，如果本身無法被 GraalVM 識別的動態(tài)特性都是由于 Spring 標(biāo)準(zhǔn)的那一套用法所導(dǎo)致，由于自身屬于 Spring 體系，靜態(tài)編譯過程就肯定少不了 Spring AOT Engine 的參與，因此，框架自身就不需要再提供任何適配就可以具備靜態(tài)編譯能力。
對于非 Spring 體系項(xiàng)目或者自身使用了一些 JDK 中原生的反射或者其他 Java 動態(tài)特性，針對自身代碼中的 Java 動態(tài)用法需要在項(xiàng)目中提供對應(yīng)的靜態(tài)配置文件才能在靜態(tài)編譯過程中讓編譯器識別其中的動態(tài)特性，對其進(jìn)行編譯構(gòu)建才能實(shí)現(xiàn)項(xiàng)目的順利編譯與執(zhí)行。針對這種情況，GraalVM 提供了一個(gè)名叫 native-image-agent 的 Tracing Agent 來幫助大家更方便地收集元數(shù)據(jù)并準(zhǔn)備配置文件。該 Agent 會在常規(guī) Java VM 上的應(yīng)用程序運(yùn)行過程中自動收集其中的動態(tài)特性使用情況并將其轉(zhuǎn)換為 GraalVM 可以識別的配置文件。最后，將通過 Agent 生成的框架自身的動態(tài)配置文件存放在項(xiàng)目的：META-INF/native-image/<group.id>/<artifact.id> 目錄下，就可以在靜態(tài)編譯過程中根據(jù)這些配置內(nèi)容，識別項(xiàng)目包中的動態(tài)特性。
Spring Cloud Alibaba 2022.0.0.0 版本所包含的所有中間件客戶端目前已完成了構(gòu)建 GraalVM 原生應(yīng)用的適配。由于項(xiàng)目自身的特定，項(xiàng)目整體實(shí)現(xiàn)中有大量的 Spring 語法導(dǎo)致的無法被 GraalVM 識別的動態(tài)特性用法，這塊內(nèi)容直接交由 Spring AOT Engine 來進(jìn)行解決，社區(qū)未做額外適配工作。
除了 Spring 體系語法，項(xiàng)目本身還是有一些其他 Java 動態(tài)用法的，這塊社區(qū)通過 native-image-agent 來進(jìn)行解析與動態(tài)配置生成。
Spring Cloud Alibaba 2022.0.0.0 版本所包含的所有中間件客戶端已完成了構(gòu)建 GraalVM 原生應(yīng)用的適配。為用戶提供了開箱即用的靜態(tài)編譯能力。相關(guān)功能體驗(yàn)過程如下：
首先需要在首先在機(jī)器上安裝 GraalVM 發(fā)行版。您可以在 Liberica Native Image Kit 頁面上手動下載它，也可以使用像 SDKMAN! 這樣的下載管理器。本文演示環(huán)境為 MacOS，如果是 Windows 可參考相應(yīng)文檔[7]進(jìn)行操作。執(zhí)行以下命令安裝 GraalVM 環(huán)境：
$ sdk install java 22.3.r17-nik$ sdk use java 22.3.r17-nik通過檢查 java -version 的輸出來驗(yàn)證是否配置了正確的版本：
$ java -versionopenjdk version "17.0.5" 2022-10-18 LTSOpenJDK Runtime Environment GraalVM 22.3.0 (build 17.0.5+8-LTS)OpenJDK 64-Bit Server VM GraalVM 22.3.0 (build 17.0.5+8-LTS, mixed mode)要使用 GraalVM 靜態(tài)編譯能力構(gòu)建微服務(wù)，首先確保您項(xiàng)目的 Spring Boot 版本為 3.0.0 或以上，Spring Cloud 版本為 2022.0.0 或以上。然后在項(xiàng)目中引入 Spring Cloud Alibaba 2022.0.0.0 版本的所需模塊依賴即可。
通過以下命令生成應(yīng)用中反射、序列化和動態(tài)代理所需的 Hints 配置文件，前提是應(yīng)用中引入了 spring-boot-starter-parent 父模塊：
$ mvn -Pnative spring-boot:run之后應(yīng)用會啟動，進(jìn)行預(yù)執(zhí)行，需要盡可能完整的測試一遍應(yīng)用的所有功能，保證應(yīng)用的大部分代碼都被測試用例覆蓋，該過程會基于 GraalVM 的 native-image-agent 收集程序中的動態(tài)特性，這樣可以確保完整生成應(yīng)用運(yùn)行過程中的所有必須的動態(tài)屬性。運(yùn)行完所有測試用例后，我們發(fā)現(xiàn) resource/META-INF/native-image 目錄下會生成以下一些 hints 文件:
注意事項(xiàng)：Spring Cloud Alibaba 2022.0.0.0 正式版本所有核心模塊都已經(jīng)默認(rèn)將自身組件相關(guān)動態(tài)特性所需的配置內(nèi)容都包含在了依賴中，因此上述預(yù)執(zhí)行過程主要為了掃描應(yīng)用自身業(yè)務(wù)代碼以及其他第三方包中的動態(tài)特性，以便后續(xù)靜態(tài)編譯過程能順利進(jìn)行，應(yīng)用能正常啟動。
以上步驟一切準(zhǔn)備就緒后，通過以下命令來構(gòu)建原生鏡像：
$ mvn -Pnative native:compile成功執(zhí)行后，我們在 /target 目錄可以看到生成的可執(zhí)行文件。
與普通可執(zhí)行文件無異，通過 target/xxx 啟動應(yīng)用, 可以觀察到類似如下的輸出:
2023-08-01T17:21:21.006+08:00 INFO 65431 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''2023-08-01T17:21:21.008+08:00 INFO 65431 --- [ main] c.a.cloud.imports.examples.Application : Started Application in 0.553 seconds (process running for 0.562)采用 GraalVM 靜態(tài)編譯技術(shù)的新版本 Spring Cloud Alibaba 應(yīng)用，所有核心能力在啟動速度和內(nèi)存占用率方面如下表所示都有顯著改善。
圖片
說明：上述測試代碼樣例來自 Spring Cloud Alibaba 項(xiàng)目中的 examples 模塊，4c16g Mac 環(huán)境，每組數(shù)據(jù)測試 3 次取平均，具體數(shù)據(jù)因機(jī)器不同可能會有差異。
相關(guān)鏈接：
[1] Java 程序的啟動過程分析
https://shipilev/talks/j1-Oct2011-21682-benchmarking.pdf
[2] GraalVM 開源高性能多語言運(yùn)行時(shí)平臺
https://www.oracle.com/java/graalvm/
[3] 外部配置
https://www.graalvm.org/latest/reference-manual/native-image/metadata/
[4] AOT Engine
https://spring.io/blog/2021/12/09/new-aot-engine-brings-spring-native-to-the-next-level
[5] G1 GC
https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5
[6] 動態(tài)代理類等問題
https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html#native-image.introducing-graalvm-native-images.understanding-aot-processing
[7] 相應(yīng)文檔
https://medium.com/graalvm/using-graalvm-and-native-image-on-windows-10-9954dc071311
本文鏈接：http://m.rrqrq.com/showinfo-26-6164-0.html基于靜態(tài)編譯構(gòu)建微服務(wù)應(yīng)用
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 如何編寫技術(shù)文檔？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號