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）。
JRockit Management Console
JRockit Management Console是一個基於JMX的控制台，用於監控和管理多個JRockit實例，提供至關重要的狀態數據和控制JRockit JVM的運行時特性的方法。它捕獲並顯示關於垃圾收集器（GC）暫停、內存、堆使用和CPU負載的實時數據，以及部署在JVM內部MBean服務器上注冊的所有JMX MBean所公開的信息。JVM管理包括對CPU相似性、垃圾收集策略和內存池大小的動態控制，還包括一個開銷低的方法分析器和一個異常計數器。
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還提供快速找出洩漏原因的手段。可以在趨勢分析表中選擇一個懷疑類型，所有具有指向選中類型的實例的類型都可以顯示在一個圖中。圖形節點可以隨意展開，用戶可以回溯到導致引用的最終原因。類的實例可以被顯示，指向一個選中實例的所有實例都可以在一張實例圖中顯示出來。可以跟蹤某個類的所有分配情況。
