原文：Hunting Memory Leaks in Java

捕获Java内存泄露 （一）

经验不足的程序员往往认为java的自动垃圾收集让他们完全不必操心内存管理。这是一个普遍的误解：即使垃圾回收器做到最棒的程度，依然完全有可能让哪怕最好的程序员受到严重的内存泄漏的伤害。下面让我解释。

当不再被需要的对象引用被不必要地保持时，会出现内存泄漏.。这些内存泄露是糟糕的。一方面，你的程序消耗越来越多的资源，导致它们会给你的机器带来不必要的压力。更糟糕的是，想检测这些漏洞可能很困难：静态分析要准确地识别这些冗余的引用常常步履维艰，并且永现有的泄漏检测工具跟踪和报告单个对象的细粒度信息，产生的结果很难理解且缺乏精度。

换句话说，内存泄漏要么太难识别，要么被识别得过于具体而不实用。

实际上有四类内存问题有相似和重叠的症状，但原因和解决方案各异：

• 性能 ：通常与过多的对象创建和删除，垃圾收集的长时间延迟，过度的操作系统页交换，等等相关联。
• 资源约束 ：出现在当你的内存太少或内存碎片太多以至于无法分配给一个大对象——这可以是本地对象，更常见的是，java堆相关。
• java堆泄漏 ：经典的内存泄露，即java对象不断创造而不被释放。这通常是由潜在对象引用引起的。
• 本地内存泄漏 ：与java堆之外的任何不断增长的内存使用有关，如通过JNI代码、驱动器、甚至由JVM分配。

在本文中，我将着重于java堆泄漏并勾勒出一种方法来检测内存泄漏，它是基于Java VisualVM报告和利用可视化界面来分析正在运行的基于java技术的应用。

但在你能够预防和追查内存泄漏之前，你应该理解它们是如何发生的，以及它们为什么发生的。（注：如果你已经可以处理错综复杂的内存泄露问题，你可以直接跳过。）

内存泄露：入门

对初学者，请把内存泄漏看作一种疾病而java的OutOfMemoryError（OOM，简称）看作一种症状。但正如任何疾病，不是所有的OOMs都意味着内存泄漏：一个OOM可能是由于生成大量局部变量或其他类似事件发生而引起的。另一方面，并不是所有的内存泄漏必然表现为OOMs，尤其是就桌面应用程序或客户端应用程序来说（都是不会运行很长时间不重启）。

把记忆泄漏看作疾病而OutOfMemoryError看作症状。但并不是所有的OutOfMemoryError意味着内存泄漏，也不是所有的内存泄漏都表现为OutOfMemoryError。

为什么这些泄漏这么有害？别的不说，随着时间的推移，泄漏的内存块在程序执行过程中，往往会降低系统的性能，因为一旦系统缺少足够的空闲物理内存，已分配但未使用的内存块将必须被换出。最终，一个程序可能耗尽其可用的虚拟地址空间，导致OOM。

下一篇：捕获Java内存泄露 （二）

---