前言
从所周知，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工具套件之间的关系。
性能调优工具BEA JRockit Mission Control图-1" src="https://www.ltesting.net/attachments/2008/06/47162_200806131510251XNcF.gif">
JRockit Management Console
JRockit Management Console是一个基于JMX的控制台，用于监控和管理多个JRockit实例，提供至关重要的状态数据和控制JRockit JVM的运行时特性的方法。它捕获并显示关于垃圾收集器（GC）暂停、内存、堆使用和CPU负载的实时数据，以及部署在JVM内部MBean服务器上注册的所有JMX MBean所公开的信息。JVM管理包括对CPU相似性、垃圾收集策略和内存池大小的动态控制，还包括一个开销低的方法分析器和一个异常计数器。
文章来源于领测软件测试网 https://www.ltesting.net/
