随着JDK7而出现,位于JDK根目录下的bin目录下。运行环境需JDK1.6及以上,能监控JDK1.4以上版本的应用程序。
相比JConsole,感觉功能更强大,且可集成各类插件,使其更强大。Jconsole算是VisualVM的子集吧。另外VisualVM也有JConsole的插件;
相比Arthas,它最大的特点肯定就是图形化了。Arthas必须得命令敲着走,且命令众多,不易上手(还全是英文……),并且它是JDK自带的!
对于eclipse和idea(VisualVM Launcher),也有相应插件,可在软件界面快速打开visualvm。
对于性能分析,主要几个点即是:
监控:实时CPU监控、内存监控、线程监控、其他监控;
转储:从内存中获得当前状态数据并存储到文件用于后续分析,一般是线程信息转储、类加载信息转储,以及堆上对象的转储;
快照:cpu情况快照、内存情况快照;
分析:程序中函数的调用关系、运行时间、内存分配及使用情况、载入的类、存在的对象信息等。
而VisualVM对这几个点做得都还是蛮不错的,下面进行一一说明。
转储和快照
而对于VisualVM,从界面上即可看到:
![05c2b2fe50206c846d80c096b0f7c080.png](https://i-blog.csdnimg.cn/blog_migrate/27a93e3b4a74dd0438db71eed1a23978.png)
它支持线程转储、堆转储,并且支持在发生OOM时立即转储堆(Arthas没有做到这一点)。同时拥有应用程序快照,快照生成后可查看线程快照、cpu、内存、类等使用情况。
另外概述一栏,可方便地看到系统信息、JVM参数等,对于JVM参数调优这些,它用起来很友好!
线程转储
上图我们可以看到有一个“线程dump”,线程转储后,可看到各个线程当前时间正在做什么事情:
![a1a8926d38a6b3ce3505cbcc468d68d5.png](https://i-blog.csdnimg.cn/blog_migrate/8637cd4ce32949b428f561bd8633eb8e.png)
线程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堆在当前时间的一个状态:
![f47c4b3c7af2ceffc461ccbfaec2e4b4.png](https://i-blog.csdnimg.cn/blog_migrate/304df1b15c9b3b1dc865a14e05441cb5.png)
图中可清晰地看到哪些类对象占用内存比较大,并且参考线程dump,你也可以进行多次堆dump,然后进行堆转储比较。
VisualVM在堆转储上的优势:
能可视化直观地看到哪些类对象占比比较大,并且支持排序;
支持两个堆转储比较(见图右上角);
支持过滤快速查找类名(见图左下角);
支持OQL控制台查询;
支持点击某个类,可直观地看到该类的所有实例信息:
重要
![d3d6b85df68d3e40488a6803f87915a5.png](https://i-blog.csdnimg.cn/blog_migrate/d5e951adc6ee2534e425945c87855612.png)
快照
图中有一个“应用程序快照”,快照后,可看到当前时间cpu、内存、类、线程情况。
监控
对于监控,VisualVM的监视
一栏,可实时可视化查看cpu、内存、类、线程情况:
![49646268dddd5170d3ce5e4cbe9ffc8a.png](https://i-blog.csdnimg.cn/blog_migrate/c0b2cb63542d2301539a962a04301c91.png)
个人感觉,对于实时监控方面,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浪费掉。因此,可重新调整上面两个最小、最大空闲堆比例来解决。
线程监控
对于线程的可视化实时监控,它无疑也是很强大的:
![8be5c424fd45659264fc00012349596a.png](https://i-blog.csdnimg.cn/blog_migrate/40cbf7f4df3de97985e35049d2e82e61.png)
图中我们可以看到,我有两个线程池: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、内存、带宽等因素综合判断)。
分析
VisualVM的抽样器
一栏可用于进行实时性能分析,做的很给力,我们可以看到下图:
![198fe9756bb4b79755e5a83d8821d897.png](https://i-blog.csdnimg.cn/blog_migrate/115182ee50d37bcf5c4e80498649b595.png)
CPU样例 是站在“方法”的角度,可以看到各个方法的自用时间,方便进行代码分析。
线程CPU时间 则是站在“线程”的角度,看到各个线程的自用时间。同时左下角均支持方法名/线程名过滤。
对于“方法”的执行时间,如果觉得看着不是很直观,你还可以把当前实时监控打一个Profiler快照(CPU样例下面有个按钮),该快照以方法调用树的形式,展示了各线程方法调用栈的执行时间:
![511ed6875b3abf45b3e23460bd3b666a.png](https://i-blog.csdnimg.cn/blog_migrate/904bbddf1c6eae328693db9b9859bcb5.png)
还可以分析热点方法:
![86542f19049d217877480a53d287d3bb.png](https://i-blog.csdnimg.cn/blog_migrate/b4db63a05ce2e02d498513f91bf9b9ae.png)
小结
Visualvm做转储、快照、监控、分析都还是蛮好的,JDK自带,执行jvisualvm
即可唤出。对于类似的分析工具,还有JProfiler、Yourkit等,不过都是收费的!