checkpoint

Java虛擬機為已編譯為字節碼 （但不一定是用Java編寫）的應用程序提供了托管運行時環境。 與為特定平臺靜態編譯的代碼相比，這為應用程序開發人員提供了許多好處，并且通常可以提高性能。 JVM通過垃圾回收器 （GC）自動處理內存分配和恢復，從而減少了內存泄漏的可能性。 即時（JIT）編譯提供了“一次編寫，隨處運行”的功能，無需為支持的每個平臺構建單獨的應用程序二進制版本。

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

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

Azul的OpenJDK的Zulu構建現在包括一組類似的技術，我們稱之為Main（CRaM）的Checkpoint / Restore。

CRaM的想法是通過執行訓練運行來減少應用程序的預熱時間，然后可以在生產運行中使用它 。 可以通過三種不同的方式執行訓練運行：

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

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

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

檢查點是創建應用程序狀態時的復雜快照。 它包含以下信息：

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

對于可以在生產運行中使用檢查點的地方，存在嚴格的限制。 檢查點與用于訓練運行的平臺緊密相關，并且包括非常低級的信息，例如來自映射系統庫（如libc）的內存頁。 如果在執行生產運行之前對系統庫，JDK或應用程序代碼進行了更改，則檢查點將不起作用。 檢查點僅應在運行相同硬件和軟件堆棧的計算機之間共享。

要將檢查點用于生產運行，應使用如下命令行：

java -Zrestore myAppClass <application arguments>

先前存儲的檢查點數據將用于最大程度地減少與應用程序關聯的預熱時間。 有兩點需要注意：

• 在生產運行期間，可以將代碼重新編譯為JIT編譯過程的正常部分。 與培訓期間不同，將啟用JIT可用的所有優化。
• 需要從生成訓練運行的目錄中啟動該應用程序。 這是檢查點狀態的一部分。
• 不應使用JVM命令行標志。 訓練運行與創建期間使用的命令行標志相關聯，然后在生產運行期間自動設置這些標志。 更改它們可能會使檢查點中的信息無效。

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

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

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

例如，考慮一個簡單的Spring Boot應用程序。

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

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

如您所見，CRaM可以極大地改變需要準備好盡快執行任務的應用程序的效率。 這在嵌入式應用程序中尤其重要，在嵌入式應用程序中，資源受到限制，并且與傳統服務器相比，設備可能需要更頻繁地重新啟動。

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

聯系AZUL了解更多信息

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

checkpoint

總結

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

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