最近的Java生產性能問題迫使我重新審視并真正欣賞Java VM即時（JIT）編譯器。 大多數Java開發人員和支持人員都聽說過這種JVM運行時性能優化，但是有多少人真正理解并欣賞它的好處？

本文將與您分享在添加新的虛擬服務器（容量改進和水平擴展項目）之后我所涉及的故障排除練習。

有關JIT的更深入介紹，我推薦以下文章：

• ##即時編譯： http ： //en.wikipedia.org/wiki/Just-in-time_compilation
• ## Java HotSpot性能引擎體系結構： http : //www.oracle.com/technetwork/java/whitepaper-135217.html
• ##了解即時編譯和優化： http : //docs.oracle.com/cd/E15289_01/doc.40/e15058/underst_jit.htm
• ## JIT編譯器如何優化代碼： http : //pic.dhe.ibm.com/infocenter/java7sdk/v7r0/index.jsp?topic=%2Fcom.ibm.java.zos.70.doc%2Fdiag%2Funderstanding% 2Fjit_overview.html

JIT編譯概述

JIT編譯本質上是一個在運行時提高Java應用程序性能的過程。

下圖說明了不同的JVM層和交互。 它描述了以下高級過程：

Java編譯器將Java源文件編譯為平臺無關的字節碼或Java類文件。

在觸發Java應用程序之后，JVM在運行時加載編譯的類，并通過Java解釋器執行適當的計算語義。

啟用JIT后，JVM將分析Java應用程序方法調用并將字節碼（在達到某些內部閾值之后）編譯為本機的，更有效的機器代碼。 通常，最繁忙的方法調用首先確定JIT進程的優先級。

將此類方法調用編譯為機器代碼后，JVM將直接執行它，而不是“解釋”它。

隨著時間的流逝，上述過程導致了運行時性能的提高。

案例分析

現在這里是我之前提到的項目的背景。 主要目標是在生產環境中添加新的IBM P7 AIX虛擬服務器（LPAR），以提高平臺的容量。 查找以下平臺本身的規格：

• Java EE服務器 ： IBM WAS 6.1.0.37和IBM WCC 7.0.1
• 操作系統 ：AIX 6.1
• JDK ：IBM J2RE 1.5.0（SR12 FP3 + IZ94331）@ 64位
• RDBMS ：Oracle 10g
• 平臺類型 ：中間層和批處理

為了達到現有的應用程序性能水平，購買了完全相同的硬件規格。 還使用與現有產品相同的版本安裝了AIX OS版本和其他IBM軟件。

為了確保應用程序具有相同的性能水平，對以下各項（清單）均進行了驗證：

• 硬件規格（＃CPU內核，物理RAM，SAN…）。
• 操作系統版本和補丁程序級別； 包括AIX內核參數。
• IBM WAS和IBM WCC版本，補丁程序級別； 包括調整參數。
• IBM JRE版本，補丁程序級別和調整參數（啟動參數， Java堆大小 ……）。
• 還正確評估了網絡連接性和性能。

新的生產服務器構建完成后，將執行功能測試，該測試還確認了聯機和批處理應用程序的正確行為。

但是，在生產運營的第一天就發現了主要的性能問題。 您將在下面找到所觀察到的性能問題的摘要矩陣。

生產服務器	運行時間	處理量（＃個訂單）	中央處理器 ％ （平均）	中間件健康
現有服務器	10個小時	25萬（基線）	20％	健康
*新*服務器	10個小時	5萬-500％	80％+ 400％	高線程利用率

從上面的視圖中可以看到，性能結果在生產的第一天就非常糟糕。 與現有生產服務器相比，新生產服務器不僅處理了更少的訂單，而且物理資源利用率（例如CPU％）也要高得多。

考慮到確保新服務器的構建與現有服務器完全相同所花費的時間，這種情況令人感到困惑。 那時，另一個核心團隊參與進來，以執行額外的故障排除并確定性能問題的根源。

故障排除：尋找罪魁禍首…

故障排除團隊分為兩部分，以專注于以下項目：

• 從IBM WAS容器中識別CPU％的來源，并將CPU占用空間與現有生產服務器進行比較。
• 在現有生產服務器和新生產服務器之間執行更多數據和文件比較。

為了了解CPU％的來源，我們確實從運行IBM WAS和IBM WCC的IBM JVM中對每個線程執行了AIX CPU分析 。 從下面的屏幕快照中可以看到，發現許多線程各自使用5-20％。 在現有生產服務器上執行的相同分析確實顯示出更少的線程數，CPU占用率始終在5％左右。

結論：

相同類型的業務流程使用的CPU是現有生產服務器的3-4倍。

為了了解執行的處理類型，每個線程數據在CPU的同時捕獲了JVM線程轉儲 。 現在，在查看了JVM線程轉儲（Java內核）之后，我們意識到的第一件事就是JIT確實被禁用了！ 通過從正在運行的JVM進程中運行java –version命令也可以確認該問題。

這個發現非常重要，特別是考慮到在現有生產服務器上啟用了JIT。 大約在同一時間，負責比較服務器的另一個團隊最終發現了用于啟動應用程序的AIX用戶的環境變量之間的差異。 早期的差距分析漏掉了這種比較練習。 他們發現新的AIX生產服務器具有以下額外條目：

JAVA_COMPILER=NONE

根據IBM文檔 ，添加此類環境變量是禁用 JIT的方法之一。

復雜的根本原因分析，簡單的解決方案

為了了解在我們的環境中禁用JIT的影響，您必須了解其含義。 禁用JIT本質上意味著整個JVM現在都在解釋模式下運行。 對于我們的應用程序，以完全解釋模式運行不僅會大大降低應用程序吞吐量，而且還會增加服務器CPU利用率的壓力點，因為每個請求/線程占用的CPU數量是使用JIT執行的請求的3-4倍（請記住，當使用JIT時啟用后，JVM將直接對機器/本機代碼執行許多調用）。

如預期的那樣，除去此環境變量以及重新啟動受影響的JVM進程確實解決了問題并恢復了性能級別。

評估您的應用程序的JIT收益

我希望您對這個案例研究和對JVM JIT編譯過程的簡短回顧表示贊賞。 為了了解不對Java應用程序使用JIT的影響，建議您進行以下實驗：

• 啟用JIT并為您的應用程序生成負載，并捕獲一些基準數據，例如CPU％，響應時間，＃個請求等。
• 禁用JIT。
• 重做相同的測試并比較結果。

參考： Java即時編譯：在Java EE支持模式博客上， 不僅僅是 JCG合作伙伴 Pierre Hugues Charbonneau 的時髦 詞匯 。

翻譯自: https://www.javacodegeeks.com/2013/07/java-just-in-time-compilation-more-than-just-a-buzzword.html

總結

以上是生活随笔為你收集整理的Java即时编译：不仅仅是一个流行词的全部內容，希望文章能夠幫你解決所遇到的問題。

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