Java虛擬機為已編譯為字節(jié)碼 （但不一定是用Java編寫）的應(yīng)用程序提供了托管運行時環(huán)境。 與為特定平臺靜態(tài)編譯的代碼相比，這為應(yīng)用程序開發(fā)人員提供了許多好處，并且通常可以提高性能。 JVM通過垃圾回收器 （GC）自動處理內(nèi)存分配和恢復(fù)，從而減少了內(nèi)存泄漏的可能性。 即時（JIT）編譯提供了“一次編寫，可在任何地方運行”的功能，無需為支持的每個平臺構(gòu)建單獨的應(yīng)用程序二進(jìn)制版本。

但是，這些優(yōu)勢并非完全沒有成本。 盡管在JVM上運行的應(yīng)用程序的整體速度最終可能會更快，但是由于編譯和優(yōu)化了常用方法，因此需要一定的預(yù)熱時間。 每次啟動應(yīng)用程序時，都必須執(zhí)行相同的性能分析，分析和編譯，即使該應(yīng)用程序使用相同。

多年來，Azul Systems一直在研究使JVM這些方面的性能影響最小化的方法。 Zing JVM使用Falcon JIT編譯器代替了舊的C2 JIT和ReadyNow！ 記錄可在重新啟動應(yīng)用程序時使用的配置文件的技術(shù)。

Azul的OpenJDK的Zulu構(gòu)建現(xiàn)在包括一組類似的技術(shù)，我們稱之為Main（CRaM）的Checkpoint / Restore。

CRaM的想法是通過執(zhí)行訓(xùn)練運行來減少應(yīng)用程序的預(yù)熱時間，然后可以在生產(chǎn)運行期間使用它。 可以通過三種不同的方式執(zhí)行訓(xùn)練運行：

正常使用該應(yīng)用程序，并執(zhí)行所需的任何功能。 該應(yīng)用程序通過退出main（）方法終止。 此時，將記錄來自應(yīng)用程序運行的所有數(shù)據(jù)。 無需更改應(yīng)用程序代碼； 僅需添加-Zcheckpoint JVM標(biāo)志。

根據(jù)上面的方案1，使用該應(yīng)用程序，但通過調(diào)用System.exit（）終止該應(yīng)用程序。 同樣，無需更改應(yīng)用程序代碼，但是在這種情況下，必須使用JVM標(biāo)志-Dcom.azul.System.exit.doCheckpointRestore = true。

在這種情況下，開發(fā)人員在應(yīng)用程序代碼中選擇一個特定點，他們希望在此生成檢查點。 必須更改應(yīng)用程序代碼； 在需要的地方放置了對方法Dcom.azul.System.tryCheckpointRestore（）的調(diào)用。 這對于不終止的應(yīng)用程序很有用。 除非為JVM指定了-Zcheckpoint標(biāo)志，否則該調(diào)用將被忽略。 附加標(biāo)志-XX：CRTrainingCount可用于使應(yīng)用程序在記錄檢查點之前處理多個事務(wù)。

檢查點是創(chuàng)建應(yīng)用程序狀態(tài)時的復(fù)雜快照。 它包含以下信息：

• JVM的Java類的內(nèi)部表示。 每次應(yīng)用程序啟動時，它都需要讀取所需的類，并使用初始化的數(shù)據(jù)為每個類創(chuàng)建自己的表示形式。
• JVM JIT編譯器C1和C2生成的代碼。 由于該代碼的重用方式，有必要關(guān)閉某些優(yōu)化以使該代碼在生產(chǎn)運行中得以重用。
• 初始化的系統(tǒng)類。 這些是核心類庫中的類，并且獨立于任何應(yīng)用程序代碼。
• 堆中與應(yīng)用程序啟動相關(guān)的某些Java對象。

對于可以在生產(chǎn)運行中使用檢查點的地方，存在嚴(yán)格的限制。 檢查點與用于訓(xùn)練運行的平臺緊密相關(guān)，并且包括非常低級的信息，例如來自映射系統(tǒng)庫（如libc）的內(nèi)存頁。 如果在執(zhí)行生產(chǎn)運行之前對系統(tǒng)庫，JDK或應(yīng)用程序代碼進(jìn)行了更改，則檢查點將不起作用。 檢查點只能在運行相同硬件和軟件堆棧的計算機之間共享。

要將檢查點用于生產(chǎn)運行，應(yīng)使用如下命令行：

java -Zrestore myAppClass <application arguments>

先前存儲的檢查點數(shù)據(jù)將用于最大程度地減少與應(yīng)用程序關(guān)聯(lián)的預(yù)熱時間。 有兩點需要注意：

• 在生產(chǎn)運行期間，可以將代碼重新編譯為JIT編譯過程的正常部分。 與培訓(xùn)期間不同，將啟用JIT可用的所有優(yōu)化。
• 需要從生成訓(xùn)練運行的目錄中啟動該應(yīng)用程序。 這是檢查點狀態(tài)的一部分。
• 不應(yīng)使用JVM命令行標(biāo)志。 訓(xùn)練運行與創(chuàng)建期間使用的命令行標(biāo)志相關(guān)聯(lián)，然后在生產(chǎn)運行期間自動設(shè)置這些標(biāo)志。 更改它們可能會使檢查點中的信息無效。

當(dāng)前，CRaM功能面向嵌入式應(yīng)用程序，在這些應(yīng)用程序中，啟動時以最佳速度運行的能力至關(guān)重要。 因此，CRaM支持的平臺僅是Arm 32位處理器，運行Linux的內(nèi)核為3.5或更高版本以及glibc 2.13或更高版本。 CRaM包含一個實用程序cr-compat-checker，可用于驗證設(shè)備是否滿足這些要求。

為了確定CRaM是否適合某個應(yīng)用程序，了解它如何更改應(yīng)用程序的性能概況至關(guān)重要。 CRaM旨在減少到達(dá)生成檢查點的時間。 從那時起，無論是否使用檢查點，執(zhí)行都將保持不變。 查看Java應(yīng)用程序的性能時，它可以分為兩部分：JVM啟動時間，即到達(dá)main（）入口點的時間； 和時間從main（）運行。 使用CRaM時，到達(dá)main（）所需的時間會更長，但是到達(dá)創(chuàng)建檢查點的位置所需的時間會更少。

為了使這一點更易于理解，圖表非常有用：

例如，考慮一個簡單的Spring Boot應(yīng)用程序。

在不使用CRaM的情況下，到main（）的時間為2秒，從進(jìn)入main（）到完全初始化的應(yīng)用程序（準(zhǔn)備處理交易）的時間為31秒。 因此，處理交易之前需要的時間為33秒。

完成檢查點后，使用CRaM啟動應(yīng)用程序，到main（）的時間增加到3秒。 但是，從輸入main（）到完全初始化的時間僅為18秒。 這樣可以將處理事務(wù)之前所需的時間減少到僅21秒，這實際上要快得多。

如您所見，CRaM可以在需要準(zhǔn)備好盡快執(zhí)行任務(wù)的應(yīng)用程序的有效性方面產(chǎn)生重大影響。 這在嵌入式應(yīng)用程序中尤其重要，在嵌入式應(yīng)用程序中，資源受到限制，并且與傳統(tǒng)服務(wù)器相比，設(shè)備可能需要更頻繁地重新啟動。

Azul目前正在進(jìn)行CRaM的Beta版測試。 如果您有興趣參與其中，請與我們聯(lián)系以獲取更多信息。

聯(lián)系A(chǔ)ZUL了解更多信息

翻譯自: https://www.javacodegeeks.com/2019/08/faster-java-startup-checkpoint-restore-main.html

總結(jié)

以上是生活随笔為你收集整理的通过Main的Checkpoint Restore加快Java启动速度的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。