首页 > 初步判断内存泄漏方法

初步判断内存泄漏方法

有时候,内存泄漏不明显,或者怀疑系统有内存泄漏,我们可以通过下面介绍的方法初步确认系统是否存在内存泄漏。
首先在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信息分析只能告诉你系统是否存在堆内存泄漏,但具体哪里泄漏,它是无法告诉你的。 存泄漏的的精确定位,是要找到内存泄漏的具体位置,需要借助如下工具/手段之一可以找 真正导致内存泄漏的类或者对象。 

转载于:https://www.cnblogs.com/wx170119/p/11316880.html

更多相关:

  • 更多内容,欢迎关注微信公众号:全菜工程师小辉~前言在笔者上一篇博客,详解了NIO,并总结NIO相比BIO的效率要高的三个原因,彻底搞懂NIO效率高的原理。这篇博客将针对第三个原因,进行更详细的讲解。首先澄清,零拷贝与内存直接映射并不是Java中独有的概念,并且这两个技术并不是等价的。零拷贝零拷贝是指避免在用户态(User-space)...

  • 一、预备知识—程序的内存分配  一个由c/C++编译的程序占用的内存分为以下几个部分  1、栈区(stack)— 由编译器自动分配释放 ,存放函数的参数值,局部变量的值等。其操作方式类似于数据结构中的栈,如果还不清楚,那么就把它想成数组,它的内存分配是连续分配的,即,所分配的内存是在一块连续的内存区域内.当我们声明变量时,那么编译器...

  • 我的爱机是一台ThinkPad T420,原装三星DDR 1333 4G内存一根,还剩一根内存位置,最近趁京东6.18促销,准备增加一根物理内存。为了确保兼容性,觉得仍然选购DDR 1333 4G内存,于是购买了金士顿这款,比如DDR3 1600的还贵。 这个安装过程完全参照该内存的网页提示进行 这里简单记录一下,以备...

  • 陪伴我多年的老本ThinkPad T420渐渐垂垂老矣, 我想更新一下可以更新的部分, 比如将2.5寸HDD更换为SSD, 将单条4G内存再增加一根, 凡此种种想法, 可能最后归结为如何获取该笔记本的硬件配置信息, 在windows下面使用鲁大师之类的检测软件, 也许很好搞定,但是在Ubuntu 14.04平台上如果办到呢? 很简单...

  • 一.内存错误出现的场景 这几天在重构ATS插件代码的过程中遇到了烦人的内存泄露问题, 周五周六连续两天通过走查代码的方法,未能看出明显的导致内存错误的代码, 同时也觉得C和C++混合编程得到一个动态库, 在一个.cpp主文件中,即用new又用malloc来动态分配内存, 可能会导致内存错误.后来网上调研和查资料发现, new和mal...

  • 前言 还是回到传统的 LSM-tree 中,我们key-value 写入时以append形态存放到一个data-block中,多个data-block+metablock 之类的数据组织成一个sst。当我们读数据以及compaction的时候读到key 之后则很方便得读取到对应的value,一次I/O能够将key-value完全从磁...

  • 文章目录1. 为什么要有GC2. GC的触发条件3. GC的核心逻辑1. blob file形态2. GC Prepare3. GC pick file4. GC run4. GC 引入的问题5. Titan的测试代码...

  • 【BZOJ4282】慎二的随机数列 Description 间桐慎二是间桐家著名的废柴,有一天,他在学校随机了一组随机数列, 准备使用他那强大的人工智能求出其最长上升子序列,但是天有不测风云,人有旦夕祸福,柳洞一成路过时把间桐慎二的水杯打翻了…… 现在给你一个长度为 n 的整数序列,其中有一些数已经模糊不清了,现在请你任意确定这些整...

  • CrashReport系统在游戏内测当天出现了异常情况JVM僵死,通过top -p -H 结合jstack(jstack -m -l pid)查看,发现是VM Thread线程CPU占用100%,线程ID好为18540,线程信息如下:----------------- 18540 -----------------0xb...