初步判断内存泄漏
有时候,内存泄漏不明显,或者怀疑系统有内存泄漏,我们可以通过下面介绍的方法初步确认系统是否存在内存泄漏。
首先在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输出中,每一项的含义如下:
![](https://img2018.cnblogs.com/blog/1360293/201908/1360293-20190807175854989-533026747.png)
我们知道,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的行(非完全垃圾回收,由于并没有将所有的垃圾都回收,因此对我们的 析没有价值)。
以下面的例子为例进行说明:
![](https://img2018.cnblogs.com/blog/1360293/201908/1360293-20190807180024036-1146075353.png)
• 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信息分析只能告诉你系统是否存在堆内存泄漏,但具体哪里泄漏,它是无法告诉你的。 存泄漏的的精确定位,是要找到内存泄漏的具体位置,需要借助如下工具/手段之一可以找 真正导致内存泄漏的类或者对象。