Java7自带分析内存工具在哪_操作方法：Java程序内存分析：使用mat工具分析内存使用情况...

MAT不是通用工具，它不能处理所有类型的堆存储文件。但是，可以更好地解析更多主流制造商和格式，例如Sun，HP，SAP和IBM的PHD堆存储文件使用的HPROF二进制堆存储文件。让我们来看看如何做，这可能对您有用。官方文件：

通常，出现OutOfMemoryError的原因有两个：

1、内存泄漏，该对象已死，并且不能由垃圾收集器自动收集。可以通过找出泄漏代码的位置和原因来确定解决方案；

2、内存溢出，并且内存中的对象仍然必须处于活动状态。这意味着Java堆分配空间不足。检查堆设置大小(-Xmx和-Xms)，并检查代码是否具有太长且无法持久的对象生命周期。在某些情况下，状态时间过长。

1.使用jmap生成堆信息

E盘的jmap文件夹中将有一个map.bin的堆信息文件。

2.将堆信息导入到垫子中进行分析

3.生成分析报告

mat可以为我们生成多个报告：

让我们看看生成的数据如何为我们提供帮助

在上图中，您可以看到其大部分功能。在饼图上，您将找到转储的大小以及类，对象和类加载器的数量。

在下面正确地显示了饼图，其中列出了最令人印象深刻的对象。将鼠标移一下，即可在左侧的对象检查中查看对象的详细信息。在下面的操作标签中：

直方图

通常，当堆内存量为堆内存量时，浅堆堆中的对象具有与保留内存相同的大小和相同的大小，对象将被垃圾释放并收集。

保留并设置一组主要对象，例如特定类的所有对象，或者由所有对象的特定类加载器加载的类，或者仅仅是一组任意对象，就是释放的组对象。如果所有对象的主要对象均为，则无法访问该设置。保留设置包括这些对象，所有其他对象只能通过这些对象。保留大小是总堆大小中包含的所有对象的保留。来自日食

有关详细说明，我建议您检查“浅堆”和“保留堆”，这是一个非常重要的概念。

这里使用该工具提供的正则表达式搜索我们自己的类并对其进行排序，以查看哪些类相对较大。

在左侧，您可以看到该类的详细用法，例如它所属的包，谁是父类，它所属的类加载器，内存地址，占用的大小和回收状态等。

这里是可以根据您的需要进行分组和搜索的工具。默认情况下，它是按类分组的，类似于sql ~~

中的group by

在这里您可以看到以上三个选项，它们分别生成概览，泄漏可疑物和主要成分数据，但是如果您想在其中查看图表，则此处生成的不是图表。

单击以在(概述)的“操作”选项卡中查看。

这是“概述”中的“堆转储概述”视图，在工具栏上单击它，这是全局内存使用情况信息

已用堆转储

79.7 MB

对象数

1,535,626

班数

8,459

类加载器的数量

74

GC根数

2,722

格式

hprof

JVM版本

时间

格林威治标准时间+ 0800 9:20:37 AM

日期

2014-7-2

标识符大小

32位

文件路径

E：\ jmap \ map.bin

文件长度

108,102,005

然后，您可以单击SystemProperties和Thread Overview进行查看。我不会在这里发布更多内容。

统治者树

我们可以看到ibatis占用了更多的内存

主要消费者

此图显示了占用大量内存的对象的分布。以下是一些特定的班级和人数。

按使用级别实际查看按级别分布的类的用法，java.lang.Class排名第一

还有另外一张我们更关心的图片，那就是根据软件包名称查看占用情况。根据包装，我们知道哪个公共jar或我们自己的包装占用了

通过这种方式，您可以看到程序包以及程序包中的哪些类正在占用更多空间。

嫌疑犯

从此报告中我们可以看到图片的暗区被怀疑存在内存泄漏。可以发现整个堆只有79.7M内存，而暗区占62％。因此，MAT通过一个简单的报告解释说该项目具有可疑代码。单击详细信息以查找课程。

单击鼠标，在带有外出引用的“列表对象”->下，可以检查该类所引用的对象，并检查是否存在其他对象引起的内存问题。

让我们继续查看池的gc根目录

选择GC根目录路径->如下所示在上下文菜单中排除弱引用，以过滤掉弱引用，因为弱引用不是解决问题的关键。

只需输入并检查，此处的代码没有问题，因此无需发布。

类加载器/组件“ org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8”占用19,052,864(2 2. 80％)字节。内存在“ java.util.HashMap $ Entry []”由“”加载的一个实例中累积。

关键字

java.util.HashMap $ Entry []

org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8

此段落在工具中提示。他告诉我们，WebappClassLoader的容量为19,052,864字节。这是tomcat的类加载器。 HashMap是JDK中占用最大的系统类加载器。这实际上是很正常的。人们经常将地图用作存储容器。

除了上一页中的描述之外，还有指向“累积点”和“累积对象”的最短路径部分，这些部分说明了从GC根到聚集点的最短路径，以及完整的参考链。观察“累积对象”部分，java.util.HashMap具有最大的保留堆(大小)，因此很明显，类实例是在HashMap中收集的。

查看“按类分类的累积对象”区域，您可以在其中找到要聚合的对象实例的类名称。标题是java.util.HashMap类。它已被实例化5573次。从这里可以看出，这个程序没有问题，因为这个数字是相对正常的，但是当出现问题时，我们将看到更大的self定义类将位于最前面，并且占用率很高高。

当然，垫子工具有很多用途。在这里，我将与您分享我所知道的。最后，我们需要弄清楚系统的内存使用情况，然后为其制定代码或架构以及服务器优化措施！

参考：

本文来自电脑杂谈，转载请注明本文网址：

http://www.pc-fly.com/a/shoujiruanjian/article-342039-1.html