发布时间：2006.04.19 16:46 来源：java家() 作者：< iframe border=0 marginWidth=0 marginHeight=0src="http://219.239.88.50:80/adsunion/get/;pl=pl-20-pip-software;tp=if;sk=0;ck=0;/?" frameBorder=0noResize width=1 scrolling=no height=1>< /iframe>抽象尽管java虚拟机和垃圾回收机制管理着大部分的内存事务，但是在java软件中还是可能存在内存泄漏的情况。

的确，在大型工程中，内存泄漏是一个普遍问题。

避免内存泄漏的第一步，就是要了解他们发生的原因。

这篇文章就是要介绍一些常见的缺陷，然后提供一些非常好的实践例子来指导你写出没有内存泄漏的代码。

一旦你的程序存在内存泄漏，要查明代码中引起泄漏的原因是很困难的。

同时这篇文章也要介绍一个新的工具来查找内存泄漏，然后指明发生的根本原因。

这个工具容易上手，可以让你找到产品级系统中的内存泄漏。

垃圾回收（GC）的角色虽然垃圾回收关心着大部分的问题，包括内存管理，使得程序员的任务显得更加轻松，但是程序员还是可能犯些错误导致内存泄漏问题。

GC(垃圾回收)通过递归对所有从"根"对象(堆栈中的对象，静态数据成员，JNI句柄等等)继承下来的引用进行工作，然后标记所有可以访问的活着的对象。

而这些对象变成了程序唯一能够操纵的对象，其他的对象都被释放了。

因为GC使得程序不能够访问那些被释放的对象，所以这样做是安全的。

内存管理可以说是自动的，但是这并没有让程序员脱离内存管理问题。

比方说，对于内存的分配（还有释放）总是存在一定的开销，尽管这些开销对程序员来说是暗含的。

一个程序如果创建了很多对象，那么它就要比完成相同任务而创建了较少对象的程序执行的速度慢（其他提供的内容都相同）。

导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。

如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器验证这些对象是否不再需要。

正如我们前面看到的，如果存在对象的引用，这个对象就被定义为"活着的"，同时不会被释放。

要确定对象所占内存将被回收，程序员就要务必确认该对象不再会被使用。

典型的做法就是把对象数据成员设为null或者从集合中移除该对象。

注意，当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。

从更高一个层次看，这就是所有存在内存管的语言对内存泄漏所考虑的事情，剩余的对象引用将不再会被使用。

典型泄漏既然我们知道了在java中确实会存在内存泄漏，那么就让我们看一些典型的泄漏，并找出他们发生的原因。

全局集合在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。

在这些情况下，注意力就被放在了管理数据仓库的大小上。

当然是有一些适当的机制可以将仓库中的无用数据移除。

可以有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。

这个作业会验证仓库中的数据然后清除一切不需要的数据。

另一个办法是使用引用计算。

集合用来对了解每个集合入口关联器（referrer）的数目负责。

这要求关联器通知集合什么时候完成进入。

当关联器的数目为零时，就可以移除集合中的相关元素。

高速缓存高速缓存是一种用来快速查找已经执行过的操作结果的数据结构。

因此，如果一个操作执行很慢的话，你可以先把普通输入的数据放入高速缓存，然后过些时间再调用高速缓存中的数据。

高速缓存多少还有一点动态实现的意思，当数据操作完毕，又被送入高速缓存。

一个典型的算法如下所示：1．检查结果是否在高速缓存中，存在则返回结果；2．如果结果不在，那么计算结果；3．将结果放入高速缓存，以备将来的操作调用。

这个算法的问题（或者说潜在的内存泄漏）在最后一步。

如果操作伴随着一个不同的，输入非常大的数字，那么存入高速缓存的也是一个非常大的结果。

那么这个方法就不是能够胜任的了。

为了避免这种潜在的致命错误设计，程序就必须确定高速缓存在他所使用的内存中有一个上界。

因此，更好的算法是：1．检查结果是否在高速缓存中，存在则返回结果；2．如果结果不在，那么计算结果；3．如果高速缓存所占空间过大，移除缓存中旧的结果；4．将结果放入高速缓存，以备将来的操作调用。

通过不断的从缓存中移除旧的结果，我们可以假设，将来，最新输入的数据可能被重用的几率要远远大于旧的结果。

这通常是一个不错的设想。

这个新的算法会确保高速缓存的容量在预先确定的范围内。

精确的范围是很难计算的，因为缓存中的对象存在引用时将继续有效。

正确的划分高速缓存的大小是一个复杂的任务，你必须权衡可使用内存大小和数据快速存取之间的矛盾。

另一个解决这个问题的途径是使用ng.ref.SoftReference类坚持将对象放入高速缓存。

这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。

类装载器Java类装载器创建就存在很多导致内存泄漏的漏洞。

由于类装载器的复杂结构，使得很难得到内存泄漏的透视图。

这些困难不仅仅是由于类装载器只与"普通的"对象引用有关，同时也和对象内部的引用有关，比如数据变量，方法和各种类。

这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器将驻留在JVM中。

既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。

定位内存泄漏常常地，程序内存泄漏的最初迹象发生在出错之后，得到一个OutOfMemoryError在你的程序中。

这种典型地情况发生在产品环境中，而在那里，你希望内存泄漏尽可能的少，调试的可能性也达到最小。

也许你的测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中揭示。

这种情况下，你需要一个低内务操作工具来监听和寻找内存泄漏。

同时，你还需要把这个工具同你的系统联系起来，而不需要重新启动他或者机械化你的代码。

也许更重要的是，当你做分析的时候，你需要能够同工具分离而使得系统不会受到干扰。

一个OutOfMemoryError常常是内存泄漏的一个标志，有可能应用程序的确用了太多的内存；这个时候，你既不能增加JVM的堆的数量，也不能改变你的程序而使得他减少内存使用。

但是，在大多数情况下，一个OutOfMemoryError 是内存泄漏的标志。

一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，如果有，程序中一定存在内存泄漏。

详细输出有很多办法来监听垃圾回收器的活动。

也许运用最广泛的就是以：-Xverbose:gc选项运行JVM，然后观察输出结果一段时间。

[memory] 10.109-10.235: GC 65536K->16788K (65536K), 126.000 ms箭头后的值（在这个例子中 16788K）是垃圾回收后堆的使用量。

控制台观察这些无尽的GC详细统计输出是一件非常单调乏味的事情。

好在有一些工具来代替我们做这些事情。

The JRockit Management Console可以用图形的方式输出堆的使用量。

通过观察图像，我们可以很方便的观察堆的使用量是否伴随时间增长。

Figure 1. The JRockit Management Console管理控制台甚至可以配置成在堆使用量出现问题（或者其他的事件发生）时向你发送邮件。

这个显然使得监控内存泄漏更加容易。

内存泄漏探测工具有很多专门的内存泄漏探测工具。

其中The JRockit Memory Leak Detector可以供来观察内存泄漏也可以针对性地找到泄漏的原因。

这个强大的工具被紧密地集成在JRockit JVM中，可以提供最低可能的内存事务也可以轻松的访问虚拟机的堆。

专门工具的优势一旦你知道程序中存在内存泄漏，你需要更专业的工具来查明为什么这里会有泄漏。

而JVM是不可能告诉你的。

现在有很多工具可以利用了。

这些工具本质上主要通过两种方法来得到JVM的存储系统信息的：JVMTI和字节码使用仪器。

Java虚拟机工具接口（JVMTI）和他的原有形式JVMPI（压型接口）都是标准接口，作为外部工具同JVM进行通信，搜集JVM的信息。

字节码使用仪器则是引用通过探针获得工具所需的字节信息的预处理技术。

通过这些技术来侦测内存泄漏存在两个缺点，而这使得他们在产品级环境中的运用不够理想。

首先，根据两者对内存的使用量和内存事务性能的降级是不可以忽略的。

从JVM获得的堆的使用量信息需要在工具中导出，收集和处理。

这意味着要分配内存。

按照JVM的性能导出信息是需要开销的，垃圾回收器在搜集信息的时候是运行的非常缓慢的。

另一个缺点就是，这些工具所需要的信息是关系到JVM的。

让工具在JVM开始运行的时候和它关联，而在分析的时候，分离工具而保持JVM运行，这显然是不可能的。

既然JRockit Memory Leak Detector是被集成到JVM中的，那么以上两种缺点就不再适用。

首先，大部分的处理和分析都是在JVM中完成的，所以就不再需要传送或重建任何数据。

处理也可以在垃圾回收器的背上，他的意思是提高速度。

再有，内存泄漏侦测器可以同一个运行的JVM关联和分离，只要JVM在开始的时候伴随着 -Xmanagement选项（这个允许监听和管理JVM通过远程JMX接口）。

当工具分离以后，工具不会遗留任何东西在JVM中；JVM就可以全速运行代码就好像工具关联之前一样。

趋势分析让我们更深一步来观察这个工具，了解他如何捕捉到内存泄漏。

在你了解到代码中存在内存泄漏，第一步就是尝试计算出什么数据在泄漏--哪个对象类导致泄露。

The JRockit Memory Leak Detector通过在垃圾回收的时候，计算每个类所包含的现有的对象来达到目的。

如果某一个类的对象成员数目随着时间增长（增长率），那么这里很可能存在泄漏。

Figure 2. The trend analysis view of the Memory Leak Detector因为一个泄漏很可能只是像水滴一样小，所以趋势分析必须运行足够长的一段时间。

在每个短暂的时间段里，局部类的增加会使得泄漏发生推迟。

但是，内存事务是非常小的（最大的内存事务是由在每个垃圾回收时从JRockit向内存泄漏探测器发送的一个数据包组成的）。

内存事务不应该成为任何系统的问题--甚至一个在产品阶段全速运行的程序。

一开始，数字会有很大的跳转，随时间的推进，这些数字会变得稳定，而后显示哪些类会不断的增大。