[转帖]周末技术专题巨献：内存泄漏，走开！（1）

kampoo

<CENTER>第 <B>1</B> <a href="http://www.itzero.net/Article/J2EE/2005_10/3740_2.html" target="_blank" >2</A> 页  <a href="http://www.itzero.net/Article/J2EE/2005_10/3740_2.html" target="_blank" >下一页</A></CENTER><br>抽象<br><br>      尽管Java虚拟机和垃圾回收机制管理着大部分的内存事务，但是在Java软件中还是可能存在内存泄漏的情况。的确，在大型工程中，内存泄漏是一个普遍问题。避免内存泄漏的第一步，就是要了解他们发生的原因。<br><br>     这篇文章就是要介绍一些常见的缺陷，然后提供一些非常好的实践例子来指导你写出没有内存泄漏的代码。一旦你的程序存在内存泄漏，要查明代码中引起泄漏的原因是很困难的。<br><br>同时这篇文章也要介绍一个新的工具来查找内存泄漏，然后指明发生的根本原因。这个工具容易上手，可以让你找到产品级系统中的内存泄漏。<br><br>垃圾回收（GC）的角色<br><br>     虽然垃圾回收关心着大部分的问题，包括内存管理，使得程序员的任务显得更加轻松，但是程序员还是可能犯些错误导致内存泄漏问题。<br><br>GC(垃圾回收)通过递归对所有从“根”对象(堆栈中的对象，静态数据成员，JNI句柄等等)继承下来的引用进行工作，然后标记所有可以访问的活着的对象。而这些对象变成了程序唯一能够操纵的对象，其他的对象都被释放了。因为GC使得程序不能够访问那些被释放的对象，所以这样做是安全的。<br><br>内存管理可以说是自动的，但是这并没有让程序员脱离内存管理问题。比方说，对于内存的分配（还有释放）总是存在一定的开销，尽管这些开销对程序员来说是暗含的。一个程序如果创建了很多对象，那么它就要比完成相同任务而创建了较少对象的程序执行的速度慢（其他提供的内容都相同）。<br><br>文章更多想说的，导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器验证这些对象是否不再需要。<br><br>正如我们前面看到的，如果存在对象的引用，这个对象就被定义为“活着的”，同时不会被释放。要确定对象所占内存将被回收，程序员就要务必确认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。注意，当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。<br><br>从更高一个层次看，这就是所有存在内存管的语言对内存泄漏所考虑的事情，剩余的对象引用将不再会被使用。<br>典型泄漏<br><br>既然我们知道了在Java中确实会存在内存泄漏，那么就让我们看一些典型的泄漏，并找出他们发生的原因。<br><br>全局集合<br><br>在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。在这些情况下，注意力就被放在了管理数据仓库的大小上。当然是有一些适当的机制可以将仓库中的无用数据移除。<br><br>可以有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。这个作业会验证仓库中的数据然后清除一切不需要的数据。<br><br>另一个办法是使用引用计算。集合用来对了解每个集合入口关联器（referrer）的数目负责。这要求关联器通知集合什么时候完成进入。当关联器的数目为零时，就可以移除集合中的相关元素。<br><br>高速缓存<br><br>高速缓存是一种用来快速查找已经执行过的操作结果的数据结构。因此，如果一个操作执行很慢的话，你可以先把普通输入的数据放入高速缓存，然后过些时间再调用高速缓存中的数据。<br><br>高速缓存多少还有一点动态实现的意思，当数据操作完毕，又被送入高速缓存。一个典型的算法如下所示：<br><br>１．检查结果是否在高速缓存中，存在则返回结果；<br><br>２．如果结果不在，那么计算结果；<br><br>３．将结果放入高速缓存，以备将来的操作调用。<br><br>这个算法的问题（或者说潜在的内存泄漏）在最后一步。如果操作伴随着一个不同的，输入非常大的数字，那么存入高速缓存的也是一个非常大的结果。那么这个方法就不是能够胜任的了。<br><br>为了避免这种潜在的致命错误设计，程序就必须确定高速缓存在他所使用的内存中有一个上界。因此，更好的算法是：<br><br>１．检查结果是否在高速缓存中，存在则返回结果；<br><br>２．如果结果不在，那么计算结果；<br><br>３．如果高速缓存所占空间过大，移除缓存中旧的结果；<br><br>４．将结果放入高速缓存，以备将来的操作调用。<br>通过不断的从缓存中移除旧的结果，我们可以假设，将来，最新输入的数据可能被重用的几率要远远大于旧的结果。这通常是一个不错的设想。<br><br>这个新的算法会确保高速缓存的容量在预先确定的范围内。精确的范围是很难计算的，因为缓存中的对象存在引用时将继续有效。正确的划分高速缓存的大小是一个复杂的任务，你必须权衡可使用内存大小和数据快速存取之间的矛盾。<br><br>另一个解决这个问题的途径是使用Java.lang.ref.SoftReference类坚持将对象放入高速缓存。这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。<br><br>类装载器<br><br>Java类装载器创建就存在很多导致内存泄漏的漏洞。由于类装载器的复杂结构，使得很难得到内存泄漏的透视图。这些困难不仅仅是由于类装载器只与“普通的”对象引用有关，同时也和对象内部的引用有关，比如数据变量，方法和各种类。<br><br>这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器将驻留在JVM中。既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。<br><br>定位内存泄漏<br><br>常常地，程序内存泄漏的最初迹象发生在出错之后，得到一个OutOfMemoryError在你的程序中。这种典型地情况发生在产品环境中，而在那里，你希望内存泄漏尽可能的少，调试的可能性也达到最小。<br><br>也许你的测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中揭示。这种情况下，你需要一个低内务操作工具来监听和寻找内存泄漏。同时，你还需要把这个工具同你的系统联系起来，而不需要重新启动他或者机械化你的代码。也许更重要的是，当你做分析的时候，你需要能够同工具分离而使得系统不会受到干扰。<br><br>一个OutOfMemoryError常常是内存泄漏的一个标志，有可能应用程序的确用了太多的内存；这个时候，你既不能增加JVM的堆的数量，也不能改变你的程序而使得他减少内存使用。<br><br>但是，在大多数情况下，一个OutOfMemoryError是内存泄漏的标志。一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，如果有，程序中一定存在内存泄漏。<br><br>详细输出<br><br>有很多办法来监听垃圾回收器的活动。也许运用最广泛的就是以：-Xverbose:gc选项运行JVM，然后观察输出结果一段时间。<br><br>
<CENTER><CCID_NOBR>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>

9 x3 b# I, s! l/ b! U<TR>
<TD class=code style="FONT-SIZE: 9pt" bgColor=#e6e6e6><RE><CCID_CODE>[memory] 10.109-10.235: GC 65536K-&gt;16788K (65536K), 126.000 ms</CCID_CODE></PRE></TD></TR></TABLE></CENTER>
<><STRONG><br><br>
! @1 T$ l/ z: d. c<CENTER>第 <B>1</B> <a href="http://www.itzero.net/Article/J2EE/2005_10/3740_2.html" target="_blank" >2</A> 页  <a href="http://www.itzero.net/Article/J2EE/2005_10/3740_2.html" target="_blank" >下一页</A></CENTER></STRONG>
( S* ?8 f* v8 q* E

[此贴子已经被作者于2005-12-29 18:51:42编辑过]