大家好！ 這是 Quarkus 系列文章的第二篇文章 - 今天我們將討論本機編譯。
是一個專門為 。 雖然這裡肯定還有很多工作要做，但我們在很多方面都做了很多出色的工作，包括優化 JVM 和許多框架。 Quarkus 吸引了開發人員越來越多興趣的功能之一是其全面、無縫的方法，可以將Java 程式碼轉換為特定作業系統的可執行檔（所謂的「本機編譯」），類似於C 和C++，其中這種編譯通常發生在建置、測試和部署週期結束時。
雖然本機編譯很重要（正如我們將在下面展示的那樣），但應該注意的是，Quarkus 在最常見的Java 機器OpenJDK Hotspot 上運行得非常好，這要歸功於我們在整個堆疊中實現的性能改進。 因此，本機編譯應該被視為一個額外的好處，可以根據需要或需要使用。 事實上，Quarkus 在本機鏡像方面嚴重依賴 OpenJDK。 而受到開發人員熱烈歡迎的開發模式，由於 Hotspot 中實現的動態程式碼執行的高級功能，確保了幾乎即時的更改測試。 此外，在建立原生GraalVM映像時，會使用OpenJDK類別庫和HotSpot功能。
那麼，如果一切都已經完美優化，為什麼還需要本機編譯呢？ 下面我們將嘗試回答這個問題。
讓我們從顯而易見的事情開始：紅帽在專案開發過程中優化 JVM、堆疊和框架方面擁有豐富的經驗 ， 包括：
- 第一個在平台上雲端工作的應用程式伺服器 .
- 第一個在電腦上運行的應用程式伺服器 .
- 第一個運行的應用程式伺服器 .
- 一系列在設備上運行的項目 .
多年來，我們一直在應對在雲端和資源受限設備（即物聯網）上運行 Java 應用程式的挑戰，並學會了在效能和記憶體優化方面充分利用 JVM。 與許多其他人一樣，我們長期以來一直致力於 Java 應用程式的本機編譯 , , идаже 我們很清楚這種方法的優點和缺點（例如，在「建置一次 - 隨處運行」的普遍性與編譯後的應用程式更小且運行速度更快之間進行選擇的困境）。
為什麼考慮這些利弊很重要？ 因為在某些情況下它們的比例變得決定性：
- 例如，在無伺服器/事件驅動的環境中 （硬或軟）即時，以便有時間回應事件。 與長期持久服務不同，冷啟動的持續時間會顯著增加請求的回應時間。 JVM 仍然需要大量的時間來啟動，雖然在某些情況下可以透過純硬體方法來減少這一時間，但 5 秒和 XNUMX 毫秒之間的差異可能是生與死的差異。 是的，在這裡您可以嘗試建立 Java 機器的熱儲備（例如，我們使用 ），但這本身並不能保證在負載擴展時有足夠的 JVM 來處理請求。 從經濟角度來看，這可能不是最正確的選擇。
- 此外，還有另一個經常出現的方面：多租戶。 儘管 JVM 的功能已經非常接近作業系統，但它們仍然無法完成我們在 Linux 中習慣的操作——隔離進程。 因此，一個執行緒的失敗可能會導致整個Java機器癱瘓。 許多人試圖透過為每個使用者的應用程式專用一個單獨的 JVM 來解決這個缺點，以最大程度地減少故障的後果。 這是非常合乎邏輯的，但不太適合縮放。
- 另外，對於面向雲端的應用，一個重要指標是主機上的服務密度。 過渡到方法論 、微服務和 Kubernetes 增加了每個應用程式的 Java 機器數量。 也就是說，一方面，所有這些都提供了彈性和可靠性，但同時服務方面的基礎記憶體消耗也增加了，其中一些費用並不總是嚴格必要的。 當最終映像僅包含服務實際使用的框架部分（包括 JDK 本身）時，靜態編譯的可執行檔在這裡受益於各種最佳化技術，例如低階死碼消除。 因此，Quarkus 原生編譯有助於在不影響安全性的情況下將服務實例密集地放置在主機上。
其實，從 Quarkus 計畫參與者的角度來看，上述論點已經足以理解原生編譯的合理性了。 然而，還有另一個非技術性但也是重要的原因：近年來，許多程式設計師和開發公司已經放棄了Java，轉而採用新的程式語言，他們認為Java 及其JVM、堆疊和框架已經變得過於強大。記憶體消耗大、速度太慢等等。
然而，使用同一個工具解決任何問題的習慣是 。 有時最好退後一步，尋找其他東西。 如果 Quarkus 能讓人們停下來思考，那麼這對整個 Java 生態系統都有好處。 Quarkus 代表如何建立更有效率的應用程式的創新觀點，使 Java 與無伺服器等新應用程式架構更加相關。 此外，由於其可擴展性，Quarkus 將有望擁有一個完整的 Java 擴展生態系統，從而顯著增加支援開箱即用的應用程式中的本機編譯的框架數量。
來源： www.habr.com