如何排查Java内存泄漏？看完我给跪了！
150 浏览量
2021-01-20
12:05:58
上传
评论
收藏 553KB PDF 举报
如何排查如何排查Java内存泄漏？看完我给跪了！内存泄漏？看完我给跪了！
没有经验的程序员经常认为Java的自动垃圾回收完全使他们免于担心内存管理。这是一个常见的误解：虽然垃圾收集器做得很好，但即使是最好的程序员也完全有可能成为严重破坏内存泄漏的牺牲品。
让我解释一下。
当不必要地维护不再需要的对象引用时，会发生内存泄漏。这些泄漏很糟糕。首先，当程序消耗越来越多的资源时，它们会对计算机施加不必要的压力。更糟糕的是，检测这些泄漏可能很困难：静态分
析通常很难精确识别这些冗余引用，现有的泄漏检测工具会跟踪和报告有关单个对象的细粒度信息，产生难以解释且缺乏精确度的结果。
换句话说，泄漏要么太难以识别，要么使用太过具体而无用术语来识别。
实际上有四类内存问题具有相似和重叠的特征，但原因和解决方案各不相同：
Performance(性能):通常与过多的对象创建和删除，垃圾收集的长时间延迟，过多的操作系统页面交换等相关联。
Resource constraints(资源约束)：当可用内存很少或内存过于分散而无法分配大对象时 – 这可能是本机的，或者更常见的是与Java堆相关。
Java heap leaks(java堆泄漏):经典的内存泄漏，Java对象在不释放的情况下不断创建。这通常是由潜在对象引用引起的。
Native memory leaks(本机内存泄漏):与Java堆之外的任何不断增长的内存利用率相关联，例如由JNI代码，驱动程序甚至JVM分配。
在这个内存管理教程中，我将专注于Java堆漏洞，并概述一种基于Java VisualVM报告检测此类泄漏的方法，并利用可视化界面在运行时分析基于Java技术的应用程序。
但在您可以预防和发现内存泄漏之前，您应该了解它们的发生方式和原因。（注意：如果你能很好地处理错综复杂的内存泄漏，你可以跳过。）
1. 内存泄漏：基础内存泄漏：基础
对于初学者来说，将内存泄漏视为一种疾病，将Java的OutOfMemoryError（简称OOM）视为一种症状。但与任何疾病一样，并非所有OOM都意味着内存泄漏：由于生成大量局部变量或其他此类事
件，OOM可能会发生。另一方面，并非所有内存泄漏都必然表现为OOM，特别是在桌面应用程序或客户端应用程序（没有重新启动时运行很长时间）的情况下。
将内存泄漏视为疾病，将OutOfMemoryError视为症状。但并非所有OutOfMemoryErrors都意味着内存泄漏，并非所有内存泄漏都表现为OutOfMemoryErrors。
为什么这些泄漏如此糟糕？除此之外，程序执行期间泄漏的内存块通常会降低系统性能，因为分配但未使用的内存块必须在系统耗尽空闲物理内存时进行换出。最终，程序甚至可能耗尽其可用的虚拟地
址空间，从而导致OOM。
2. 解密解密OutOfMemoryError
如上所述，OOM是内存泄漏的常见指示。实质上，当没有足够的空间来分配新对象时，会抛出错误。当垃圾收集器找不到必要的空间，并且堆不能进一步扩展，会多次尝试。因此，会出现错误以及堆栈
跟踪。
诊断OOM的第一步是确定错误的实际含义。这听起来很清楚，但答案并不总是那么清晰。例如：OOM是否是因为Java堆已满而出现，还是因为本机堆已满？为了帮助您回答这个问题，让我们分析一些
可能的错误消息：
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
java.lang.OutOfMemoryError: request bytes for . Out of swap space?
java.lang.OutOfMemoryError: (Native method)
2.1.“Java heap space”
此错误消息不一定意味着内存泄漏。实际上，问题可能与配置问题一样简单。
例如，我负责分析一直产生这种类型的OutOfMemoryError的应用程序。经过一番调查后，我发现罪魁祸首是阵列实例化，因为需要太多的内存;在这种情况下，并不是应用程序的错，而是应用程序服务
器依赖于默认的堆太小了。我通过调整JVM的内存参数解决了这个问题。
在其他情况下，特别是对于长期存在的应用程序，该消息可能表明我们无意中持有对象的引用，从而阻止垃圾收集器清理它们。这时Java语言等同于内存泄漏。（注意：应用程序调用的API也可能无意
中持有对象引用。）
这些“Java堆空间”OOM的另一个潜在来源是使用finalizers。如果类具有finalize方法，则在垃圾收集时该类型的对象不会被回收。而是在垃圾收集之后，稍后对象将排队等待最终确定。在Sun实现
中，finalizers由守护线程执行。如果finalizers线程无法跟上finalization队列，那么Java堆可能会填满并且可能抛出OOM。
2.2. “PermGen space”
此错误消息表明永久代已满。永久代是存储类和方法对象的堆的区域。如果应用程序加载了大量类，则可能需要使用-XX：MaxPermSize选项增加永久代的大小。
Interned java.lang.String对象也存储在永久代中。java.lang.String类维护一个字符串池。调用实习方法时，该方法检查池以查看是否存在等效字符串。如果是这样，它由实习方法返回;如果没有，则将字
符串添加到池中。更准确地说，java.lang.String.intern方法返回一个字符串的规范表示;结果是对该字符串显示为文字时将返回的同一个类实例的引用。如果应用程序实例化大量字符串，则可能需要增加
永久代的大小。
注意：您可以使用jmap -permgen命令打印与永久生成相关的统计信息，包括有关内部化String实例的信息。
2.3.“Requested array size exceeds VM limit”
此错误表示应用程序（或该应用程序使用的API）尝试分配大于堆大小的数组。例如，如果应用程序尝试分配512MB的数组但最大堆大小为256MB，则将抛出此错误消息的OOM。在大多数情况下，问题
是配置问题或应用程序尝试分配海量数组时导致的错误。
2.4. “Request bytes for . Out of swap space?”
此消息似乎是一个OOM。但是，当本机堆的分配失败并且本机堆可能将被耗尽时，HotSpot VM会抛出此异常。消息中包括失败请求的大小（以字节为单位）以及内存请求的原因。在大多数情况下，是
报告分配失败的源模块的名称。
如果抛出此类型的OOM，则可能需要在操作系统上使用故障排除实用程序来进一步诊断问题。在某些情况下，问题甚至可能与应用程序无关。例如，您可能会在以下情况下看到此错误：
操作系统配置的交换空间不足。
系统上的另一个进程是消耗所有可用的内存资源。
由于本机泄漏，应用程序也可能失败（例如，如果某些应用程序或库代码不断分配内存但无法将其释放到操作系统）。
2.5. Native method
如果您看到此错误消息并且堆栈跟踪的顶部框架是本机方法，则该本机方法遇到分配失败。此消息与上一个消息之间的区别在于，在JNI或本机方法中检测到Java内存分配失败，而不是在Java VM代码中
检测到。
如果抛出此类型的OOM，您可能需要在操作系统上使用实用程序来进一步诊断问题。
2.6. Application Crash Without OOM
有时，应用程序可能会在从本机堆分配失败后很快崩溃。如果您运行的本机代码不检查内存分配函数返回的错误，则会发生这种情况。
例如，如果没有可用内存，malloc系统调用将返回NULL。如果未检查malloc的返回，则应用程序在尝试访问无效的内存位置时可能会崩溃。根据具体情况，可能很难定位此类问题。
在某些情况下，致命错误日志或崩溃转储的信息就足以诊断问题。如果确定崩溃的原因是某些内存分配中缺少错误处理，那么您必须找到所述分配失败的原因。与任何其他本机堆问题一样，系统可能配
置了但交换空间不足，另一个进程可能正在消耗所有可用内存资源等。
3. 泄漏诊断泄漏诊断
在大多数情况下，诊断内存泄漏需要非常详细地了解相关应用程序。警告：该过程可能很长并且是迭代的。
我们寻找内存泄漏的策略将相对简单：
识别症状
评论0
最新资源