[发明专利]用于内存泄漏诊断的方法和装置

说明书

技术领域

本发明涉及一种用于垃圾收集语言的内存泄漏诊断的方法和装置。 

背景技术

在一些编程语言以及相关的运行时间(runtime)中，通常会由应用程序本身提供一种内存管理功能。对于那不再被程序需要的内存是由程序设计员来释放。如果程序不能合理释放不同的内存将导致内存资源的浪费，即这些内存将不能被任何其他的程序使用。导致这种内存浪费的程序错误通常称之为“内存泄漏”。在有些编程语言中，会采用自动内存管理而不是依赖程序员释放内存。这种自动内存管理在本领域通常称之为“垃圾收集”，就是一种与编程语言以及其相关的运行时间的实施相关的运行时间系统的主动元件。这种自动内存管理通过自动释放那些不再为运行程序所引用的内存部分将程序员部分地从释放内存的管理工作中解脱出来。但是，自动内存管理会产生另一个问题，就是有些对象保留对部分内存中的数据结构的引用(reference)，而这些数据结构在未来的应用程序执行中将不会被使用。这种引用会阻止自动垃圾收集器回收那些不再被使用的内存部分，也导致了“内存泄漏”。因此，尽管垃圾收集机制帮助减少了“内存泄漏”问题，但是后一种内存泄漏仍旧存在并导致计算机的性能降低，严重的时候会导致应用程序的运行占用所有的内存并导致计算机崩溃。因此，内存泄漏由于其对计算机的性能造成巨大影响而削弱了计算机的可获得性和安全性。 

对于支持自动内存管理的运行时间中的内存泄漏，其主要以两类方式存在：一类是通过每次执行而快速地创建大量的泄漏或以至于为人所觉察的方式创建泄漏；另一类是通过每次执行而连续微妙地以至于无法察觉地创建泄漏。 

如何发现和找到那些正在泄漏的对象以及快速找到泄漏的原因是本领域需要解决的问题。一个系统的泄漏诊断起来是非常复杂的，尤其是对于那些每次连续以及较小容量地发生的缓慢泄漏而言是如此。对于在堆上的不明显 的增长是非常难以辨识的。通常，在发现泄漏时已经为时已晚，泄漏程序已经对整个系统造成了严重的影响。这对于那种开始很小但是在整个运行时间段内持续增长的泄漏而言尤其如此。有时，在问题大到足以可注意之前需要高达几周的服务时间。识别这些潜在泄漏是非常困难的，尤其是对于不能忍受多次堆(heap)访问甚至堆转储(dump)的在线系统(live productive system)而言是如此，因为这些系统不能忍受由于堆操作需要的执行暂停。尽管现在存在各种垃圾回收方式并且也各有益处，但是这种内存泄漏对于Java程序而言依然是一个问题。 

目前，现有的一些技术有助于用户对黑箱进行研究以便确定在运行时间(runtime)处的根本原因。对诊断内存泄漏，现有技术主要依赖于比较区分堆快照(snapshot)(堆快照是一种由像节点一样的类型以及其间的引用构成的图(graph))以及根据对象数量的增长来进行诊断。这些技术在每轮垃圾收集之后监视堆，并且观察自由空间的向下的锯齿图形(内存的使用率曲线图)直到程序无法在从堆上获得空间为止(每次收集的、可供以后使用的内存越来越少)。这种现有的技术并不能用于在线系统，因为这种堆快照的获取和分析会使得具有较大的堆容量的系统暂停几十秒。对于诸如服务器的在线系统而言，这种延迟或暂停会导致超时，从而显著影响在线应用的表现。基于上述原因，这种延迟和暂停对于在线系统而言是完全不可接受的。 

而且，用于大型应用程序的内存堆往往容量巨大，因此，试图对堆快照进行频繁的比较对这些应用程序的诊断帮助有限，因为泄漏对象并不明显，但是如果利用现有技术进行泄漏诊断，应用程序会由于为进行泄漏诊断而频繁进行堆快照的比较操作而减慢，这将对服务质量以及用户的体验带来负面的效果。而且，这些技术在有些情况下将使得正在运行的应用程序或系统受到很大干扰(perturb)以至于不具有实际价值，尤其是在在线环境下。 

现有的内存泄漏的诊断方法对工业应用的效果有限，因为这些现有的方法通常将基本类型识别为嫌疑类型。例如，一种现有技术建议使用引用(reference)来查找负责内存泄漏的有用对象。但是引用不能包含执行语境信息。被引用的嫌疑对象因为是基本的常见使用类型，可能同时被多个引用者持有。在这种情况下，人们依然不了解这些引用为什么会产生以及在何种条件下泄漏问题会被再现。诊断以及修复是否正确难以进行判别。