JVM可视化监控---VisualVM
一、VisualVM
VisualVM是Netbeans的profile子项目，在JDK6.0 update 7 中自带，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。
如果已经正确配置classpath路径，VisualVM的启动非常简单，只需在命令行输入jvisualvm即可启动图形化界面。VisualVM不仅支持本机监控，还支持远程监控。
二、安装方式
- jdk自带，bin目录下，双击即可打开，如图
2. idea插件，VisualVM Launcher，安装后配置参数，如图
配置后在idea上启动即可
- 官网下载客户端
下载路径：https://visualvm.github.io/download.html
下载后安装即可，本人喜欢直接用客户端
三、功能介绍
主界面，VisualVM会自动捕捉运行中的java进程，本人是在本地测试，故打开Local,即可看到运行中的java进程，点击edu.jiahui.convertlabgateway.Application，是本地启动的一个SpringBoot项目，可看到当前项目的概览
概述中显示了JVM、Java版本、dump批次等信息，在实战中这里的信息可用来进行信息核对。特别是JVM参数和系统属性项的核对。
监视界面是用得比较多的一个界面，通过该界面可以查看CPU使用情况、堆和Metaspace的使用情况、线程的使用情况、类的加载情况等。
通过对堆和Metaspace的使用情况分析，可以看到对应内存空间的使用和增长情况，可进行合理调整和规划。
点击右上角的Heap Dump,会基于点击的时间节点生成dump文件,如图
我们用来分析内存主要是在此页面中的“类”菜单内。也可以选择下拉框查看自己想看的细节
我这里选择了Objects,就可以看到所有对象的详情，也可以通过下面的Class Filter选择自己想看的。
四、插件安装
VisualVM提供了很多插件可以通过Tools–>Plugins安装,这里不在一一介绍，我安装了Visual GC，下面有用
五、内存溢出场景构建
先写一段代码，用来模拟内存溢出，也就是创建一个Map，然后向其中不断的新增对象。同时在程序处理的过程中让线程睡眠或死循环来方便通过VisualVM进行查看。
测试代码如下：
public class MemoryLeakTest {
/**
* 声明缓存对象
*/
private static final Map<String, TestMemory> CACHE_MAP = new HashMap<>();
public static void main(String[] args) {
try {
//给打开visualVm时间
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//循环添加对象到缓存
for (int i = 0; i < 1000000; i++) {
TestMemory t = new TestMemory();
CACHE_MAP.put("key" + i, t);
}
System.out.println("-------1------");
//为dump出堆提供时间
try {
//给打开visualVm时间
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
for(int i=0; i<1000000;i++){
TestMemory t = new TestMemory();
CACHE_MAP.put("key"+i,t);
}
}
}
TestMemory类代表生成中的业务类。
public class TestMemory {
}
然后放置在项目的启动类中
为了让程序更快地达到内存的阈值，我在idea中设置启动时可限制JVM的大小，这里设置为：-Xms128m -Xmx128m，设置步骤如图
一切准备妥当，下面来进行验证。
六、内存溢出分析
下面我们就来启动程序，启动VisualVM来进行内存溢出的分析。
当程序执行的过程中，我们会发现“堆”内存会出现一个快速增加的曲线。
这个过程中Metaspace也在随之增长。
打开Visual GC界面，我们会看到面试中被问过很多遍的堆内存结构：
通过这张图，可以直观的看到堆内存中的老年代、新生代、Metaspace空间（JDK8），还有新生代中的Eden、S0(Survivor From)、S1(Survivor To)，而且它们的分配比例也有一个比较直观的展示。
这里Eden已经被填满、S0和S1为空，老年代也几乎被填满（因为垃圾收集无法清除持有引用的对象）
最重要的是你会发现针对老年代在19.932s内进行了98次垃圾回收。也就是说已经触发了频繁的Full GC操作，而且内存并没有被释放掉。在生产系统中，当你看到系统在频繁的进行Full GC操作，那是JVM在释放一个很恐怖的信号了。
上面说了一些表象的内容，现在真正开进行内存分析了。回到上面提到的“监视”、“堆dump”、“类”中，可以看到下图：
可以看到，堆中存在着39万多个TestMemory对象。当你看到堆中有类似的大量的对象存在，你应该意识到此处可能有内存泄露。也就是大量的对象被创建，而没有被“顺利”回收。我们这里没被回收的原因是对象被放在了静态变量里面了。
服务继续运行，出现OOM
通过上面步骤，基本上可以定位到哪些对象的处理出现了问题，此时再回到代码中针对相应的代码进行排查，便可快速定位内存溢出的问题所在。其中我们需要特别留意上述过程中VisualVM为我们提供的那些报警信号和数据呈现。
七、远程连接
配置VisualVM远程连接：
https://www.cnblogs.com/liugh/p/7620336.html
八、小结
本文我们是在讲VisualVM的使用，也是在讲线上JVM的排查，也是在讲JVM的内存结构，还是在讲如何去构造一个内存溢出（bug）的场景。但讲什么并不重要，关键是看，通过这篇文章，你重温了什么，学到了什么，又收获了什么。