JVM性能调优监控工具hprof使用详解

最新推荐文章于 2025-09-24 13:57:20 发布

原创最新推荐文章于 2025-09-24 13:57:20 发布 · 6w 阅读

56 ·

CC 4.0 BY-SA版权

文章标签：

#JVM性能调优 #hprof #retained heap #mat #tomcat中jvm参数设置

Java深入专栏收录该内容

14 篇文章

订阅专栏

本文探讨了Java开发中常见的内存问题，如OutOfMemoryError和内存泄漏，并介绍了如何使用hprof工具进行JVM性能调优监控。通过生成hprof文件定位内存泄漏原因，并展示了如何在Tomcat中设置JVM参数。

一、问题现状

现实企业级Java开发中，有时候我们会碰到下面这些问题：

OutOfMemoryError，内存不足
内存泄露
线程死锁
锁争用（Lock Contention）
Java进程消耗CPU过高
......

这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具hprof进行介绍。

二、hprof文件的生成

生成hprof文件可以在DDMS（ DDMS 的全称是DalvikDebug Monitor Service，是 Android 开发环境中的Dalvik虚拟机调试监控服务。提供测试设备截屏、查看特定进程正在运行的线程以及堆信息、Logcat、广播状态信息、模拟电话呼叫、模拟接收及发送SMS、虚拟地理坐标等服务）选中进程点击窗口左上角的"dump hprof file"按钮来直接生成，也可以通过在程序加代码中来生成，以下通过设置生成hprof文件：

我们希望在memory 溢出时候能自动生成heap dump文件，为此，我们在运行时候添加JVM 参数：

-XX:+HeapDumpOnOutOfMemoryError

注：dump生成的.hprof文件默认放到了该项目目录下面。

先构造一个实体类User，这个User类就是一般的java 类，然后我们构造一个ArrayList，然后在一个无限循环中一直放这个User类的实例，因为User类和ArrayList都在堆上，而ArrayList因为是强引用，所以无法被GC回收，（因为我们List一直在用并没有摧毁）所以一旦ArrayList所占用的堆内存填满整个heap size时候，heap就溢出了。

package com.deppon.tps;
public class User {
	private String name;
	private String sex;
	private int age;
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	public String getSex() {
		return sex;
	}
	public void setSex(String sex) {
		this.sex = sex;
	}
	public int getAge() {
		return age;
	}
	public void setAge(int age) {
		this.age = age;
	}
    public User( String name,String sex,int age){
        this.name=name;
        this.sex=sex;
        this.age=age;
    }
}

然后我们创建一个main方法就是上面的Test1类里面，创建ArrayList，并且无限向其中添加User类对象的方法是：

package com.deppon.tps;
import java.util.ArrayList;
import java.util.List;
public class Test1 {
	public static void main(String[] args) {
		List<User> persons = new ArrayList<User> ();
        while( 1>0){
            persons.add( new User("liuhai","male",25));
        }
	}
}

当运行上述代码时候，堆溢出了，产生了heap dump文件（这里用VM参数指定了如果堆溢出则产生heap dump)

用 MAT(Memory Analyze Tool)工具--插件下载、安装及打开hprof文件见以下链接，分析这个hprof文件（java_pid39340.hprof），我们发现了，它的确探测出了memory leak问题，如下：

如图所示，这里很清楚的表示，main()方法中有一个集合类型,，然后集合中的每一个元素都是com.charles.research.User的对象，并且每个对象的Shallow Heap和Retained Heap大小都为24byte。因为ArrayList一直存在，所以当对象足够多时候，就把heap弄满并且溢出了。这里创建了76340681个User对象，每个对象占据了24个byte,所以一共占据了24 * 7634068=183217632字节，差不多约为 174.72M 大小的堆空间。在这里 User对象的S hallow Size 和 Retained Size都为24byte呢？

我们要看下Shallow Size和Retained Size各是什么？

Shallow Size是对象本身占据的内存的大小，不包含其引用的对象。对于常规对象（非数组）的Shallow Size由其成员变量的数量和类型来定，而数组的ShallowSize由数组类型和数组长度来决定，它为数组元素大小的总和。

Retained Size=当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C,C就是间接引用) ，并且排除被GC Roots直接或者间接引用的对象

所以，我们这里的User类，因为我们机器是32位 WIN7系统，所以对象头占据8byte,它包含String对象引用(name)，占据4byte,包含String对象引用（sex)，占据4byte,包含一个int类型(age),占据4byte,所以一共占据8+4+4+4=20byte，因为要补齐位数，所以最后尺寸为24byte. 这就是这个对象的本身大小(Shallow Heap)的大小。

小知识：为了说明补齐，大家也可以做实验，如果我们User中加一个String成员，那么User类大小仍然为24byte,因为这个新String对象的引用4byte刚好去填了补齐的那个坑，如果再加一个String成员，那么User类大小就直接从24byte升到32byte了，因为又产生了一个坑需要补齐。

而我们的User类中没有引入其他的类(不包括String，因为String直接被Root GC引用），所以回收User占据的内存就是回收User自身，所以Retained Heap大小等同于Shallow Heap大小。