【深入浅出-VisualVM】(2):分析堆内存OOM

  • 概述
    显示jvm运行时的参数,Java版本,以及系统属性。
  • 监控
    显示当前这个pid的cpu,堆,PermGen,类,线程的运行情况,可以主动进行垃圾回收,以及生成此时刻的dump文件。
  • 线程
    显示所有线程的“实时”状态(运行,休眠,等待,监视)以及时间,(调整好刷新时间),可以通过放大,放小,更细致的观察线程的状态,以及一个线程详细的时刻状态和线程dump堆栈。
  • 抽样器
    随机抽样快速检测,显示各个方法和线程的cpu耗时,以及堆区各个实例、方法区各个类、以及每个线程所占内存详细信息。

  • Profiler

    功能和抽样器差不多,只不过是全面检测,比较慢而已(类似杀毒软件的快速扫描和全盘扫描)。

OOM在JVM中发生的地方只有堆,栈,方法区,直接内存。

Java程序大多发生OOM是在堆区域,堆dump 是分析内存堆的唯一文件,可以由VisualVm,IBM HeapAnalyzer,Jhat,Eclipse MemoryAnalyzer等分析,这里单独介绍VisualVm。

案例:堆内存的OOM

设置JVM 启动参数 -Xmx1024m -Xms1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\dump (其中堆 1,073,741,824个字节,字节与m相差大约6个倍数)运行下面程序,则会发生OOM的时候,生成堆文件,目录在d盘dump文件夹下(或者设置VisualVm中右键该应用,发生OOME自动生成dump)。

当然生产的时候,并不是等到OOM才生成dump文件,直接用 jmap -dump:format=b,file=xxx.hprof 24331 jmap是jdk自带工具,format=b是代表二进制,file代表生成路径 24331代表pid,可以用 ps -ef | grep 进程名 找到 ,当然jmap还有很多功能,查看JVM堆对象占用情况,JVM内存状态等,这里不多介绍。

package jvisualVM;
 
public class JavaHeapTest {
    public final static int OUTOFMEMORY = 900000000;
 
    private String oom;
 
    private int length;
 
    StringBuffer tempOOM = new StringBuffer();
 
    public JavaHeapTest(int leng) {
        this.length = leng;
 
        int i = 0;
        while (i < leng) {
            i++;
            try {
                tempOOM.append("a");
            } catch (OutOfMemoryError e) {
               e.printStackTrace();
               break;
            }
        }
        this.oom = tempOOM.toString();
 
    }
 
    public String getOom() {
        return oom;
    }
 
    public int getLength() {
        return length;
    }
 
    public static void main(String[] args) {
        JavaHeapTest javaHeapTest = new JavaHeapTest(OUTOFMEMORY);
        System.out.println(javaHeapTest.getOom().length());
    }
 
}

输出:

java.lang.OutOfMemoryError: Java heap space
Dumping heap to d:\dump\java_pid10024.hprof ...
Heap dump file created [606447327 bytes in 1.577 secs]
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:2367)
	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415)
	at java.lang.StringBuffer.append(StringBuffer.java:237)
	at JavaHeapTest.<init>(JavaHeapTest.java:14)
	at JavaHeapTest.main(JavaHeapTest.java:34)
301989886

控制台信息可以定位到OOM发生是在JavaHeapTest第14行

1.我们用VisualVM装入堆dump文件(d:\dump\java_pid8444.hprof),文件越大,装载时间越长,点击摘要,在基本信息里找到导致OutOfMemoryError的异常线程main,查看线程的堆栈,与抛出的错误信息一致,可以定位到代码的行数。

其中 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415) Local Variable: java.lang.String#1 代表这里发生OOM的时候,String对象的实例号是1,点进去可以看到1的实例内容是字符串 a ,实例2的内容是 reference Handler ,这对分析以前常见的直接引用错误非常直观,有多少个实例,每个实例都是什么内容,一清二楚。面的字段引用,可以追溯到JavaHeapTest这个类的tempOOm(只能追溯全局变量) 发生的问题,可以定位到发生OOM的类,实际上可以通过1的堆栈信

2.选择类,按照类名大小排序,选择最大的char[],然后排序char[]的实例,选择最大的,查看右边的字段,展开下息,直接定位到char[]#1这个实例,造成OOM。

解决方案

增大堆大小,最后测试-Xmx7024m -Xms7024m 不会报OOM

共 4,291,445,456 个字节 / 900000000 = 4.7 (有一个char大约占用2个字节,可能是中间有复制拷贝吧)此方法不是根本解决方法,只是演示,根本是优化存大对象的方案。

如果用字符串相加替代Stringbuffer,相当慢,堆最高可以达到1G,之后是不断的GC,这里不做演示,有兴趣的童鞋,可以运用此方法,举一反三。

最后堆dump文件之间还可以比较差异,用于分析2个时间段堆中对象的变化,用于发现潜在的OOM。

堆dump文件,其实就相当于一个数据库文件,VisualVm提供了OQL控制台,可以像用SQL一样,快速查出我们需要的对象信息,例如: select s from java.lang.String s where s.count > 100 查看长度大于100的字符串,这一块以后有机会单独去介绍。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章