图 14 显示该应用程序的堆使用情况。堆使用中的骤降标记了对堆进行压缩的点。当 JVM 内存不足时 ，日志结束。

图 14. 泄露严重的应用程序的堆使用情况

使用弱引用来避免泄露

切换到 WeakHashMap，如清单 2 所示，立即更正该问题；新的改进的堆使用情况如图 15 所示。堆使 用从不会超过 1MB，并且应用程序可以继续保持不确定地运行。

清单 2. 对防止内存泄露的 Leaker 类的简单更正

　private　Map　things　=　new　WeakHashMap();　

图 15. 使用 WeakHashMap 修复可能存在泄露的应用程序

IBM的Java诊断，第2部分(10)

但是，弱引用可能不足以更正某些泄露。如果图 15 中的映射是链接的列表，如清单 3 所示，那会发 生什么情况呢？

清单 3. 对再次引用泄露的 Leaker 类的进一步修改

public　class　Leaker { 　 private　Map　things　=　new　WeakHashMap(); 　 public　void　leak()　{ 　 Object　previousThing　=　null; 　 while　(true)　{ 　　 final　Leak　thing　=　new　Leak(previousThing); 　　 things.put(new　Date(),　thing); 　　 previousThing　=　thing; 　 } 　 } 　 private　class　Leak 　 { 　 private　Object　data; 　 public　Leak(Object　thing)　{ 　　 /*　Make　a　linked　list　*/ 　　 data　=　thing; 　 } 　 } }

弱引用告诉垃圾收集器如果某个对象除了弱引用之外没有其他任何引用，则应该收集该对象。由于映 射中的每个对象都持有一个对以前的对象的引用，因此将不会清除任何弱引用并且应用程序将快速消耗完 内存，如图 16 所示：

图 16. 无法使用 WeakHashMap 修复的内存泄露应用程序中的堆使用

IBM的Java诊断，第2部分(11)

确保弱引用如期工作

通过在 EVTK 中绘制被清除的弱引用的图，可以证实该问题，如图 17 所示。向列表中添加链接之后 ，被清除的弱引用的数量将从较大的数更改为完全没有。（修改后的应用程序沿着 X 轴零点的线条非常 短，而以前的应用程序的线条则又长又高。）很明显，弱引用不再起作用。

图 17. 对可能存在内存泄露的应用程序的两个变体清除弱引用

在这种情况下，解决办法就是也将链接列表中的链接更改为弱引用。执行如清单 4 中所示的代码更改 之后，弱应用的数量大大增加了，而且堆使用也返回到最小值：

清单 4. 引进更多弱引用将防止对引用的持有超过必需的时间

private　class　Leak { 　 private　WeakReference　reference; 　 public　Leak(Object　thing)　{ 　 this.reference　=　new　WeakReference(thing); 　 /* 　　　　　 *　We　can　get　back　our　object　from　the　reference　with 　　　　　 *　reference.get(),　but　we　should　always　check　it　for　null. 　　　　　 */ 　 } }

通过使用 EVTK 查看被清除的弱引用的数量，您可以轻松验证对使用弱引用的重新设计是否切实有效 。

如果代码检测没有快速找到泄露，则您可能需要执行一些应用程序转储并分析它们以找到引用增加了 的对象。

详细 GC 日志还可以帮助评估应用程序的可伸缩性。例如，如果应用程序的目的是要处理大量数据， 但当测试期间处理少量数据时，该应用程序却使用非常多的内存，则该应用程序未能按预期进行伸缩。

IBM的Java诊断，第2部分(12)

案例研究：调整堆的大小

很多开发人员都使用详细 GC 数据来帮助选择堆的最佳大小。如果堆太小以至于无法容纳应用程序所 需的数据，则该应用程序将消耗完内存并且使用 OutOfMemoryError 终止。如果堆具有应用程序数据的空 间，但没有大量

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!