jvisualvm分析线程（jvisualvm分析dump）



一、JVisualVM能做什么

VisualVM 是Netbeans的profile子项目，已在JDK6.0 update 7 中自带(java启动时不需要特定参数，监控工具在bin/jvisualvm.exe)，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。

     在JDK_HOME/bin(默认是C:Program FilesJavajdk1.6.0_13bin)目录下面，有一个jvisualvm.exe文件，双击打开，从UI上来看，这个软件是基于NetBeans开发的了。

具体的介绍参看：

http://www.ibm.com/developerworks/cn/java/j-lo-visualvm/

二、准备模拟内存泄漏demo

1、定义静态变量HashMap

2、分段循环创建对象，并加入HashMap

代码如下：

3、配置jvm参数如下：

4、运行程序并打卡visualvm监控

三、使用jVisualvm分析内存泄漏

1、查看Visual GC标签，内容如下，这是输出first的截图

这是输出forth的截图：

老生代一直在gc，当程序继续运行可以发现老生代gc还在继续：增加到了10次，但是老生代的内存并没有减少。说明存在无法被回收的对象，可能是内存泄漏了。

如何分析是那个对象泄漏了呢？打开抽样器标签：点击后如下图：

按照程序输出进行堆dump，当输出first时，dump一次，当输出forth时dump一次。

进入最后dump出来的堆标签，点击类：点击右上角：“与另一个堆存储对比”。如图选择第一次导出的dump内容比较：

比较的结果如下：（10:39:23和10:38:48）比较（上图的比较顺序反了，结果是类实例减少），发现TestMemory类的实例数，一直在增加，却没有被垃圾回收。

可以看出在两次间隔时间内TestMemory对象实例一直在增加并且多了，说明该对象引用的方法可能存在内存泄漏。

如何查看，依赖关系。【点击类名，鼠标右键，选择在实例视图中显示】得到如下界面：

左侧是创建的实例总数，右侧上部为该实例的结构，下面为引用说明，从图中可以看出在类JvmMemoryTest里面被引用了，并且被HashMap引用。

如此可以确定泄漏的位置，进而根据实际情况进行分析解决。

五、扩展知识

线程死锁侦测

jvm优化建议

   本质上是减少GC的次数。

如果是频繁创建对象的应用，可以适当增加新生代大小。常量较多可以增加持久代大小。对于单例较多的对象可以增加老生代大小。比如spring应用中。

GC选择，在JDK5.0以后，JVM会根据当前系统配置进行判断。一般执行-Server命令便可以。gc包括三种策略：串行，并行，并发。

吞吐量大大应用，一般采用并行收集，开启多个线程，加快gc的是否。

响应速度高的应用，一般采用并发收集，比如应用服务器。

年老代建议配置为并发收集器，由于并发收集器不会压缩和整理磁盘碎片，因此建议配置：

直接运行linux上的jvisualvm

下载X-Manager,可以将试图展现在本地机器上。

不受此jvm支持

保证jvisualvm所属jdk版本和linux上一致。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/bcyy/69841.html