专门工具的优势
一旦你知道程序中存在内存泄漏,你需要更专业的工具来查明为什么这里会有泄漏。而JVM是不可能告诉你的。现在有很多工具可以利用了。这些工具本质上主要通过两种方法来得到JVM的存储系统信息的:JVMTI和字节码仪器。
通过这些技术来侦测内存泄漏存在两个缺点,而这使得他们在产品级环境中的运用不够理想。首先,根据两者对内存的使用量和内存事务性能的降级是不可以忽略的。从JVM获得的堆的使用量信息需要在工具中导出,收集和处理。这意味着要分配内存。按照JVM的性能导出信息是需要开销的,垃圾回收器在搜集信息的时候是运行的非常缓慢的。另一个缺点就是,这些工具所需要的信息是关系到JVM的。让工具在JVM开始运行的时候和它关联,而在分析的时候,分离工具而保持JVM运行,这显然是不可能的。
既然JRockit Memory Leak Detector是被集成到JVM中的,那么以上两种缺点就不再存在。首先,大部分的处理和分析都是在JVM中完成的,所以就不再需要传送或重建任何数据。处理也可以建立在垃圾回收器的基础上,即提高速度。再有,内存泄漏侦测器可以同一个运行的JVM关联和分离,只要JVM在开始的时候伴随着 –Xmanagement选项(通过远程JMX接口允许监听和管理JVM)。当工具分离以后,工具不会遗留任何东西在JVM中;JVM就可以全速运行代码就好像工具关联之前一样。
趋势分析
让我们更深一步来观察这个工具,了解他如何捕捉到内存泄漏。在你了解到代码中存在内存泄漏,第一步就是尝试计算出什么数据在泄漏——哪个对象类导致泄露。The JRockit Memory Leak Detector通过在垃圾回收的时候,计算每个类所包含的现有的对象来达到目的。如果某一个类的对象成员数目随着时间增长(增长率),那么这里很可能存在泄漏。
Figure 2. The trend analysis view of the Memory Leak Detector
因为一个泄漏很可能只是像水滴一样小,所以趋势分析必须运行足够长的一段时间。在每个短暂的时间段里,局部类的增加会使得泄漏发生推迟。但是,内存事务是非常小的(最大的内存事务是由在每个垃圾回收时从JRockit向内存泄漏探测器发送的一个数据包组成的)。内存事务不应该成为任何系统的问题——甚至一个在产品阶段全速运行的程序。
一开始,数字会有很大的跳转,随时间的推进,这些数字会变得稳定,而后显示哪些类会不断的增大。

