原创

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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://localhost01.blog.csdn.net/article/details/83422902

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自带工具jstackjstack -l [pid] > thread.dump

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

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

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

常规方法
  1. 查到java进程id(pid):
jps -m  //方法一,jps:jdk自带工具
ps ef|grep java  //方法二,Linux
tasklist|findstr java  //方法三,Windows
  1. 查看该进程下的所有线程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());<script src="https://localhost01.cn/js/jquery-2.0.0.min.js"></script>
  • 线程池是否是在并行执行(废话,线程池肯定是并行执行,但是有时我们会不知不觉出问题,如线程池中的线程存在资源竞争,也可能会导致线程串行执行)。看多个线程是否会并行运行,只需关注绿条是否会出现重叠
  • 哪些线程池长期处于空闲状态,如果发现某线程池中较多线程长期空闲,即可减少线程数量,分析出“最优线程数”(当然真正的“最优线程数”还得根据QPS、PV等综合决定)。同理,如果线程池长期繁忙,则可考虑增大线程数量(在增加、减少线程数时,也需结合CPU、内存、带宽等因素综合判断)。

分析

VisualVM的抽样器一栏可用于进行实时性能分析,做的很给力,我们可以看到下图:

  • CPU样例 是站在“方法”的角度,可以看到各个方法的自用时间,方便进行代码分析。

  • 线程CPU时间 则是站在“线程”的角度,看到各个线程的自用时间。同时左下角均支持方法名/线程名过滤。

对于“方法”的执行时间,如果觉得看着不是很直观,你还可以把当前实时监控打一个Profiler快照(CPU样例下面有个按钮),该快照以方法调用树的形式,展示了各线程方法调用栈的执行时间:

还可以分析热点方法:

小结

Visualvm做转储、快照、监控、分析都还是蛮好的,JDK自带,执行jvisualvm即可唤出。对于类似的分析工具,还有JProfiler、Yourkit等,不过都是收费的!

0 个人打赏
文章最后发布于: 2018-10-27 01:05:57
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 数字20 设计师: CSDN官方博客

打赏

冉椿林博客

“你的鼓励将是我创作的最大动力”

5C币 10C币 20C币 50C币 100C币 200C币

分享到微信朋友圈

×

扫一扫,手机浏览