Java性能調優工具BEA JRockit Mission Control

前言

從所周知，Java虛擬機(JVM)及垃圾收集器(GC)負責管理大多數的內存任務，可是Java應用系統中仍是有可能出現內存泄漏。事實上，OOM之類的現象在大型項目中也是一個常見的問題。避免內存泄漏的第一步是要弄清楚它是如何發生的，而後對症下藥。

那到底是什麼致使了 Java 程序中的內存泄漏呢？難道 Java 虛擬機的垃圾收集器不該該管理未使用的內存嗎？是的，它會進行管理，可是垃圾收集的對象只能是再也不被引用的對象。可是，某些再也不須要的對象，卻在系統的某個地方仍在引用它，這樣就不能對這些對象進行垃圾收集，在日誌中的大量String對象的生成以及編寫Java代碼時的一些常見的內存泄漏陷阱等等都會形成內存泄漏，可是要在開發階段完成找出形成泄漏的代碼是很是困難的。

在大型企業系統中，Java代碼中的內存泄漏是常見並且難於解決的問題。這些泄漏問題一般是在最不肯意它發生的正式生產環境中發現的，並且它也很難於在開發與測試環境中獲得重現。這是爲何呢？生產環境中的系統須要處理更大量的數據，並且有可能在運行很長時間後纔會發現 Java堆在緩慢地增加。最終，致使系統內存耗盡。

所以本文介紹一種新工具BEA JRockit Mission Control，用來診斷泄漏並指出根本緣由。該工具的開銷很是小，所以可使用它來尋找生產環境中的系統的內存泄漏。

簡介

BEA JRockit Mission Control（如下簡稱爲JRMC）於2005年12月面世，並從JRockit R26.0.0版本開始捆綁了這個工具套件，目前最新的版本是2.0.1。它是一組以極低的開銷來監控、管理和分析生產環境中的應用程序的工具。它包括三個獨立的應用程序：內存泄漏監測器（Memory Leak Detector）、JVM運行時分析器（Runtime Analyzer）和管理控制檯（Management Console）。

下面的架構圖描述了BEA JRockit Mission Control 2.0工具套件之間的關係。

JRockit Management Console

JRockit Management Console是一個基於JMX的控制檯，用於監控和管理多個JRockit實例，提供相當重要的狀態數據和控制JRockit JVM的運行時特性的方法。它捕獲並顯示關於垃圾收集器（GC）暫停、內存、堆使用和CPU負載的實時數據，以及部署在JVM內部MBean服務器上註冊的全部JMX MBean所公開的信息。JVM管理包括對CPU類似性、垃圾收集策略和內存池大小的動態控制，還包括一個開銷低的方法分析器和一個異常計數器。

以下圖所示，能夠用多個JRockit Management Console實例鏈接到一個JRockit JVM上，並且一個Management Console也能夠鏈接到多個JRockit JVM。Management Console能夠運行在不一樣的機器上。實際上，控制檯是能夠鏈接處理多個JRockit JVM的，一般不須要在同一臺機器上運行多個Management Console，而是在不一樣的監控機器上面運行多個實例進行JRockit JVM。

JRockit Runtime Analyzer

JRockit Runtime Analyzer（JRA）是一個JVM分析器，是一個隨需應變的「動態記錄器」Java應用程序，它記錄了Java應用程序和JVM在一段預約的時間內的詳細記錄。而後經過JRA應用程序對記錄下來的文件進行離線分析。所記錄的數據包括對方法的調用跟蹤、錯誤的同步、鎖定的分析，還有垃圾收集統計信息，優化決策以及對象統計信息和其餘重要的應用程序/JVM行爲。它的目的是讓JRockit開發人員可以找到良好的方法來基於現實應用程序優化JVM，對於幫助客戶在生產和開發環境中解決問題十分有用。

JRA由兩個部分組成：JVM中的記錄引擎和能夠用於分析結果記錄的GUI應用程序。記錄引擎使用的信息源有幾種，包括JRockit Hot Spot Detector（優化引擎也使用它來決定應該優化哪些方法）、操做系統、JRockit Memory System（最出名的就是垃圾收集器）和JRockit鎖定分析器（若是支持的話）。

JRockit Memory Leak Detector

雖然Java的自動內存管理機制把開發人員從顯式地分配和釋放所使用內存的重擔下解放出來，但若是程序繼續引用再也不有用的對象時，內存泄漏仍是有可能發生。JRockit Memory Leak Detector工具用來發現和查找內存泄漏緣由。趨勢分析器爲用戶提供了一個趨勢分析，能夠發現很是緩慢的泄漏，顯示詳細的堆統計信息（包括指向泄漏對象和分配位置的引用類型和實例），能夠說明應用程序中每一個類使用堆空間的狀況，顯示某一類型的實例使用了多少空間、它們佔用了堆的哪一部分、存在多少個實例以及每秒鐘堆空間使用的增長速度（以字節爲單位），並快速找出泄漏緣由。使用先進的圖形化表現技術，以便更容易定位和理解有時比較複雜的信息。

JRockit Memory Leak Detector還提供快速找出泄漏緣由的手段。能夠在趨勢分析表中選擇一個懷疑類型，全部具備指向選中類型的實例的類型均可以顯示在一個圖中。圖形節點能夠隨意展開，用戶能夠回溯到致使引用的最終緣由。類的實例能夠被顯示，指向一個選中實例的全部實例均可以在一張實例圖中顯示出來。能夠跟蹤某個類的全部分配狀況。

下載安裝

JRockit Mission Control 2.0（內部稱爲Energy）是做爲一組Eclipse插件而開發的，這個能夠經過下載安裝後，運行它以後所見到的程序風格以及幫助裏的信息得知，固然從安裝後的目錄結構裏咱們也能夠看到。Energy改進了用戶界面，並利用了新的JRockit和6.0特有的管理特性，能夠將JRockit Mission Control 2.0與JDK 1.四、5.0和6.0版本的JRockit（版本號大於R27，目前這些JDK的版本號都到了R27.2.0）鏈接起來，所以能夠無縫地進行鏈接。JDK及JRockit Mission Control能夠從http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp 去選擇相應的所需版本進行安裝使用。各個版本的JDK裏所附帶的JRockit Mission Control都是相同的版本2.0.1，本文以它來鏈接JRockit 5.0的JDK爲示例進行說明。

申請許可

雖然JRockit Mission Control 2.0已經包含在BEA JRockit R27.1以上版本的JDK裏面了，即安裝後就有了。可是，爲了使用它，你還須要下載一個適合與你的許可。BEA提供兩種類型許可：免費的有限制的開發者許可和收費的無限制的企業許可。許可下載地址爲 http://dev2dev.bea.com/jrockit/tools.html

許可的安裝，默認的JRockit JDK安裝後帶有一個空的JRMC許可license.bea，將下載到的許可文件拷貝到 %JROCKIT_HOME%/jre/ 目錄下覆蓋掉原來的文件，注意這個許可的文件名稱必須是license.bea，這樣許可的全路徑就是 %JROCKIT_HOME%/jre/license.bea 了。可是，若是你已經有了JRMC以外的其它許可，你須要打開下載到的話可文件，將裏面的component="JRA"和component="Memory Leak Detector"的<license>拷貝到已有的許可文件裏並保存便可。

WebLogic使用

修改commEnv.cmd爲-Xmanagement -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
 

運行rmi的機器若是有多個IP就會有這個問題。也能夠經過設置java.rmi.server.hostname=本機IP(非127.0.0.1)來解決。
我使用的方法是在啓動參數上加入 -Djava.rmi.server.hostname=10.5.31.56
這樣不用改hosts，也能夠解決這個問題。

使用

啓動代理開始鏈接

要使用JRockit Management Console來監控JRockit JVM，首先必須啓動要監控的JVM中的管理代理。也就是說應用系統必須是用JRockit JDK進行啓動的，而且啓動了但願監控的JRockit的JMX管理代理服務。能夠經過使用JRCMD或Ctrl-Break Handler來啓動和關閉管理代理，最簡單的方法是直接藉助於-Xmanagement標誌來啓動它。如java -Xmanagement [your application]。可是經過JRCMD或Ctrl-Break Handler來進行管理更加方便與無侵入，連啓動的命令都不用個性。有關JRCMD或Ctrl-Break Handler以及-Xmanagment選項的更多信息，請參見Management Console文檔和Sun的JMX監控與管理的文檔。

咱們首先要在管理控制檯中建立一個鏈接，鏈接至咱們感興趣的 JVM ，並確保系統正在運行且沒有過載。而後，選中鏈接並點擊管理控制檯中的「Start Memleak」圖標，將啓動內存增加的一個趨勢(Trend)分析。 JVM 中每次進行垃圾收集時， JRockit 都會把數據發送給位於一個趨勢分析表中的 Memory Leak Detector，以下圖所示，你能夠根據本身的須要點擊標題欄進行升降序排列，找出你須要進一步監測的對象。或者在下面的「Type filter」裏輸入過濾條件，縮小你的監測範圍。

趨勢分析挖掘源頭

對趨勢進行分析，經過在每次垃圾收集時計算每一個類的現有對象的數目，若是特定類的對象數目隨時間而增加，就可能發生了內存泄漏。泄漏可能像細流同樣很是小，因此趨勢分析必須運行很長一段時間。在短期內，可能會發生一些類的局部增加，而以後它們又會跌落。可是趨勢分析的開銷很小（最大開銷是在每次垃圾收集時將數據包由JRockit發送到Memory Leak Detector）。開銷不該該成爲任何系統的問題——即便是一個全速運行的生產環境中的系統。起初數目會跳躍不停，可是一段時間以後它們就會穩定下來，並顯示出哪些類的數目在增加。

選中想要關注的Type，點擊右鍵，在彈出的菜單中選擇「Show Referring Type」，切換到「Type」標籤並顯示引用的關係圖，以下圖，（注意：如下示例的圖示只是做爲說明之用，與實際的應用系統並不相符。）

在圖上選中關注點，並右鍵，能夠根據不一樣的類型選擇「List Instances」 在下方Instances裏或選擇「List Largest Arrays」在下方的Largest Arrays裏會列出全部的實例。

接下來，能夠選中某一實例，右鍵，在彈出的菜單中選擇「Inspect Instance」，切換「Instances」標籤，並顯示實例間的引用關係，而且在下方的「Inspector」窗口中顯示具體實例的詳細信息，能夠很方便地點擊左邊的+號來逐級地展開進行觀察，也能夠經過右鍵的「Refresh」菜單實時地更新實例的信息。

在Instances Graph上，能夠根據關注點，選中它，右鍵，在彈出的菜單中，選擇「Show Allocation Traces」，切換到「Allocation Stack Traces」標籤，能夠根據百分比的大小直接定位到你的源碼代去，抓到源頭了就能夠採起相應的方法進行解決問題。

限於篇幅，以上僅簡單介紹Memory Leak Detector的使用過程，更加豐富的以及Runtime Analyzer、Management Console功能能夠從附帶的幫助文檔中獲取。

總結

簡單地說，JRockit是汽車的引擎，而JRockit Mission Control是用於調優和維護引擎的工具和設備箱。

當前用於監控、管理和分析Java運行時的大部分技術都使用了至關具備侵入性的技術，好比字節碼裝置和JVMPI（現已廢棄不用並被JVMTI所取代）。JRMC主要關注在完成必需的工具檢測的同時對運行的系統形成最小的影響。它所使用的技術還使得工具與JVM斷開鏈接以後應用程序馬上能夠以全速運行。所以，JRMC適用於在生產環境中使用。它的開銷很是小，這能夠將Heisenberg效應降至最低，併爲應用程序提供比其餘開銷更大的技術更有表明性的數據。

JRockit JVM 擁有一些用於實時內存泄漏檢測的獨特功能。如今的JRockit JDK包含一個多用途的工具套件，可用於進行監控、管理、分析和消除應用程序中的內存泄漏。JRMC可免費用於開發。它能夠可靠地用在生產環境中，並且在使用以後，也不會在系統中留下任何痕跡。在實際應用中，它所引發的性能開銷要比其餘工具小的多。

本文僅是簡要介紹一下這個套件的功能，關於JRMC的更多信息請見其幫助與BEA網站的文檔。

最後，做爲一名Java開發人員，應當始終關注應用程序的性能問題；同時也應該同可以幫助提升應用程序性能的人（如DBA，其實這常常是最重要的一個環節）一塊兒協做；並儘量地去關注Java性能方面的一些最佳實踐。好比：能夠常常訪問Java Performance Tuning http://www.javaperformancetuning.com/

參考資料:

JROCKIT MISSION CONTROL簡介，Marcus Hirt