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

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

有關(guān)JIT的更深入介紹，我推薦以下文章：

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

JIT編譯概述

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

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

Java編譯器將Java源文件編譯為平臺無關(guān)的字節(jié)碼或Java類文件。

在觸發(fā)Java應用程序之后，JVM在運行時加載編譯的類，并通過Java解釋器執(zhí)行適當?shù)挠嬎阏Z義。

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

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

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

案例分析

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

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

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

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

• 硬件規(guī)格（＃CPU內(nèi)核，物理RAM，SAN…）。
• 操作系統(tǒng)版本和補丁程序級別； 包括AIX內(nèi)核參數(shù)。
• IBM WAS和IBM WCC版本，補丁程序級別； 包括調(diào)整參數(shù)。
• IBM JRE版本，補丁程序級別和調(diào)整參數(shù)（啟動參數(shù)， Java堆大小 ……）。
• 還正確評估了網(wǎng)絡(luò)連接性和性能。

新的生產(chǎn)服務(wù)器構(gòu)建完成后，將執(zhí)行功能測試，該測試還確認了聯(lián)機和批處理應用程序的正確行為。

但是，在生產(chǎn)運營的第一天就發(fā)現(xiàn)了主要的性能問題。 您將在下面找到所觀察到的性能問題的摘要矩陣。

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

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

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

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

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

• 從IBM WAS容器中識別CPU％的來源，并將CPU占用空間與現(xiàn)有生產(chǎn)服務(wù)器進行比較。
• 在現(xiàn)有生產(chǎn)服務(wù)器和新生產(chǎn)服務(wù)器之間執(zhí)行更多數(shù)據(jù)和文件比較。

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

結(jié)論：

相同類型的業(yè)務(wù)流程使用的CPU是現(xiàn)有生產(chǎn)服務(wù)器的3-4倍。

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

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

JAVA_COMPILER=NONE

根據(jù)IBM文檔 ，添加此類環(huán)境變量是禁用 JIT的方法之一。

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

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

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

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

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

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

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

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

總結(jié)

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

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