在上一次【https://www.cnblogs.com/webor2006/p/10629889.html】已经编写了一个能在堆空间出现内存溢出的代码，先来回顾一下：
其中咱们给JVM配置了如下参数：
其中还设置了一个当发生内存溢出时来将内存的信息给dump出来，其实就类似于Android中来分析内存也是需要dump内存信息一样，如下：
其dump出来的文件在这个目录之下：
其实这个dump出来的文件也叫做“转储”文件，那用何工具来分析呢，有很多工具可以分析，这里学习一下之前也介绍的jvisualvm，它是由oracle基于hospot虚拟机力推的一个集大成者的一个功能超级强大的图形化分析工具，它是集成了很多的命令行的工具使得我们在一个GUI上看到不管是正在运行的JVM进程的种种信息，包括线程的信息、元空间的信息，堆空间的信息等等，还可以分析我们dump出来的转储文件，所以咱们先来打开此工具，在命令行中输入：
接下来咱们来打开转储文件：
接下来就详细来分析一下该转储文件：
堆转储上的线程: "main" prio=5 tid=1 RUNNABLE at java.lang.OutOfMemoryError.<init>(OutOfMemoryError.java:48) at java.util.Arrays.copyOf(Arrays.java:3210) Local Variable: class java.lang.Object[] at java.util.Arrays.copyOf(Arrays.java:3181) Local Variable: java.lang.Object[]#301 at java.util.ArrayList.grow(ArrayList.java:265) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231) at java.util.ArrayList.add(ArrayList.java:462) Local Variable: com.jvm.memory.MyTest1#64646 at com.jvm.memory.MyTest1.main(MyTest1.java:11) Local Variable: java.util.ArrayList#7 "Finalizer" daemon prio=8 tid=3 WAITING at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) Local Variable: java.lang.ref.ReferenceQueue#26 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:212) Local Variable: java.lang.System$2#1 "Signal Dispatcher" daemon prio=9 tid=4 RUNNABLE "Reference Handler" daemon prio=10 tid=2 WAITING at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference.tryHandlePending(Reference.java:191) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
可以清晰的看到线程的具体异常信息，其中OutOfMemoryError异常如果在真实项目中出现了肯定就是大问题了，对于它其实都比较熟悉了，还是来瞅一下它的官方对它的解释：
其中该异常的继承体系如下 ：
好，再回到jvisualvm，目前咱们是在这个视图上看到的信息：
接着来切换到类瞅一下：
好，接下来再来看另外一个视图：
也就是说需要在类视图中来选择要查看的实例数，所以咱们回到类视图来操作一下：
此时就可以自动跳到实例数这个视图了，如下：
而在实例数视图左侧看到有个500个实例的提示：
貌似跟我们在类似图看到个数不一样啊：
其实不是500个，还有其它木有展开而已，如下：
接着点击一下其中的实例，在右侧可以看到具体的字段信息，如下：
然后还能看到类加载器相关的信息，很显然我们自己创业的类是由应用类加载器所加载的：
接着还可以看一下它的父加载器，很显然是由扩展类加载器加载的：
而它的父加载器很显然就是根类加载器，也就是null嘛：
进一步对咱们之前学习的类加载器相关的知识进行巩固，好，再看最后一下视图：
接下来咱们再来改造一下我们的程序：
咱们先来看一下gc()方法的官方解释：
它最终调用的是System类中的gc()，如下：
咱们再来瞅下它的gc()注释：
从上面的解释也就说明了为啥在实际项目中不鼓励手动去调这个gc()方法，咱们这样做目的是为了学习研究仅此而已，当手动调用了gc()之后程序内部发生了啥变化呢？这里还是借用jvisualvm来查看下，首先找到咱们运行的进程：
然后双击打开它：
也有几个视图，咱们一个个来瞅下，先来看下监视：
可见是实时对进程的情况进行监视的，咱们细看一下：
接下来再切一个视图：
然后再切另外一个视图：
最后一个视图是用来分析性能的：
大致了解下既可，这里我们从jvisualvm的分析中可以发现我们的程序在堆中的使用基本是维持在2MB左右的，如下：
那。。如果我们手动将JVM的堆内存由目前的5MB改成1MB呢，看我们程序虽说主动调用了gc()看是否还会有溢出出现，试一下：
其实很容易理解，我们设置的堆内存是在1MB，而实际我们程序堆内存会在2MB左右，当然会溢出啦。