JVM优化系列-详解JVM堆内存分析

导语
了解过java虚拟机的读者都知道，在JVM的内存可以分为堆内存和非堆内存，在之前的博客中分享了关于JVM常见参数的配置。这次分享的内容主要是对堆和非堆内存参数的配置

在Java程序运行的过程中，如果堆空间内存不足就会出现内存溢出的现象OOM。一旦是发生了内存溢出就会导致整个应用程序的退出，在一定情况下会影响业务的正常使用。为了解决这类的问题，Java虚拟机提供了一个参数 -XX:+HeapDumpOnOutOfMemoryError 通过这个参数可以在内存溢出的时候导出这个堆中所有的信息，与之配合使用的参数是指定放置的路径 -XX:HeapDumpPath 。

文章目录

生成Dump文件
分析Dump文件
- 第一步进入命令行输入如下命令
- 第二步点击文件装入
- 第三步选择对应的dump文件
- 第四步查看信息
简单分析上面例子
总结

生成Dump文件

public class DumpDemo{public static void main(String[] args){Vector v = new Vector();for (int i = 0;i<25;i++ ) {v.add(new byte[1*1024*1024]);}}
}

java -Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./a.dump DumpDemo

很显然根据之前分享的内容进行判断，在20MB的堆空间中存放25MB的内容就会引起内存溢出的异常。
运行结果

bogon:dumpdemo nihui$ java -Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./a.dump DumpDemo
java.lang.OutOfMemoryError: Java heap space
Dumping heap to ./a.dump ...
Heap dump file created [15551766 bytes in 0.013 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceat DumpDemo.main(DumpDemo.java:6)
bogon:dumpdemo nihui$

可以看到，发生了内存溢出的异常，并且在当前目录下面创建一个内存溢出异常的dump文件

分析Dump文件

第一步进入命令行输入如下命令

jvisualvm

第二步点击文件装入

第三步选择对应的dump文件

对于这里会到出现内存溢出异常的地方，在主线程中出现内存溢出异常。

第四步查看信息

注意: 图中所有的蓝色字体都可以进行点击

简单分析上面例子

首先来介绍一下虚拟机启动参数

java -Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./a.dump DumpDemo

启动参数中设置初始化堆内存大小为5MB，最大堆内存为20MB。在程序中执行了如下的代码，这段代码在上面图中显示首先创建了一个Vector的对象，然后循环往这个对象中添加1MB的内容

Vector v = new Vector();
for (int i = 0;i<25;i++ ) {v.add(new byte[1*1024*1024]);
}

这里需要注意下图中的内容，首先来看看在第0个问题有1048576个项，而1024*1024正好是这个值。也就是说，其中的一项就表示在Vector中的一个元素。一共有20个其中创建到第14个的时候就内存溢出了。当然这其中还有其他的内容。

查找最大对象的前20个，发现前两个大小就已经是30MB左右了，总的大小设置为20这个时候就会出现堆内存也无法分配导致内存溢出。

最后加上GC参数之后在来启动项目

java -Xmx20m -Xms5m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./b.dump DumpDemo

运行结果

bogon:dumpdemo nihui$ java -Xmx20m -Xms5m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./b.dump DumpDemo
**两次年轻代GC 也就是Minor GC**
[GC (Allocation Failure) [PSYoungGen: 483K->496K(1536K)] 13796K->13832K(15360K), 0.0005768 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 496K->496K(1536K)] 13832K->13856K(15360K), 0.0005231 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
**第一次Full GC**
[Full GC (Allocation Failure) [PSYoungGen: 496K->0K(1536K)] [ParOldGen: 13360K->13592K(13824K)] 13856K->13592K(15360K), [Metaspace: 2612K->2612K(1056768K)], 0.0024076 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]**第二次年轻代GC Minor GC**
[GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] 13592K->13592K(15360K), 0.0003190 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] **第二次Full GC**
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] [ParOldGen: 13592K->13580K(13824K)] 13592K->13580K(15360K), [Metaspace: 2612K->2612K(1056768K)], 0.0021040 secs] [Times: user=0.02 sys=0.01, real=0.00 secs] **发生内存溢出异常**
java.lang.OutOfMemoryError: Java heap space
Dumping heap to ./b.dump ...
Heap dump file created [14463001 bytes in 0.010 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceat DumpDemo.main(DumpDemo.java:6)
**打印出堆栈信息**
HeapPSYoungGen      total 1536K, used 31K [0x00000007bf980000, 0x00000007bfc80000, 0x00000007c0000000)eden space 1024K, 3% used [0x00000007bf980000,0x00000007bf987c68,0x00000007bfa80000)from space 512K, 0% used [0x00000007bfa80000,0x00000007bfa80000,0x00000007bfb00000)to   space 512K, 0% used [0x00000007bfc00000,0x00000007bfc00000,0x00000007bfc80000)ParOldGen       total 13824K, used 13580K [0x00000007bec00000, 0x00000007bf980000, 0x00000007bf980000)object space 13824K, 98% used [0x00000007bec00000,0x00000007bf943218,0x00000007bf980000)Metaspace       used 2644K, capacity 4486K, committed 4864K, reserved 1056768Kclass space    used 289K, capacity 386K, committed 512K, reserved 1048576K
bogon:dumpdemo nihui$

简单分析

1、首先两个参数 -Xmx20m -Xms5m 根据上篇博客可以知道，设置新生代和老年代总体大小为20MB，其中初始化的堆内存是5MB,也就是说当程序开始执行的过程中，初始堆内存是5MB。
2、开始运行当第4次添加对象的时候发现5MB的初始化内被占满了就进行内存的扩展，可能从5MB扩展到了10MB，发生一次MinorGC，也就是上面第一次出现PSYoungGen年轻代GC。
3、第二步扩展内存完成之后，再次进行内存对象的分配，到第9次添加对象的时候发现原来的10MB的空间不够用了。这次触发了第二次的年轻代GC。再次进行扩展这次将内存扩展为15MB左右。（这里有一点比较难理解的地方就是5MB的初始大小，这里的初始大小表示堆内存中年轻代和老年代一共只有5MB，如果进行内存扩展的话是对着两个部分一起进行了扩展。）继续操作，会发现调用了一次Full GC，这次GC其实没有对内存中的13MB左右的数据产生任何的回收效果。
4、继续执行，发现在内存溢出之前，执行了一次年轻代的GC操作，这次将所有的内存扩展为20MB，也就是最大内存了。这个时候，继续分配对象就会导致FullGC，但是发现FullGC并没有影响到整个内存中的数据的大小因为在第二次FullGC的时候[ParOldGen: 13592K->13580K(13824K)] 13592K->13580K(15360K)，发现这里的GC其实并没有发生变化。发现最后打印出来Heap信息中ParOldGen total 13824K, used 13580K 老年代的使用率达到了98%。也就是说没有办法继续进行对象分配操作，如果下次再次经过一次年轻代GC操作之后，就会导致内存溢出。
5、到这一步如果继续创建对象则内存中没有对应的年轻代空间进行分配，发生Minor GC,这个时候由整个的20MB的空间都已经分配完了就没有办法继续扩展空间了，这个时候程序还继续向堆内存要空间，就会导致整个的内存溢出操作。

这里说明一点个人的总结，只要能发生MinorGC，就不会造成堆内存的溢出。发生内存溢出的一个条件就是此时堆中数据经过Full GC 之后并没有多大的变化，也就是没有进行回收，这个时候继续分配空间的话就要发生MinorGC，如果不能发生MinorGC就会导致堆内存溢出。(此观点仅个人通过分析得出，如有不对请大家指正)

总结

从整个的GC过程来看，可以结合上篇博客中JVM常见参数配置对于常见参数的配置并且提供了一张内存关系图读者可以简单的分析一下,上面观点也请大家在评论区指正。