内存泄漏检测工具_第2部分：泄漏检测和分析的工具和功能
企业应用程序中的内存泄漏会导致大量紧急情况。 成本是分析所花费的时间和金钱，生产环境中昂贵的停机时间，压力以及对应用程序和框架失去信心的结合。
非代表性的测试环境，无效的工作负载识别以及不足的测试周期会导致无法通过测试过程检测到内存泄漏。 公司通常无法或不愿意花费大量的时间和金钱来克服这些障碍。 问题是教育，文化和财政问题之一。 本文将不会尝试解决这些问题，而是将重点放在有助于解决这些问题的技术解决方案上。
本文是我们介绍性文章的第1部分：内存泄漏概述的后续文章。 在第2部分中，我们将通过一些实际案例研究更详细地描述 V6.1中的内存泄漏分析和检测功能。 本文介绍了 .1中新引入的内存泄漏检测功能，以及称为Java内存转储诊断（MDD4J）的脱机内存泄漏分析工具。 这两个功能的组合可用于确定在 中运行的Java和Java 2平台企业版（J2EE™）应用程序中内存泄漏的根本原因。
本文是为使用 上部署的应用程序的Java开发人员，应用程序服务器管理员和问题确定顾问编写的。
什么是Java中的内存泄漏？
当不再需要对象持有对对象的引用时，Java应用程序中就会发生内存泄漏。即使Java虚拟机（JVM）具有内置的垃圾收集机制，此问题也阻止了自动Java垃圾收集过程释放内存（请参阅参考资料）。 相关主题 ），使程序员摆脱了任何明确的对象解除分配职责。 这些内存泄漏问题表现为随着时间的推移Java堆使用量不断增加，而当堆完全用尽时最终会出现。 这种类型的内存泄漏称为Java堆内存泄漏。
碎片和本机内存泄漏
由于无法清除不再使用的本机系统资源（例如文件句柄，数据库连接工件等），Java中也可能发生内存泄漏。 这种类型的内存泄漏称为本地内存泄漏。 这些类型的内存泄漏表现为随着时间的推移，进程大小不断增加，而Java堆使用率却没有任何增加。
尽管Java堆内存泄漏和本机内存泄漏最终都显示为，但并非所有都是Java堆泄漏或本机内存泄漏引起的。 由于Java垃圾回收过程无法在压缩期间为新对象释放任何连续的空闲内存块，因此Java堆碎片也可能导致。 在这种情况下，尽管存在大量的可用Java堆，但仍可能发生。 由于Java堆中存在固定或分配的对象，因此在IBM的 1.4.2或更早版本中可能会出现碎片问题。 固定对象是由于JNI（Java本机接口）对这些对象的访问而无法在堆压缩期间移动的对象。 定量对象是在堆压缩期间由于来自线程堆栈的引用而无法移动的对象。 由于频繁分配大尺寸的对象（超过1 MB），碎片化问题通常还会加剧。
由于碎片问题或由于本机内存泄漏而导致的错误不在本文讨论范围之内。 通过观察一段时间内的Java堆使用情况，可以将本机内存泄漏和碎片问题与Java堆内存泄漏区分开来。 ® 和详细的GC输出（请参阅参考资料 ）可用于进行这种区分。 Java堆使用率的增加会导致完全耗尽，这表明存在Java堆内存泄漏，而对于本机内存泄漏和碎片问题，堆使用率不会随时间显着增加。 对于本机内存泄漏，进程大小将增加，对于碎片问题，在发生时将有大量可用堆。
Java应用程序中内存泄漏的常见原因
如上所述，Java中内存泄漏的常见根本原因（Java堆内存泄漏）是非故意的（由于程序逻辑错误）对象引用，这些对象引用在Java堆中占据了未使用的对象。 在本节中，描述了导致Java堆内存泄漏的许多常见类型的程序逻辑错误。
无限缓存
一个非常简单的内存泄漏示例是一个java.util.对象（例如，一个），该对象充当缓存，但是没有限制地增长。 清单1显示了一个简单的Java程序，该程序演示了基本内存如何泄漏数据结构。
清单1.示例Java程序将对象泄漏到静态容器对象中
public class MyClass {staticHashSet myContainer = new HashSet();HashSet myContainer = new HashSet();public void leak(int numObjects) {for (int i = 0; i < numObjects; ++i) {String leakingUnit = new String("this is leaking object: " + i);myContainer.add(leakingUnit);}}public static void main(String[] args) throws Exception {{MyClass myObj = new MyClass();myObj.leak(100000); // One hundred thousand} System.gc();}在清单1所示的Java程序中，有一个名为的类，该类通过的名称对进行了静态引用。 在类的主要方法：中，有一个子作用域（粗体文本），在该作用域中实例化了类：的实例，并调用了其成员操作：泄漏。 这导致在容器：中添加了十万个对象。 程序控件退出子范围后，将对对象的实例进行垃圾回收，因为在该子范围之外没有对对象的实例的引用。 但是，类对象具有对名为的成员变量的静态引用。 由于此静态引用，即使在对象的唯一实例被垃圾回收之后， 仍继续保留在Java堆中，并且与一起，中的所有对象也继续保留，从而保持了Java堆的重要部分，直到程序退出main方法为止。 该程序演示了基本的内存泄漏操作，其中涉及到高速缓存对象的无限增长。 大多数高速缓存都是使用模式实现的，该模式涉及对顶级Cache类的静态引用，如本示例所示。
未调用的侦听器方法
由于程序错误导致许多内存泄漏，导致无法调用清除方法。 侦听器模式是Java程序中常用的模式，用于实现不再需要共享资源时清理共享资源的方法。 例如，J2EE程序通常依赖接口及其回调方法来清除用户会话过期时存储在用户会话中的任何状态。 有时，由于程序逻辑错误，负责调用侦听器的程序可能无法调用它，或者侦听器方法可能由于异常而无法完成，这甚至可能导致Java堆中未使用的程序状态仍然存在不再需要。
无限循环
由于程序错误，会发生一些内存泄漏，其中应用程序代码中的无限循环会分配新对象，并将新对象添加到可从程序循环范围外部访问的数据结构中。 由于对共享的不同步数据结构的多线程访问有时会发生这种无限循环。 这些类型的内存泄漏表现为快速增长的内存泄漏，如果详细的GC数据报告在很短的时间内可用堆空间急剧下降，则会导致。 对于这种类型的内存泄漏情况，重要的是分析在观察到空闲内存正在Swift下降的短时间内进行的堆转储。 在标题为“ 案例研究3”和“ 案例研究4”的部分中讨论了在IBM支持机构中观察到的涉及无限循环的两个不同内存泄漏案例的分析结果。
尽管可以通过分析堆转储来识别内存泄漏数据结构，但要确定无限循环中的内存泄漏代码并非易事。 卡在无限循环中的方法可以通过查看在观察到空闲内存Swift下降的过程中获取的线程转储中所有线程的线程堆栈来确定。 IBM SDK实现与堆转储一起生成Java核心文件。 该文件包含所有活动线程的线程堆栈，可用于标识可能陷入无限循环的方法和线程。
会话对象过多
由于对支持最大用户负载所需的最大堆大小进行了不适当的配置，因此会发生许多。 一个简单的示例是使用内存中对象存储用户会话信息的J2EE应用程序。 如果未对可以保存在内存中的会话对象的最大数量设置最大限制，则在高峰用户加载时间内可能有许多会话对象。 这可能导致并不是真正的内存泄漏，而是配置不正确。
解决方案
传统的内存泄漏技术基于这样的想法，即您知道自己存在内存泄漏，并希望找出根本原因。 技术各不相同，但总是涉及堆转储分析，附加Java虚拟机分析器接口（JVMPI）或Java虚拟机工具接口（JVMTI）代理，或使用字节码插入来跟踪对集合的插入和删除。 这些分析机制非常复杂，尽管它们具有巨大的性能负担，并且不适合在生产环境中持续使用。
问题
企业应用程序中的内存泄漏会导致大量紧急情况。 此类问题的成本包括分析所需的时间和金钱，生产环境中昂贵的停机时间，压力以及对应用程序和框架的信心丧失。
典型的分析解决方案是尝试将应用程序移动到隔离的测试环境中，在该环境中可以重新创建问题并可以执行分析。 在这些测试环境中，复制内存的困难使关联的内存泄漏的成本增加了。
传统的冗余方法（例如群集）只能在一定程度上提供帮助。 内存泄漏将在整个群集成员中传播。 由于受影响的应用程序服务器的响应速度变慢，工作负载管理技术导致请求被路由到更健康的服务器，并可能导致协调的应用程序服务器崩溃。
成本构成
典型的内存泄漏场景分析表明，企业应用程序中内存泄漏分析成本的主要来源是直到问题严重时才识别它们。 除非管理员具有监视内存趋势的技能，时间和资源，否则用户通常不会意识到自己有问题，直到他们的应用程序性能下降并且应用程序服务器对管理请求无响应为止。 通常，与内存泄漏相关的成本来源主要来自三个方面：测试，检测和分析。
已将内存泄漏的检测和分析确定为相关但独立的解决方案中的两个不同问题。 不幸的是，没有简单的技术解决方案来解决与足够的测试相关的成本，并且该主题不会在本文中解决。
将检测与分析分开
传统技术的问题在于它们试图同时进行检测和分析。 这导致解决方案性能不佳，或者涉及不适合许多生产环境的技术，例如JVMPI代理或字节代码插入。
通过将检测问题与分析隔离，我们能够在 V6.0.2中提供轻量级的生产就绪型内存泄漏检测机制。 该解决方案使用便宜的通用统计信息来监视内存使用趋势并提供内存泄漏的早期通知。 这使管理员有时间准备适当的备份解决方案并分析问题的原因，而又不会造成与测试环境中的复制相关的昂贵且令人沮丧的问题。
尽管生成的过程很昂贵，并且不建议在应用程序服务器承受大量生产负载的情况下使用，但在负载处于活动状态时，无需生成。 管理员可以设置负载平衡，或在较低的使用时间生成，以避免短期内性能下降。
为了促进此分析， 提供了Java内存转储诊断工具（MDD4J），这是一种重量级的离线内存泄漏分析工具，将多种成熟技术整合到单个用户界面中。
为了弥合检测与分析之间的鸿沟，我们提供了一种自动化工具，可以在IBM JDK上生成。 此机制将生成多个堆转储，这些堆转储已与足够的内存泄漏进行了协调，以便于使用MDD4J进行比较分析。 的生成非常昂贵； 默认情况下，此功能是禁用的，并且提供了MBean操作以在适当的时间启用它。
内存泄漏检测
中的轻量级内存泄漏检测旨在提供对测试和生产环境中的内存问题的早期检测。 它对性能的影响最小，并且不需要附加代理程序或使用字节码插入。 尽管它旨在与脱机分析工具（包括MDD4J）结合使用，但它并非旨在提供问题根源的分析。
算法
如果应用程序服务器的状态和工作负载稳定，则内存使用模式应相对稳定。
图1.详细的GC图显示了内存泄漏应用程序的可用内存（绿色）和已用内存（红色）
启用详细GC是调试内存泄漏的问题确定过程的第一步。 有关在IBM Kit上启用详细GC的说明，请参阅《 IBM Kit的诊断指南》（请参阅参考资料 ）。 支持人员和客户都使用类似的流程和图表进行详细的GC统计，以确定内存泄漏是否是失败的原因（请参阅参考资料 ）。 如果GC周期后的可用内存持续减少，则很可能发生内存泄漏。 图1中的图表是在发生内存泄漏的应用程序中发生GC循环后，图表中的可用内存的示例（该图表使用的是内部IBM工具）。 泄漏非常明显，但是除非主动监视数据，否则在服务器崩溃之前您不会意识到它。
我们的内存泄漏检测机制通常会自动执行此过程，以在GC周期后寻找空闲内存中的持续下降趋势。 我们无法假设可以获得详细的GC信息，并且JVMPI对于生产而言过于昂贵（并且需要附加的代理程序）。 因此，我们仅限于PMI数据，这些数据会进行Java API调用以获取可用内存和总内存统计信息。 详细GC会在GC周期结束后直接提供可用内存统计信息，而PMI数据则不会。 我们通过使用分析可用内存统计信息方差的算法来对垃圾回收周期后的可用内存进行近似估算。
泄漏可能非常快，也可能非常缓慢，因此我们分析了短间隔和长间隔的内存趋势。 没有设置最短间隔的时间段，而是通过可用内存统计信息的方差得出的。
由于我们在生产服务器中运行，并且试图检测内存泄漏（而不是创建内存泄漏），因此我们必须存储非常有限的数据。 废弃不再需要的原始数据点和汇总数据点，以将我们的内存占用降至最低。
通过在近似/汇总的可用内存统计信息中查找下降趋势来分析周期。 规则的配置决定了如何应用严格的条件，尽管该规则配置了一组应通用的默认值。
除了垃圾回收周期后近似内存的下降趋势外，我们还会研究垃圾回收后的平均可用内存低于某些阈值的情况。 这种情况要么是内存泄漏的迹象，要么是在资源太少的应用程序服务器上运行应用程序。
i系列
OS /400®或引入了一些独特的方案。 机器通常配置有有效的可用内存池大小。 该池大小决定了可用于JVM的内存量。 当Java堆超过此值时，将使用DASD（磁盘）容纳堆。 这样的解决方案总是会导致糟糕的性能，尽管管理员可能没有意识到这个问题，因为即使服务器瘫痪了，应用服务器仍会保持响应。
如果将Java堆大小扩展到DASD，我们将发出警报，通知管理员这将发生，并且它们的有效内存池大小过小，资源太少或发生内存泄漏。
扩大堆
Java堆通常配置为具有最小和最大堆大小。 在堆扩展的同时，分析可用内存趋势非常困难。 我们避免在堆扩展时进行任何下降趋势分析，而是监视并确定堆是否很快将耗尽资源。 这是通过监视堆大小是否持续增加，GC周期后的可用内存是否在堆的某个阈值以内并因此推动堆扩展以及通过预测当前趋势是否持续（如果JVM继续运行）来实现的资源不足。 如果发现了这种情况，我们会通知用户潜在的问题，以便他们可以监视情况或制定应急计划。
生成
许多分析工具（包括MDD4J）都分析堆转储以查找内存泄漏的根本原因。 在IBM JDK上，通常将因s而生成的用于此类分析。 如果希望更加主动，则需要在适当的时间生成进行分析。 这非常重要，因为如果在不适当的时间生成了，则会导致错误的分析。 例如，如果在工作负载开始时生成了，则通常将填充的缓存标识为内存泄漏。
结合我们的内存泄漏检测机制， 提供了一种可以结合内存泄漏趋势生成多个堆转储的功能。 这样可确保在出现明显的内存泄漏证据后进行堆转储，并具有足够的内存泄漏以确保获得有效分析结果的最佳机会。
缺省情况下，可以启用自动堆转储生成，或者可以在适当的时间使用MBean操作启动自动堆转储。
除了自动的堆转储生成实用程序之外，还可以通过使用（请参阅 信息中心）或在设置一些环境变量（请参阅Unix®平台）后发送kill -3信号（在Unix®平台上）来手动生成堆转储。 相关主题中的诊断指南）。
好处
管理员能够在测试和生产环境中运行轻量级内存泄漏检测，并提前收到内存泄漏的通知。 这使管理员能够设置应急计划，在问题可重现时进行分析并在失去应用程序响应能力或应用程序服务器崩溃之前诊断结果。
结果是大大降低了与企业应用程序中的内存泄漏相关的成本。
继承限制
内存泄漏检测规则是根据一种简单的原理设计的。 它使用免费的可用数据并进行必要的近似计算，以提供有关内存泄漏的可靠通知。 由于所分析数据的固有局限性和所需的近似值，因此，现有解决方案使用更好的数据和更复杂的算法，并且应获得更准确的结果（尽管并非没有很大的性能成本）。 但是，我们可以说，虽然简单，但是我们的实现很便宜，使用通用统计信息并检测内存泄漏。
自主管理器集成
轻量级内存泄漏检测是完全可配置的，旨在与高级自主管理器或自定义JMX客户端进行交互。 IBM 是这种关系的一个示例。
抽象化 拓扑并适当地部署应用程序，以对不断变化的工作负载做出React，同时保持应用程序性能标准。 它还纳入了健康管理政策。 内存运行状况策略使用 内存泄漏检测功能来识别应用程序服务器何时发生内存泄漏。
提供了许多配置内存泄漏检测的策略。 在示例策略中，策略将通过获取多个堆转储（使用工作负载管理来维护应用程序的性能）进行分析来对内存泄漏通知做出React。 另一个策略可能只是监视应用程序服务器的内存水平何时对损坏应用程序服务器重新启动至关重要。
生产系统的内存泄漏分析
确定Java内存泄漏的根本原因需要两个步骤：
确定内存泄漏在哪里。 标识对象，无意引用，持有这些无意引用的类和对象，以及无意引用指向的对象。
确定泄漏发生的原因。 确定负责在程序的适当位置不释放那些无意引用的源代码方法（程序逻辑）。
用于Java的 Dump 工具有助于确定应用程序中发生内存泄漏的位置。 但是，该工具无法帮助识别导致内存泄漏的错误源代码。 借助此工具识别出泄漏的数据结构类和程序包后，您可以使用任何调试器或在日志记录中使用特定的跟踪语句来识别错误的源代码方法，并对应用程序代码进行必要的更改以解决内存问题。泄漏。
分析技术需要占用大量CPU，内存和磁盘空间。 因此，分析机制被实现为离线工具。 该机制特别适合在生产环境或压力测试环境中运行的大型应用程序。 该工具可用于分析（离线）手动获得的或与轻量级内存泄漏检测结合产生的这些转储。
用于Java的 Dump 工具针对以下角色，旨在满足这些相关目标：
该工具支持IBM便携式堆转储（.phd），IBM Text，HPROF Text和SVC堆转储格式。 有关格式和受支持的JDK版本的详细列表，请参见附录 。
技术概述
用于Java的 Dump 工具提供了对来自Java虚拟机（JVM）的常见格式的内存转储的分析功能，该Java虚拟机在各种IBM和非IBM平台上运行 。 内存转储的分析旨在确定Java堆中可能是内存泄漏的根本原因的区域或数据结构的集合。该工具以图形格式显示内存转储的内容，同时突出显示已识别的区域作为内存泄漏的嫌疑人。 图形用户界面提供了浏览功能，以验证可疑的内存泄漏区域，并了解包含这些泄漏区域的数据结构。
该工具提供两种主要类型的分析功能：单内存转储分析和比较分析。
分析结果显示在具有以下功能的基于Web的交互式用户界面中：
案例研究1：内存泄漏示例的内存泄漏分析
对来自的一对堆转储的比较分析（清单1中的示例代码）在图2中显示了以下泄漏可疑对象。
图2.疑似内存泄漏示例
分析结果的“可疑”选项卡在四个表中列出了可疑的内存泄漏。 The Data That Most to table lists data which are by the above. Each row of the table a leak data :
Often there are data and the of a being a leak can from these . In this case, there is only one and the fact that this data can for 84 of the total heap size of the dump this as a very .
The table, Data with Large Drops in Reach Size , lists data by the dump on the heap dump. Each row in the table a data with a that has a large of child . Both the first and table can point to the same . If in the first and table are , then the rows in both the are .
The third table, Types that most to in Heap Size , lists data types that have a large in the of the and dump. These data types are not into data or based on their ; , these are the top-most data types for the whole heap. Again, if a data type has a large of in a data or , then that data type row is .
The table, that most to in Heap Size , lists Java names for data types that have a large in the of the and dump. The which is for the leak is often by the name and class name of the data types which are part of . This table names with the , which can help the for the leak.
A heap dump (often the heap dump with the error) can be also with MDD4J. 3 shows the of the tab when the heap dump from the in 1 is just by .
(There are only three in this case in the tab. There are no data is not . The Types that most to Heap Size and that most to Heap Size do not show any but only the total of in the dump.)
3. dump for the leak from 1
After a data in the tab, you can visit the tab to see the chain of the leak in the heap, as shown in 4.
4. for leak
In this , it can be seen that there is a chain of from the class with the name to a to a to an array of $Entry with a very large of $Entry child . Each $Entry holds a . This the data in the leak shown in 1.
The tree view in this tab shows all the in the heap dump, in the cases where an has more than one . The table in the left panel shows all the of any in the tree. Any row in the table can be to the tree to the of the . The left panel also shows other for any in the tree; for , the size of the , the of , the total reach size, and so on.
5. for leak
The and tab helps the of what are the major to the of the heap in the dump ( 5). It also helps to show the the major and the data types for each of the major . In this , the node has been as a major in the graph shown in the left panel. On the right panel, the data types that to this node are . The $Entry , of which there is one for each in the , is shown in this set.
The are also in a text file with the name .txt. The text can be from a link in the tab, as well as from the in the file . 2 shows a from the .txt file, which shows the of the for the leak .
2. for leak
Suspected memory leaking regions:
Region Key:0,Leak Analysis Type:SINGLE_DUMP_ANALYSIS,Rank:1.0
Region Size:13MB, !RegionSize.DropSize!13MB
Owner chain - Dominator tree:
MyClass, class0x300c0110, reaches:13MB), LEAK_ROOT
|java/util/HashSet, object0x3036d840, reaches:13MB), LEAK_ROOT_TO_CONTAINER
|-java/util/HashMap, object0x3036d8a0, reaches:13MB), LEAK_ROOT_TO_CONTAINER
|--java/util/HashMap$Entry, array0x30cf0870, reaches:13MB), LEAK_CONTAINER
|---Leaking unit:
|----java/util/HashMap$Entry, object0x3028ad18, reaches:480 bytes)
|----java/util/HashMap$Entry, object have grown by 72203 instances
Region Key:2,Leak Analysis Type:COMPARATIVE_ANALYSIS,Rank:1.0
Region Size:12MB, Growth:12MB, 300001 instances
Owner chain - Dominator tree:
MyClass, class0x300c0110, reaches:13MB), LEAK_ROOT
|java/util/HashSet, object0x3036d840, reaches:13MB), LEAK_ROOT_TO_CONTAINER
|-java/util/HashMap, object0x3036d8a0, reaches:13MB), LEAK_ROOT_TO_CONTAINER
|--java/util/HashMap$Entry, array0x30cf0870, reaches:13MB), LEAK_ROOT_TO_CONTAINER
|---java/util/HashMap$Entry, object0x30e88898, reaches:256 bytes), LEAK_CONTAINER
|----Leaking unit:
|-----java/util/HashMap$Entry, object have grown by 1 instancesCase study 2: for leak due to un- call back
6 shows the and tab for a leak case a found in IBM . This there was some state that was not being up when the was . The graph in this shows that the node is the to the of the heap, which is the is a which all the in data.
6. for a leak un-
To find the root cause of the more , it is to see the tab in 7, where you can see that there are a very large of that are in the user . After at the data and the of , it is to infer that the were not when they were no . Hence, it was to infer that the code was not . It was later that the root cause was a bug to when are , which was at the root cause of this . This issue was soon .
7. view for
Case Study 3: from a leak due to an loop
8 shows the tab from the of two heap dumps taken from a leak case an loop. The in the GC logs show a very fast drop in the free heap space in a very short time. of a heap dump taken the time when the free heap was was to the root cause of the . The heap dump did not have the data in it, the data was in the Java stack, which got prior to the heap dump.
As can be seen from the tab, there are a very large of of from the : org..poi. and an large of of the class org..poi...
8. for a leak in POI
9 shows the tab in this . It can be that there is a chain of from an of the type org..poi.hssf.., which has an a very large (20,431) of .
9. POI
that the were in a which was stuck in an loop and were added to an which was from the Java stack. The dumps taken at the same time as the heap dump two Java which were in the same which was the . of the Java code (from the open POI) some multi- code which were fixed in a . From this , it was to down the root cause of the leak to the POI .
Case study 4: of a leak due to an loop
10 shows of a leak due to an open : com.... From the left panel, you can see that there are an large of com...File that are to the .
10. File
Case study 5: from a leak a large of
11 shows a leak case a large of .
11. JMS
12. for JMS
From the Graph in 12, you can see that these andle are owned by node to the Java heap with class in it. In , the class has an large of . the of a bug that was to in . These were in turn up a large of in the Java heap. These were also up of heap . Thus, this was as a leak with the root cause in the Java heap.
Case study 6: which are not 13. In- HTTP in
13 shows a leak at the 。 The has a to com。ibm。ws。。。 to of 。ibm。ws。。。 。 These are of in- HTTP 。 These can be in large in a J2EE heap, which uses HTTP to store user in 。
Such do not a leak。 of a large of of these types can imply that there too many , due to a heavy user load and an error which, under these , can be by the heap size, or by a limit on the of live kept in at any time。 of a large of of these types could also a leak where held by these are 。 So you can that the leak is in when there are - up in the 。
tools
There are two kinds of Java leak tools on the 。 The first type of tool is an tool that to a and Java heap from the , by the Java or by the JDK 。 of this are Wily , , Leak , and so on。 these tools can the types of that are in over a of time, they do not help to the data of which these are part。
To the root cause of a leak, it is to not only at a lower , but also what is on to the , and look at the whole data the leak at a 。 In , used in some of these tools add to time, which make them for usage。 , , which may also not be 。
set of tools the HAT tool from SUN ® which also Java heap dumps. The HAT tool for data types that have large of in a dump and can also two heap dumps to data types which have in . Again, what is is a of the data .
is an -based tool for IBM JDK heap dumps to the HAT tool, but it does not the root cause of a leak. Dump for Java (MDD4J) upon basic in by and dump for leak root cause , and also an user .
and
The lack of and low leak tools make it hard to deal with leak in or test .
The MDD4J tool is to this gap. By heap dumps in the MDD4J tool the IBM to be to the dumps to root of the leak. These seek to data ( by of ) that are the most in the dumps. This not only low level but also level data , of which the are part. This helps to the of what is at a level of than low level such as .
In , the tool also , which a set of major to the size of the Java heap, their , and their data types. The , along with the , also help to the of what is on to the in , thus the leak. The data types in the and also help to blame to a high level in the whole . This helps to the to the team for .
It is also to point out that the tool only out which may or may not be leaks. This is data and valid of are often .
gap is that it is not for the tool to the code in the that is the leak to occur. To that , it is to stack for every , which is very and is also not in most of dumps.
结论
When used in with leak , the Dump for Java tool a that the of early with state of the art .
: and JVM
The of dumps are by the Dump for Java tool:
IBM Heap Dump (.phd) (for 6.x, 5.1 on most ) IBM Text heap dump (for 5.0 and 4.0 on most ) HPROF heap dump (for on the ® and HP-UX ) SVC Dumps ( on the IBM )
Table 1 a list of , JDK , and Java dump on the JVM.
Table 1. and 平台 JDK Java Dump
AIX®, ®, Linux®
6.1
IBM J9 SDK 1.5
Heap Dump (PHD)
IBM J9 SDK 1.5 (64-bit)
Heap Dump (PHD)
6.0.2
IBM J9 SDK 1.4.2 (64-bit)
Heap Dump (PHD)
6.0 - 6.0.2
IBM SDK 1.4.2
Heap Dump (PHD)
5.1
IBM SDK 1.4.1
IBM Text Heap Dump
5.0 - 5.0.2
IBM SDK 1.3
IBM Text Heap Dump
4.0
IBM SDK 1.3
IBM Text Heap Dump
®, HP®
6.1
SUN JDK 1.5
HPROF(ASCII)
SUN JDK 1.5 (64-bit)
HPROF(ASCII)
6.0.2
SUN JDK 1.4.2 (64-bit)
HPROF(ASCII)
6.0 - 6.02
SUN JDK 1.4
HPROF(ASCII)
5.1
SUN JDK 1.4
HPROF(ASCII)
5.0 - 5.0.2
SUN JDK 1.3
HPROF(ASCII)
4.0
SUN JDK 1.3
HPROF(ASCII)
z/OS®
6.1
IBM J9 SDK 1.5
SVC/PHD
IBM J9 SDK 1.5 (64-bit)
SVC/PHD
6.0.2
IBM SDK 1.4.2 (64-bit)
SVC/PHD
6.0 - 6.0.2
IBM SDK 1.4.2
SVC/PHD
5.1
IBM SDK 1.4.1
SVC
5.0-5.02
IBM SDK 1.3
SVC
OS/400
6.1
IBM SDK 1.5
PHD
The would like to thank Julin and Stan Cox for the paper, and Scott for the .
翻译自:
内存泄漏检测工具
