转载

【深入浅出-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，查看线程的堆栈，与抛出的错误信息一致，可以定位到代码的行数。

【深入浅出-VisualVM】（2）：分析堆内存OOM

其中 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。

【深入浅出-VisualVM】（2）：分析堆内存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的字符串，这一块以后有机会单独去介绍。

原文 http://mousycoder.com/2016/01/15/thinking-in-visualvm/thinking-in-visualvm-2/

正文到此结束