Java程序内存分析Java VisualVM（Visual GC）

朴灿烈づ我的快乐病毒、 2022-05-30 02:00 214阅读 0赞

VisualVM 是一款免费的\\集成了多个JDK 命令行工具的可视化工具，它能为您提供强大的分析能力，对 Java 应用程序做性能分析和调优。这些功能包括生成和分析海量数据、跟踪内存泄漏、监控垃圾回收器、执行内存和 CPU 分析，同时它还支持在 MBeans 上进行浏览和操作。

在内存分析上，Java VisualVM的最大好处是可通过安装Visual GC插件来分析**GC（Gabage Collection）**趋势、内存消耗详细状况。

**一  Visual GC(监控垃圾回收器)**

Java VisualVM默认没有安装Visual GC插件，需要手动安装**，**JDK的安装目录的bin目露下双击**jvisualvm.exe**，即可打开Java VisualVM，点击菜单栏 **工具->插件** 安装Visual GC

[![wKiom1VUeQiyixcuAAMnGJdLLuU385.jpg][]][wKiom1VUeQiyixcuAAMnGJdLLuU385.jpg]

安装完成后重启Java VisualVM，Visual GC界面自动打开，即可看到JVM中堆内存的分代情况

[![wKiom1VUfh3QOdwoAAR5bOWPUSQ180.jpg][]][wKiom1VUfh3QOdwoAAR5bOWPUSQ180.jpg]

被监控的程序运行一段时间后Visual GC显示如下

[![wKiom1VUih3zWsSPAAXS4juKDgs487.jpg][]][wKiom1VUih3zWsSPAAXS4juKDgs487.jpg]

要看懂上面的图必须理解Java虚拟机的一些基本概念：

**堆(Heap)** ：JVM管理的内存叫堆

**分代：**根据对象的生命周期长短，把堆分为3个代：**Young，Old和Permanent**，根据不同代的特点采用不同的收集算法，扬长避短也。

1.  **Young（年轻代）**  
    年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor复制过来的对象。**而且，Survivor区总有一个是空的。参考文章：[http://www.iteye.com/topic/894148][http_www.iteye.com_topic_894148]**
2.  **Tenured（年老代）**  
    年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3.  **Perm（持久代）**  
    用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

**GC的基本概念**

gc分为full gc 跟 minor gc（Young GC也就是Minor GC），当每一块区满的时候都会引发gc。

1.  Scavenge GC  
    一般情况下，当新对象生成，并且在Eden申请空间失败时，就触发了Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。
2.  Full GC  
    对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC：

*  上一次GC之后Heap的各域分配策略动态变化

*  System.gc()被显示调用

*  Perm域被写满

*  Tenured被写满

**内存溢出 ** out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

**内存泄露**  memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。**其实说白了就是该内存空间使用完毕之后未回收。**

**查看java内存情况命令(jstat)**

** jmap -heap \[pid\] 查看内存分布**

jstat -gcutil \[pid\] 1000 每隔1s输出java进程的gc情况

[http://boendev.iteye.com/blog/882479][http_boendev.iteye.com_blog_882479]

[http://www.cnblogs.com/ggjucheng/p/3977384.html][http_www.cnblogs.com_ggjucheng_p_3977384.html]

# JVM的GC简介和实例 #

[http://www.searchtb.com/2013/07/jvm-gc-introduction-examples.html][http_www.searchtb.com_2013_07_jvm-gc-introduction-examples.html]

**二 Java VisualVM的其他功能**

**1.监视界面（cpu，类，堆，线程）**

[![wKioL1VUhwezuqlHAAPtVDlu7j8689.jpg][]][wKioL1VUhwezuqlHAAPtVDlu7j8689.jpg]

**2.线程界面**

VisualVM 的线程标签提供了三种视图，默认会以时间线的方式展现。另外两种视图分别是表视图和详细信息视图。

时间线视图上方的工具栏提供了缩小，放大和自适应三个按钮，以及一个下拉框，我们可以选择将所有线程、活动线程或者完成的线程显示在视图中。

[![wKiom1VUhl7zciIhAAPgDckTjF8605.jpg][]][wKiom1VUhl7zciIhAAPgDckTjF8605.jpg]

**3.Profile界面（性能剖析）**

在 Profiler 标签，点击“CPU”按钮启动一个 CPU 性能分析会话 ,VisualVM 会检测应用程序所有的被调用的方法。当进入一个方法时，线程会发出一个“method entry”的事件，当退出方法时同样会发出一个“method exit”的事件，这些事件都包含了时间戳。然后 VisualVM 会把每个被调用方法的总的执行时间和调用的次数按照运行时长展示出来。

此外，我们也可以通过性能分析结果下方的方法名过滤器对分析结果进行过滤。

[![wKioL1VUiMHx3I-AAAUZHlSza2c463.jpg][]][wKioL1VUiMHx3I-AAAUZHlSza2c463.jpg]

点击内存按钮执行内存分析查看类

[![wKioL1VUimnDkaQdAAPQ9qZatVg045.jpg][]][wKioL1VUimnDkaQdAAPQ9qZatVg045.jpg]

## 4.快照功能 ##

我们可以使用 VisualVM 的快照功能生成任意个性能分析快照并保存到本地来辅助我们进行性能分析。快照为捕获应用程序性能分析数据提供了一个很便捷的方式因为快照一旦生成可以在任何时候离线打开和查看，也可以相互传阅。

VisualVM 提供了两种类型的快照：

*  Profiler 快照：当有一个性能分析会话（内存或者 CPU）正在进行时，我们可以通过性能分析结果工具栏的“快照”按钮生成 Profiler 快照捕获当时的性能分析数据。
 *  应用程序快照：我们可以右键点击左侧 Applications 窗口中应用程序节点，选择“应用程序快照”为生成一个应用程序快照。应用程序快照会收集某一时刻的堆转储，线程转储和 Profiler 快照，同时也会捕获 JVM 的一些基本信息。

#####  Profiler 快照 #####

![图 13. Profiler 快照][13. Profiler]

#####     #####

##### 应用程序快照 #####

![图 14. 应用程序快照][14.]

**5.堆dump(转储）**和**线程dump（转储）操作**

**线程转储的生成与分析**

VisualVM 能够对正在运行的本地应用程序生成线程转储，把活动线程的堆栈踪迹打印出来，帮助我们有效了解线程运行的情况，诊断死锁、应用程序瘫痪等问题。

### 堆转储的生成与分析 ###

VisualVM 能够生成堆转储，统计某一特定时刻 JVM 中的对象信息，帮助我们分析对象的引用关系、是否有内存泄漏情况的发生等。

**Dump文件**是进程的内存镜像，可以把程序的执行状态通过调试器保存到dump文件中，堆dump的dump文件内容如下图所示

当 VisualVM 统计完堆内对象数据后，会把堆转储信息显示在新的堆转储标签内，我们可以看到摘要、类、实例数等信息以及通过 OQL 【对象查询语言是专门为ODMG（Object Database Management Group）对象模型制定的查询语言】控制台执行查询语句功能。

堆转储的摘要包括转储的文件大小、路径等基本信息，运行的系统环境信息，也可以显示所有的线程信息

从类视图可以获得各个类的实例数和占用堆大小数，分析出内存空间的使用情况，找出内存的瓶颈，避免内存的过度使用。

通过实例数视图可以获得每个实例内部各成员变量的值以及该实例被引用的位置。首先需要在类视图选择需要查看实例的类。

此外，还能对两个堆转储文件进行比较。通过比较我们能够分析出两个时间点哪些对象被大量创建或销毁。

线程转储和堆转储均可以另存成文件，以便进行离线分析。

详细讲解:

[http://www.ibm.com/developerworks/cn/java/j-lo-visualvm/][http_www.ibm.com_developerworks_cn_java_j-lo-visualvm]

**[![wKioL1VUjjeyw26xAAQawGDNDUs206.jpg][]][wKioL1VUjjeyw26xAAQawGDNDUs206.jpg]**

博客原文：[http://blog.csdn.net/jethai/article/details/52345074][http_blog.csdn.net_jethai_article_details_52345074]

[wKiom1VUeQiyixcuAAMnGJdLLuU385.jpg]: /images/20220530/f01a57b6849d4d6cb6828e446af0f1f7.png
[wKiom1VUfh3QOdwoAAR5bOWPUSQ180.jpg]: /images/20220530/12a4ca004f46488a927bb6996e8de058.png
[wKiom1VUih3zWsSPAAXS4juKDgs487.jpg]: /images/20220530/64d7d7f0b1ee40b0bc7bf004da14b43e.png
[http_www.iteye.com_topic_894148]: http://www.iteye.com/topic/894148
[http_boendev.iteye.com_blog_882479]: http://boendev.iteye.com/blog/882479
[http_www.cnblogs.com_ggjucheng_p_3977384.html]: http://www.cnblogs.com/ggjucheng/p/3977384.html
[http_www.searchtb.com_2013_07_jvm-gc-introduction-examples.html]: http://www.searchtb.com/2013/07/jvm-gc-introduction-examples.html
[wKioL1VUhwezuqlHAAPtVDlu7j8689.jpg]: /images/20220530/31ae857316ad4317804cafc6cac9ac52.png
[wKiom1VUhl7zciIhAAPgDckTjF8605.jpg]: /images/20220530/6d184442bc574c408ff4871af881abeb.png
[wKioL1VUiMHx3I-AAAUZHlSza2c463.jpg]: /images/20220530/2570a84ef2f34c4582c9b5d284734a0c.png
[wKioL1VUimnDkaQdAAPQ9qZatVg045.jpg]: /images/20220530/aa33e1b3f3714b22b0e1ee5700d2d665.png
[13. Profiler]: /images/20220530/d68bb1dedb95484b9d916dda081f6a98.png
[14.]: /images/20220530/b2778684c86c4239a48dd4432ea8c873.png
[http_www.ibm.com_developerworks_cn_java_j-lo-visualvm]: http://www.ibm.com/developerworks/cn/java/j-lo-visualvm/
[wKioL1VUjjeyw26xAAQawGDNDUs206.jpg]: /images/20220530/823c8f3f42a644bea92cf1556305beef.png
[http_blog.csdn.net_jethai_article_details_52345074]: http://blog.csdn.net/jethai/article/details/52345074