初步判断内存泄漏方法

Posted 2022-06-17 wx170119

有时候，内存泄漏不明显，或者怀疑系统有内存泄漏，我们可以通过下面介绍的方法初步确认系统是否存在内存泄漏。

首先在Java命令行中增加-verbose:gc参数，

然后重新启动java进程。

当系统运行过程中,JVM进行垃圾回收的时候，会将垃圾回收的日志打印出来，通过分析

这些GC日志，我们可以初步判断系统是否存在堆内存泄漏，

8190.813: [GC 164675K->251016K(1277056K), 0.0117749 secs]

8190.825: [Full GC 251016K->164654K(1277056K), 0.8142190 secs]

8191.644: [GC 164678K->251214K(1277248K), 0.0123627 secs]

8191.657: [Full GC 251214K->164661K(1277248K), 0.8135393 secs]

8192.478: [GC 164700K->251285K(1277376K), 0.0130357 secs]

8192.491: [Full GC 251285K->164670K(1277376K), 0.8118171 secs]

8193.311: [GC 164726K->251182K(1277568K), 0.0121369 secs]

8193.323 : [Full GC 251182K->164644K(1277568K), 0.8186925 secs]

8194.156: [GC 164766K->251028K(1277760K), 0.0123415 secs]

8194.169: [Full GC 251028K->164660K(1277760K), 0.8144430 secs]

在这段GC输出中，每一项的含义如下：

 

 我们知道，Java虚拟机的垃圾回收有两种类型： 通GC 在GC信息的输出中，[GC 164726K->251182K(1277568K), 0.0121369 secs]中的"GC"就 代表的普通GC,普通GC只回收部分垃圾对象，因此回收完毕后，系统中仍存在大量的垃 圾对象 全GC 即FULL GC,在GC信息的输出中，[Full GC 251285K->164670K(1277376K), 0.8118171secs]的"FULL GC"就代表的完全GC,完全GC，系统彻底的对垃圾对象进行回收，回收完 毕后，垃圾对象所占用的内存得到彻底的回收，此时系统中存在的对象都是真正在使用 的活动对象，这时候的Java内存真实地反映了Java对象所占用的内存的大小。 在分析系统是否存在内存泄漏时，我们关注的是在当时真正有用的对象所占用的内存的 小。如果随着系统的运行，真正的Java对象所占用的内存越来越大，那么基本上能够确认存在内存泄漏（此时要排除系统是否设计了大量的缓存）。因此在做内存泄漏的分析时，我 只需要分析Full GC的行(非完全垃圾回收，由于并没有将所有的垃圾都回收，因此对我们的 析没有价值)。

以下面的例子为例进行说明：

 

• 251285K 完全垃圾回收之前Java对象占用的内存大小，这个值包含两部分，一部分是正在 使用的Java对象占用的空间，另一部分是垃圾对象占用的空间。JAVA内存泄漏分析和堆内存设置 73

• 164670K 完全垃圾回收之后Java对象占用的内存大小，这个值是真正的活动Java对象占用 的内存。

• 1277376K 堆的设置最大值。

• 0.8118171 secs 表示本次完全垃圾回收占用的时间。

    判断系统是否存在内存泄漏的依据是：如果系统存在内存泄漏，那么完全垃圾回收完之 的内存值应该持续上升。如果在现场能观察到这个现象，说明系统存在内存泄漏当怀疑 个系统存在内存泄漏的时候，首先使用FULL GC信息对内存泄漏进行一个初步确认，确认统是否存在内存泄漏。只检查完全垃圾回收后的可用内存值是否一直再增大，步骤如下31：. 首先截取系统稳定运行以后的GC信息（如初始化已经完成），这个非常重要，非稳定运行 期的信息无分析价值，因为你无法确认内存的增长是正常的增长还是由于内存泄漏导致 的非正常增长。. 过滤出FULL GC的行。只有FULL GC的行才有分析价值。因为完全GC后的内存是当 前Java对象真正使用的内存数量。一般系统会有两种可能：

(a) 如果完全垃圾回收后的内存持续增长32，大有一直增长到Xmx设定值的趋势，那么这 个时候基本上就可以断定系统存在内存泄漏。

(b) 如果当前完全垃圾回收后内存增长到一个值之后，又能回落，总体上处于一个动态 平衡，那么内存泄漏基本可以排除。 通过如上内存使用趋势分析之后，基本上就能确定系统是否存在堆内存泄漏。

当然这 GC信息分析只能告诉你系统是否存在堆内存泄漏，但具体哪里泄漏，它是无法告诉你的。 存泄漏的的精确定位，是要找到内存泄漏的具体位置，需要借助如下工具/手段之一可以找 真正导致内存泄漏的类或者对象。