性能分析利器总结一《VisualVM》

article/2025/10/25 0:57:03

VisualVM

随着JDK7而出现，位于JDK根目录下的bin目录下。运行环境需JDK1.6及以上，能监控JDK1.4以上版本的应用程序。

相比JConsole，感觉功能更强大，且可集成各类插件，使其更强大。Jconsole算是VisualVM的子集吧。另外VisualVM也有JConsole的插件；
相比Arthas，它最大的特点肯定就是图形化了。Arthas必须得命令敲着走，且命令众多，不易上手（还全是英文……），并且它是JDK自带的！
对于eclipse和idea（VisualVM Launcher），也有相应插件，可在软件界面快速打开visualvm。

对于性能分析，主要几个点即是：

监控：实时CPU监控、内存监控、线程监控、其他监控；
转储：从内存中获得当前状态数据并存储到文件用于后续分析，一般是线程信息转储、类加载信息转储，以及堆上对象的转储；
快照：cpu情况快照、内存情况快照；
分析：程序中函数的调用关系、运行时间、内存分配及使用情况、载入的类、存在的对象信息等。

而VisualVM对这几个点做得都还是蛮不错的，下面进行一一说明。

转储和快照

而对于VisualVM，从界面上即可看到：

它支持线程转储、堆转储，并且支持在发生OOM时立即转储堆（Arthas没有做到这一点）。同时拥有应用程序快照，快照生成后可查看线程快照、cpu、内存、类等使用情况。

另外概述一栏，可方便地看到系统信息、JVM参数等，对于JVM参数调优这些，它用起来很友好！

线程转储

上图我们可以看到有一个“线程dump”，线程转储后，可看到各个线程当前时间正在做什么事情：

线程dump看到的是当前时刻线程的一个状态，可以看到线程是否在运行、多个线程是否在资源竞争;

多次dump进行对比可排查线程是否存在问题，如多次dump，发现某一个线程一直在调某个方法，则可说明该方法可能有些问题。

针对线程转储，也可使用jdk自带工具jstack：jstack -l [pid] > thread.dump

线程dump中可看到几个参数：

LoopThreadPool 线程/池名字
prio 线程优先级，默认为5
tid jvm线程ID，Thread.getId()获取到的就是它
nid 真实操作系统线程id

那么，我们如何查cpu占用比较大的线程呢？

常规方法

查到java进程id（pid）：

jps -m  //方法一，jps：jdk自带工具
ps ef|grep java  //方法二，Linux
tasklist|findstr java  //方法三，Windows

查看该进程下的所有线程id：

top -Hp [pid]  //方法一，Linux
Process Explorer工具直接找到进程下cpu占用比较大的线程  //方法二，Windows

后续还可根据线程id，去线程dump文件分析相应线程的信息
需要把线程id转换为十六进制，再去dump文件中查相应nid。

Visualvm

VisualVM的 抽样器 -> CPU -> 线程CPU时间 可直接看到

Arthas

thred top [n] 命令可直接看到前n个线程

堆转储

图中有一个“堆dump”，堆转储后，可看到jvm堆在当前时间的一个状态：

图中可清晰地看到哪些类对象占用内存比较大，并且参考线程dump，你也可以进行多次堆dump，然后进行堆转储比较。

VisualVM在堆转储上的优势：

能可视化直观地看到哪些类对象占比比较大，并且支持排序；
支持两个堆转储比较（见图右上角）；
支持过滤快速查找类名（见图左下角）；
支持OQL控制台查询；
支持点击某个类，可直观地看到该类的所有实例信息：重要

快照

图中有一个“应用程序快照”，快照后，可看到当前时间cpu、内存、类、线程情况。

监控

对于监控，VisualVM的监视一栏，可实时可视化查看cpu、内存、类、线程情况：

个人感觉，对于实时监控方面，VisualVM的确做的不错。另外从图中来看，CPU使用情况一图中，CPU的飙升是因为垃圾回收活动的频繁，而垃圾回收的频繁往往是因为内存占用的暴增。

小案例

之前遇到过一个服务器内存占用过大的情况：程序是从ES中查询数据到程序，查询的数据大小不一，大部分数据在3个G以内，极少部分达到7个G。

默认情况下，初始Xms=物理内存/64，默认Xmx=物理内存/4（如服务器内存是32G，即JVM最大内存可为8G），并且默认XX:MinHeapFreeRatio=40%，XX:MaxHeapFreeRatio=70%（即空闲的堆在40%-70%正常，小于则会扩充，当内存不够则报内存溢出，大于则会缩减）。

因此程序在接收到7个多G的数据时，把堆内存调为了8G。而事实上，大部分时间，堆上内存占用都在3G以内（空闲堆比例=(8-3)/8=62.2%，不会进行内存缩减），这时，总有5个G的空闲内存被JVM浪费掉。因此，可重新调整上面两个最小、最大空闲堆比例来解决。

线程监控

对于线程的可视化实时监控，它无疑也是很强大的：

图中我们可以看到，我有两个线程池：EsIO的线程池，负责对ES的IO请求，另一个是Web线程池，它负责分析ES查询的数据。

利用该图，我们可以清晰地看到：

各线程池名字，由图也可看出，我们在编写线程池时，带上线程名字更容易后续问题排查：

this.pool = new ThreadPoolExecutor(threadNum, threadNum, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(),new ThreadFactoryBuilder().setNameFormat(threadName + "-%d").build(),new ThreadPoolExecutor.AbortPolicy());

线程池是否是在并行执行（废话，线程池肯定是并行执行，但是有时我们会不知不觉出问题，如线程池中的线程存在资源竞争，也可能会导致线程串行执行）。看多个线程是否会并行运行，只需关注绿条是否会出现重叠。
哪些线程池长期处于空闲状态，如果发现某线程池中较多线程长期空闲，即可减少线程数量，分析出“最优线程数”（当然真正的“最优线程数”还得根据QPS、PV等综合决定）。同理，如果线程池长期繁忙，则可考虑增大线程数量（在增加、减少线程数时，也需结合CPU、内存、带宽等因素综合判断）。