JVM虚拟机详解------jvisualvm使用及实战经历

本文主要是介绍JVM虚拟机详解------jvisualvm使用及实战经历，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. 相关

jvisualvm官方文档

官方对jvisualvm的介绍是

Visually monitors, troubleshoots, and profiles Java applications.

Java VisualVM是一个直观的图形用户界面，当基于Java技术的应用程序在指定的Java虚拟机（JVM）上运行时，可提供有关它们的详细信息。之所以命名为Java VisualVM，是因为Java VisualVM提供了有关JVM软件的可视化信息。

Java VisualVM将多个监视，故障排除和性能分析实用程序组合到一个工具中。例如，独立工具jmap，jinfo，jstat和jstack提供的大多数功能已集成到Java VisualVM中。可以将其他功能（例如jconsole命令提供的功能）添加为可选插件。

Java VisualVM对Java应用程序开发人员进行应用程序故障排除以及监视和改善应用程序的性能很有用。 Java VisualVM使开发人员能够生成和分析堆转储，跟踪内存泄漏，执行和监视垃圾回收以及执行轻量级内存和CPU性能分析。您可以使用插件扩展Java VisualVM功能。例如，可通过MBeans选项卡和JConsole插件包装器插件来使用jconsole命令的大多数功能。您可以从标准Java VisualVM插件的目录中选择，方法是依次选择“工具”和“ Java VisualVM”菜单中的“插件”。
在这里插入图片描述

2. 主要数据

2.1. 进程

在主界面左边本地下可以看到我们主机上当前正在运行的Java进程

2.2. dump

我们不借助jvisualvm的情况下可以通过jmap指令来查看jvm的dump数据，jvisualvm内置了jmap，所以能够可视化查看dump的数据，我们在鼠标置于线程上，然后右键就可以查看线程dump或堆hump，帮助我们分析进程当前的运行情况。

如果进程设置了OOME前生成堆dump，jvisualvm也可以导入dump文件进行分析。

#出现 OOME 时生成堆 dump: 
-XX:+HeapDumpOnOutOfMemoryError
#生成堆文件地址：
-XX:HeapDumpPath=/home/liuke/jvmlogs/

2.4. 进程概述

在这里插入图片描述

双击进程可以进入线程数据界面，第一个便是进程的概述，里面又我们进程运行的主机、主类、运行参数和java相关信息。

2.5. 监视器

在这里插入图片描述

进程监视器中展示了我们当前进程运行时长、CPU使用、内存、类的一些信息。

2.6. 线程

在这里插入图片描述

这里展示了线程的所有进程，我们还可以按照一定的条件进行筛选。

2.7. 抽样器

在这里插入图片描述

抽样器可以实时的展示某一段时间进程的活动情况，还可以选择cpu或线程作为抽样指标。

2.8. Visual GC

在这里插入图片描述

这是一个插件功能，可以去Oracle jvisualvm插件市场上去下载该插件，然后在jvisualvm上选择工具->插件->已下载->添加插件，然后选择我们下载好的插件进行安装，如果找不到gc插件，可以扫描文章最下方我的公众号，然后回复jvisualvm gc获取。

在这个界面上我们能够直观地查看进程当前的gc情况，包括jvm内存现状，gc次数等等。

3. 一次实战经历

由于涉密，所以仅描述大体信息
在今年3月份，我们的一个模块上线，平时这个模块不会出现什么问题，但是一旦友商举行活动（可以理解为电商的大促），支付量在短时间内会飙升到一个很高的值，这时候会出现频繁的卡顿，我们不知道友商设置的超时时间是多少，反正是最后会导致支付成功率非常低，负责这模块的同事一直认为是网络带宽不够，但是加了带宽之后问题仍然没有解决。那一段时间我们的支付数据非常难看，运营商多次给我们发出警告，老板很生气，于是我作为攻坚人员开始接手。

首先是检查数据库配置，打开慢日志，确实有很多条，数据库有点负载不足，加上sql设计不合理，于是优化了数据库相关问题。

但是问题还是没有解决，这个时候我开始重点放在jvm配置方面。检查了了配置后，我先是认为配置没有问题，然后开始使用jvisualvm检查dump，发现活动时会有多次的full gc，频率高达5min一次。于是等待一次友商做活动，我通宵监控GC情况，忽然发现了一个问题，minor gc后，Eden区的实例直接进入了老年代，我顿时大悟。

这里就涉及到了gc机制，每次minor gc，Eden区的实例应当进入s区才对，但是由于此时Eden里存活的实例太多了，超过了s区的50%，由于动态年龄检查机制，导致实例直接进入老年代，这才导致了full gc的频繁进行。

找到问题的原因后，优化了jvm的配置，然后full gc一周才进行一次，问题解决。