从所周知,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="http://www.ltesting.net/uploads/2008/06/47162_200806131510251XNcF.gif">
JRockit Management Console是一个基于JMX的控制台,用于监控和管理多个JRockit实例,提供至关重要的状态数据和控制JRockit JVM的运行时特性的方法。它捕获并显示关于垃圾收集器(GC)暂停、内存、堆使用和CPU负载的实时数据,以及部署在JVM内部MBean服务器上注册的所有JMX MBean所公开的信息。JVM管理包括对CPU相似性、垃圾收集策略和内存池大小的动态控制,还包括一个开销低的方法分析器和一个异常计数器。