> 文章列表 > Memory Analyzer Mat

Memory Analyzer Mat

Memory Analyzer Mat

目录

一、JDK 、JRE和JVM 的关系

二、Java进程内存占用查询命令

2.1JAVA 代码是如何执行的

2.2何时用hrpof文件分析内存

三、Memory Analyzer Mat

3.1Memory Analyzer Mat安装

3.2 Overview视图

3.2.1直方图视图(histogram)

3.2.2 Dominator Tree

3.2.3 Top Consumers

3.3 Leak Suspects

3.3.1 Overview

3.3.2 Problem Suspect

3.3.3 Problem Suspect 1

3.3.4 Problem Suspect 2


一、JDK 、JRE和JVM 的关系



二、Java进程内存占用查询命令


2.1JAVA 代码是如何执行的

2.2何时用hrpof文件分析内存

其实如果只是要了解JVM的运行状况,然后去进行JVM GC优化,通常来说jstat就完全够用了。但是有的时候可能我们会发现JVM新增对象的速度很快,然后就想要去看看,到底什么对象占据了那么多的内存。

如果发现有的对象在代码中可以优化一下创建的时机,避免那种对象对内存占用过大,那么也许可以去反过来优化一下代码。当然,其实如果不是出现OOM那种极端情况,也并没有那么大的必要去着急优化代码。

我们通过如下可以 大致连接JVM 内存的状态,老年代和新生代使用情况。

jmap -heap 11469
jstat -gc 11469  5000

但是如果你仅仅只是看一个大概,感觉就只是看看上述那些对象占用内存的情况,感觉还不够,想要来点深入而且仔细点的那就可以用jmap命令生成一个堆内存快照放到一个文件里去,用如下的命令即可:

jmap -dump:live,format=b,file=dump.hprof PID

这个命令会在当前目录下生成一个dump.hrpof文件,这里是二进制的格式,你不能直接打开看的,其把这一时刻JVM堆内存里所有对象的快照放到文件里去了,供你后续去分析。


三、Memory Analyzer Mat


3.1Memory Analyzer Mat安装

Memory Analyzer Mat下载地址:Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

关于 HeapDumpOnOutOfMemoryError 参数讲解:

-XX:+HeapDumpOnOutOfMemoryError 参数表示当JVM发生OOM时,自动生成DUMP文件。
-XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径,也可以指定文件名称,例如:-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名,默认会在项目根目录下生成一个文件,文件名格式为:java_<pid>_<date>_<time>_heapDump.hprof。
-XX:+HeapDumpBeforeFullGC		当 JVM 执行 FullGC前
-XX:+HeapDumpAfterFullGC		当 JVM 执行 FullGC后

因为程序存在OOM 问题所以我主动 dump

## 7150 进程号
jmap -dump:live,format=b,file=/hadoop/ops/ftpDS.hprof  7150

可以看到 生成的 hprof 的文件还是比较大的 达到了 1.6G。

3.2 Overview视图

将dump下来的hprof文件打开,视图首页总结出当前这个Heap dump占用了多大的内存,其中涉及的类有多少,对象有多少,类加载器,如果有没有回收的对象,会有一个连接,可以直接参看(图中的Unreachable Objects Histogram)。 比如该例子中显示了Size: 979 MB Classes: 4.2k Objects: 26.1m Class Loader: 46

3.2.1直方图视图(histogram)

histogram视图主要是查看某个类的实例个数,比如我们在检查内存泄漏时候,要判断是否频繁创建了对象,就可以来看对象的个数来看。也可以通过排序看出占用内存大的对象。

3.2.2 Dominator Tree

列举出Retained Size值最大的几个值,你可以将鼠标放到饼图中的扇叶上,可以在右侧看出详细信息:

3.2.3 Top Consumers

1.Biggest Objects (Overview)

2 Biggest Objects

3 Biggest Top-Level Dominator Classes (Overview)

4 Biggest Top-Level Dominator Classes

5 Biggest Top-Level Dominator Class Loaders (Overview)

6 Biggest Top-Level Dominator Packages

3.3 Leak Suspects

3.3.1 Overview

3.3.2 Problem Suspect

这个视图会展示一些可能的内存泄漏的点,比如上图上图显示有2个内存泄漏可疑点。

3.3.3 Problem Suspect 1

"org.apache.hadoop.fs.FileSystem$Cache"”的一个实例文件系统被"sun.misc.Launcher$AppClassLoader @ 0xc04e9290"加载。占用208,987,664字节(20.36%)。内存在“"org.apache.hadoop.fs.FileSystem$Cache"”的一个实例中累积。文件系统被程序"sun.misc.Launcher$AppClassLoader @ 0xc04e9290"加载。

关键字

org.apache.hadoop.fs.FileSystem缓存

3.3.4 Problem Suspect 2

7,670个“org.apache.hadoop.conf.Configuration”实例。配置”,由“sun.misc”加载。"sun.misc.Launcher$AppClassLoader @ 0xc04e9290" 占用813,527,552字节(79.25%)。这些实例是从"java.util.HashMap$Node[]",的一个实例中引用的。由"<系统类加载器>"加载。

看到上述的信息,我们基本能找到在我们代码中造成内存泄漏可疑点的地方,很容易去定位问题。