jre的bin目录下的工具，都非常小。它都是tools.jar下面的代码的一层封装而已。tools.jar不是java标准，是Hotspot实现的。
|
名称 |
作用 |
|
jps |
JVM Process Status Tool，现实指定系统内所有的HotSpot虚拟机进程 |
|
jstat |
JVM Statistics Monitoring Tool，用于收集Hotspot虚拟机各个方面的运行参数 |
|
jinfo |
Configuration Info for Java，现实虚拟机配置信息 |
|
jmap |
Memory map for java，生成虚拟机的内存转储快照 |
|
jhat |
JVM heap Dunp Browser，用于分析heapdump文件，他会建立一个HTTP/HTML服务，让用户可通过浏览器查看 |
|
jstack |
Stack Track for java ，显示虚拟机线程快照 |
jps
jps用来查看基于HotSpot的JVM里面中，所有具有访问权限的Java进程的具体状态, 包括进程ID，进程启动的路径及启动参数等等，与unix上的ps类似，只不过jps是用来显示java进程，可以把jps理解为ps的一个子集。
主要参数说明 ：
-q 忽略输出的类名、Jar名以及传递给main方法的参数，只输出pid。
-m 输出传递给main方法的参数，如果是内嵌的JVM则输出为null。
-l 输出应用程序主类的完整包名，或者是应用程序JAR文件的完整路径。
-v 输出传给JVM的参数。
jstat
Jstat用于监控基于HotSpot的JVM，对其堆的使用情况进行实时的命令行的统计，使用jstat我们可以对指定的JVM做如下监控：
- 类的加载及卸载情况
- 查看新生代、老生代及持久代的容量及使用情况
- 查看新生代、老生代及持久代的垃圾收集情况，包括垃圾回收的次数及垃圾回收所占用的时间
- 查看新生代中Eden区及Survior区中容量及分配情况等
jstat工具特别强大，它有众多的可选项，通过提供多种不同的监控维度，使我们可以从不同的维度来了解到当前JVM堆的使用情况。详细查看堆内各个部分的使用量，使用的时候必须加上待统计的Java进程号，可选的不同维度参数以及可选的统计频率参数。
命令格式：
jstat [ option vmid [interval][s|ms][count]]
option 参数如下面表格
Option Displays...
|
用于查看类加载情况的统计 |
|
|
用于查看HotSpot中即时编译器编译情况的统计 |
|
|
用于查看JVM中堆的垃圾收集情况的统计 |
|
|
用于查看新生代、老生代及持久代的存储容量情况 |
|
|
用于查看垃圾收集的统计情况（这个和-gcutil选项一样），如果有发生垃圾收集，它还会显示最后一次及当前正在发生垃圾收集的原因。 |
|
|
用于查看新生代垃圾收集的情况 |
|
|
用于查看新生代的存储容量情况 |
|
|
用于查看老生代及持久代发生GC的情况 |
|
|
用于查看老生代的容量 |
|
|
用于查看持久代的容量 |
|
|
用于查看新生代、老生代及持代垃圾收集的情况 |
|
|
HotSpot编译方法的统计 |
interval 和count 代表查询次数和间隔。
列说明：
|
S0C |
新生代中Survivor space中S0当前容量的大小（KB） |
|
S1C |
新生代中Survivor space中S1当前容量的大小（KB） |
|
S0U |
新生代中Survivor space中S0容量使用的大小（KB） |
|
S1U |
新生代中Survivor space中S1容量使用的大小（KB） |
|
EC |
Eden space当前容量的大小（KB） |
|
EU |
Eden space容量使用的大小（KB） |
|
OC |
Old space当前容量的大小（KB） |
|
OU |
Old space使用容量的大小（KB） |
|
PC |
Permanent space当前容量的大小（KB） |
|
PU |
Permanent space使用容量的大小（KB） |
|
YGC |
从应用程序启动到采样时发生 Young GC 的次数 |
|
YGCT |
从应用程序启动到采样时 Young GC 所用的时间(秒) |
|
FGC |
从应用程序启动到采样时发生 Full GC 的次数 |
|
FGCT |
从应用程序启动到采样时 Full GC 所用的时间(秒) |
|
GCT |
T从应用程序启动到采样时用于垃圾回收的总时间(单位秒)，它的值等于YGC+FGC |
jinfo
jinfo可以输出并修改运行时的java 进程的opts。用处比较简单，用于输出JAVA系统参数及命令行参数。
jmap
jmap用于生成堆转储快照（一般称为heapdump或者dump文件）。当然也可其他方法比如加参数-XX：+HeapDumpOnOutOfMemoryError参数，在虚拟机OOM异常的之后自动生成dump文件，也可以通过-XX：+HeapDumpOnCtrlBreak参数则可以使用Ctrl+Break键让虚拟机生成dump文件。
参数说明：
-dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件.
-finalizerinfo 打印正等候回收的对象的信息.
-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.
-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀"*". 如果live子参数加上后,只统计活的对象数量.
-permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.
-F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效.
jhat
jhat是sun提供的dump分析工具，上面讲过分析dump的工具还有MAT( Eclipse Memory Analyzer tool)、IBM HeapAnalyzer等，一般这个命令不太用到，是因为分析dump是个既耗时又耗机器资源的过程，第二个原因是这个工具比较简陋，没有MAT( Eclipse Memory Analyzer tool)、IBM HeapAnalyzer这些专业和强大。
jstack
jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"
可以查看线程当前的调用堆栈，线程状态，锁持有情况：
JDK可视化工具
jconsole
JConsole是一个基于JMX的GUI工具，用于连接正在运行的JVM，不过此JVM需要使用可管理的模式启动。如果要把一个应用以可管理的形式启动，可以在启动是设置com.sun.management.jmxremote。
设置参数：
调用命令：
打开了可视化界面如下：
注意这里有一个检测死锁的功能。
jvisualVM
JDK自带的JAVA性能分析工具。它已经在你的JDK bin目录里了，只要你使用的是JDK1.6 Update7之后的版本。
jvisualVM所谓多合一虚拟机故障处理工具，有强大的插件扩展功能，通过安装插件扩展支持，jvisualVM可以做到：
a、显示虚拟机进程及进程的配置和环境信息（jps，jinfo）；
b、监视应用程序CPU、GC、堆、方法区及线程的信息（jstat、jstack）；
c、dump及分析堆转储快照（jmap、jhat）；
d、方法级的程序性能分析，找出调用最多，运行时间最长的方法；
安装
只要安装JDK即可，运行jvisualvm.exe ，选择【工具】——【插件】——【可用插件】（自带的有几个主要插件，不过jvisualvm提供了直接从网上检查更新并下载其他插件）
·
如果版本比较老，那么还是连接的sun的插件重心，需要修改，在https://visualvm.github.io/pluginscenters.html 地址下，找到对应的jdk版本，将对应的.xml.gz地址配置在插件中心的地址里即可。
远程监控cpu使用情况
点采样器栏：
点击cpu，观察到cpu使用状况，点击snapshot，采取结果，可以选择查看方法、类或包的cpu使用情况，使用工具可以查找想要查看的方法、类或包：
GC监控
选择要监控的pid，查看GC情况
如果Old区满了，每次回收都很少或者回收不了，说明GC有问题。
远程监控内存泄露、解决内存溢出问题
1)内存泄露、溢出的异同
同：都会导致应用程序运行出现问题，性能下降或挂起。
异：
内存泄露是导致内存溢出的原因之一；内存泄露积累起来将导致内存溢出。
内存泄露可以通过完善代码来避免；内存溢出可以通过调整配置来减少发生频率，但无法彻底避免。
2)监测内存泄漏
内存泄漏是指程序中间动态分配了内存，但在程序结束时没有释放这部分内存，从而造成那部分内存不可用的情况，重启计算机可以解决，但也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件设计缺陷引起的。
内存泄漏可以分为4类：
a. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
b.偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
c.一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
d.隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
3)Heap dump 分析
每隔一段时间给所检测的java应用做一次heap dump：
（或者在响应应用pid上鼠标右键heap dump）弹出以下提示框：
在应用服务器将此文件下载到jvisual vm所在的机器上，file--load打开此文件，如下面三图所示：
对比上面三个截图，发现似乎有个东西在急速飙升，仔细一看是这个对象：org.eclipse.swt.graphics.Image 在第一章图中这个还没排的上，第二次dump已经上升到5181个，第三次就是7845个了。涨速相当快，而且和任务管理器里面看到的GDI数量增涨一致，就是它了。
问题到这儿就比较清楚了，回到代码里面仔细一看可以发现，是某个地方反复的用图片来创建Image对象导致的，改掉以后搞定问题。
到这里其实我想说的是，Java使用起来其实要比C++更容易导致内存泄漏。对于C++来说，每一个申请的对象都必须明确释放，任何没有释放的对象都会导致memleak，这是不可饶恕的，而且这类问题已经有很多工具和方法来解决。但是到了Java里面情况就不同了，对于Java程序员来说对象都是不需要也无法主动销毁的，所以一般的思路是：随用随new，用完即丢。很多对象具体的生命周期可能连写代码的人自己也不清楚，或者不需要清楚，只知道某个时刻垃圾收集器会去做的，不用管。但很可能某个对象在"用完即丢"的时候在另一个不容易发现的地方被保存了一个引用，那么这个对象就永远不会被回收。更加糟糕的是整个程序从设计之初就没有考虑过对象回收的问题，对于C++程序员来说memleak必然是一个设计错误，但是对Java程序员来说这只是一个疏忽，而且似乎没有什么好的办法来避免。今天看到的这个问题是因为GDI泄漏会造成严重后果才被重视，但如果仅仅是造成内存泄漏，那这个程序可能得连续跑上个十天半个月才会发现问题。最后就是，对于c++，错误的代码在测试阶段就可以快速的侦测出哪怕一个byte的memleak并加以改正，但是对于java程序，理论上没有哪个工具能够知道是不是有泄漏，因为除了作者自己以外没有人能够知道一个被引用的对象是不是应该被销毁，只有通过大量的，长期的压力测试才能发现问题，这是很危险的一件事情。
4)解决内存溢出问题
1、java.lang.OutOfMemoryError: PermGen space
JVM管理两种类型的内存，堆和非堆。堆是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
PermGen space的全称是Permanent Generation space，是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的，Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同，GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话，就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
如上图所示，PermGen在程序运行一段时间后超出了我们指定的128MB，通过Classes视图看到，Java在运行的同时加载了大量的类到内存中。PermGen会存储Jar或者Class的描述信息；所以在class大量增加的同时PermGen超出了我们指定的范围。为了让应用稳定，我们需要探寻新的PermGen范围。检测时段时候后（如下图）发现PermGen在145MB左右稳定，那么我们就得到了稳定的新参数；这样PermGen内存溢出的问题得到解决。
2、java.lang.OutOfMemoryError: Java heap space
第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。
注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
垃圾回收GC的角色，JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：
一个是当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。
根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。
为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收。一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
2.7.如何避免内存泄漏、溢出
1)尽早释放无用对象的引用。
好的办法是使用临时变量的时候，让引用变量在退出活动域后自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
2) 程序进行字符串处理时，尽量避免使用String，而应使用StringBuffer。
因为每一个String对象都会独立占用内存一块区域，如：
1.String str = "aaa";
2.String str2 = "bbb";
3.String str3 = str + str2;
4.// 假如执行此次之后str , str2再不被调用，那么它们就会在内存中等待GC回收；
5.// 假如程序中存在过多的类似情况就会出现内存错误；
3) 尽量少用静态变量。
因为静态变量是全局的，GC不会回收。
4) 避免集中创建对象尤其是大对象，如果可以的话尽量使用流操作。
JVM会突然需要大量内存，这时会触发GC优化系统内存环境； 一个案例如下：
1.// 使用jspsmartUpload作文件上传，运行过程中经常出现java.outofMemoryError的错误，
2.// 检查之后发现问题：组件里的代码
3.m_totalBytes = m_request.getContentLength();
4.m_binArray = new byte[m_totalBytes];
5.// totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。
6.// 解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。
7.// 参考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747
6) 不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃。
7) 优化配置。
a.设置-Xms、-Xmx相等；
b.设置NewSize、MaxNewSize相等；
c.设置Heap size, PermGen space:
概述
开发大型 Java 应用程序的过程中难免遇到内存泄露、性能瓶颈等问题，比如文件、网络、数据库的连接未释放，未优化的算法等。随着应用程序的持续运行，可能会造成整个系统运行效率下降，严重的则会造成系统崩溃。为了找出程序中隐藏的这些问题，在项目开发后期往往会使用性能分析工具来对应用程序的性能进行分析和优化。
VisualVM 是一款免费的性能分析工具。它通过 jvmstat、JMX、SA（Serviceability Agent）以及 Attach API 等多种方式从程序运行时获得实时数据，从而进行动态的性能分析。同时，它能自动选择更快更轻量级的技术尽量减少性能分析对应用程序造成的影响，提高性能分析的精度。
本文将对 VisualVM 的主要功能逐一介绍并探讨如何利用获得的数据进行性能分析及调优。
背景知识
性能分析的主要方式
-
监视：监视是一种用来查看应用程序运行时行为的一般方法。通常会有多个视图（View）分别实时地显示 CPU 使用情况、内存使用情况、线程状态以及其他一些有用的信息，以便用户能很快地发现问题的关键所在。
-
转储：性能分析工具从内存中获得当前状态数据并存储到文件用于静态的性能分析。Java 程序是通过在启动 Java 程序时添加适当的条件参数来触发转储操作的。它包括以下三种：
-
系统转储：JVM 生成的本地系统的转储，又称作核心转储。一般的，系统转储数据量大，需要平台相关的工具去分析，如 Windows 上的 windbg 和 Linux 上的 gdb。
-
Java 转储：JVM 内部生成的格式化后的数据，包括线程信息，类的加载信息以及堆的统计数据。通常也用于检测死锁。
-
堆转储：JVM 将所有对象的堆内容存储到文件。
-
快照：应用程序启动后，性能分析工具开始收集各种运行时数据，其中一些数据直接显示在监视视图中，而另外大部分数据被保存在内部，直到用户要求获取快照，基于这些保存的数据的统计信息才被显示出来。快照包含了应用程序在一段时间内的执行信息，通常有 CPU 快照和内存快照两种类型。
-
CPU 快照：主要包含了应用程序中函数的调用关系及运行时间，这些信息通常可以在 CPU 快照视图中进行查看。
-
内存快照：主要包含了内存的分配和使用情况、载入的所有类、存在的对象信息及对象间的引用关系等。这些信息通常可以在内存快照视图中进行查看。
-
性能分析：性能分析是通过收集程序运行时的执行数据来帮助开发人员定位程序需要被优化的部分，从而提高程序的运行速度或是内存使用效率，主要有以下三个方面：
-
CPU 性能分析：CPU 性能分析的主要目的是统计函数的调用情况及执行时间，或者更简单的情况就是统计应用程序的 CPU 使用情况。通常有 CPU 监视和 CPU 快照两种方式来显示 CPU 性能分析结果。
-
内存性能分析：内存性能分析的主要目的是通过统计内存使用情况检测可能存在的内存泄露问题及确定优化内存使用的方向。通常有内存监视和内存快照两种方式来显示内存性能分析结果。
-
线程性能分析：线程性能分析主要用于在多线程应用程序中确定内存的问题所在。一般包括线程的状态变化情况，死锁情况和某个线程在线程生命期内状态的分布情况等
VisualVM 安装
VisualVM 是一个性能分析工具，自从 JDK 6 Update 7 以后已经作为 Oracle JDK 的一部分，位于 JDK 根目录的 bin 文件夹下。VisualVM 自身要在 JDK6 以上的版本上运行，但是它能够监控 JDK1.4 以上版本的应用程序。下面主要介绍如何安装 VisualVM 以及各种 VisualVM 上的插件。
安装 VisualVM
VisualVM 项目的官方网站目前提供英文版本和多语言支持版本下载。多语言版本主要支持英语、日语以及中文三种语言。如果下载安装多语言版本的 VisualVM，安装程序会依据操作系统的当前语言环境去安装相应 VisualVM 的语言版本。最新 VisualVM 版本主要支持的操作系统包括：Microsoft Windows (7, Vista, XP, Server)、Linux、Sun Solaris、Mac OS X、HP-UX 11i。本文以 Microsoft Windows XP 为安装环境并支持中文。
-
从 VisualVM 项目的官方网站上下载 VisualVM 安装程序。
-
将 VisualVM 安装程序解压缩到本地系统。
-
导航至 VisualVM 安装目录的 bin 目录，然后启动 jvisualvm.exe。
安装 VisualVM 上的插件
VisualVM 插件中心提供很多插件以供安装向 VisualVM 添加功能。可以通过 VisualVM 应用程序安装，或者从 VisualVM 插件中心手动下载插件，然后离线安装。另外，用户还可以通过下载插件分发文件 (.nbm 文件 ) 安装第三方插件为 VisualVM 添加功能。
从 VisualVM 插件中心安装插件安装步骤 :
-
从主菜单中选择"工具">"插件"。
-
在"可用插件"标签中，选中该插件的"安装"复选框。单击"安装"。
-
逐步完成插件安装程序。
图 1. VisualVM 插件管理器
根据 .nbm 文件安装第三方插件安装步骤 :
-
从主菜单中选择"工具">"插件"。
-
在"已下载"标签中，点击"添加插件"按钮，选择已下载的插件分发文件 (.nbm) 并打开。
-
选中打开的插件分发文件，并单击"安装"按钮，逐步完成插件安装程序。
图 2. 通过 .nbm 文件安装 VisualVM 插件
功能介绍
下面我们将介绍性能分析的几种常见方式以及如何使用 VisualVM 性能分析工具进行分析。
内存分析
VisualVM 通过检测 JVM 中加载的类和对象信息等帮助我们分析内存使用情况，我们可以通过 VisualVM 的监视标签和 Profiler 标签对应用程序进行内存分析。
在监视标签内，我们可以看到实时的应用程序内存堆以及永久保留区域的使用情况。
图 3. 内存堆使用情况
图 4. 永久保留区域使用情况
此外，我们也可以通过 Applications 窗口右击应用程序节点来启用"在出现 OOME 时生成堆 Dump"功能，当应用程序出现 OutOfMemory 例外时，VisualVM 将自动生成一个堆转储。
图 5. 开启"在出现 OOME 时生成堆"功能
在 Profiler 标签，点击"内存"按钮将启动一个内存分析会话，等 VisualVM 收集和统计完相关性能数据信息，将会显示在性能分析结果。通过内存性能分析结果，我们可以查看哪些对象占用了较多的内存，存活的时间比较长等，以便做进一步的优化。
此外，我们可以通过性能分析结果下方的类名过滤器对分析结果进行过滤。
图 6. 内存分析结果
CPU 分析
VisualVM 能够监控应用程序在一段时间的 CPU 的使用情况，显示 CPU 的使用率、方法的执行效率和频率等相关数据帮助我们发现应用程序的性能瓶颈。我们可以通过 VisualVM 的监视标签和 Profiler 标签对应用程序进行 CPU 性能分析。
在监视标签内，我们可以查看 CPU 的使用率以及垃圾回收活动对性能的影响。过高的 CPU 使用率可能是由于我们的项目中存在低效的代码，可以通过 Profiler 标签的 CPU 性能分析功能进行详细的分析。如果垃圾回收活动过于频繁，占用了较高的 CPU 资源，可能是由内存不足或者是新生代和旧生代分配不合理导致的等。
图 7. CPU 使用情况
在 Profiler 标签，点击"CPU"按钮启动一个 CPU 性能分析会话 ,VisualVM 会检测应用程序所有的被调用的方法。当进入一个方法时，线程会发出一个"method entry"的事件，当退出方法时同样会发出一个"method exit"的事件，这些事件都包含了时间戳。然后 VisualVM 会把每个被调用方法的总的执行时间和调用的次数按照运行时长展示出来。
此外，我们也可以通过性能分析结果下方的方法名过滤器对分析结果进行过滤。
图 8. CPU 性能分析结果
线程分析
Java 语言能够很好的实现多线程应用程序。当我们对一个多线程应用程序进行调试或者开发后期做性能调优的时候，往往需要了解当前程序中所有线程的运行状态，是否有死锁、热锁等情况的发生，从而分析系统可能存在的问题。
在 VisualVM 的监视标签内，我们可以查看当前应用程序中所有活动线程和守护线程的数量等实时信息。
图 9. 活跃线程情况
VisualVM 的线程标签提供了三种视图，默认会以时间线的方式展现。另外两种视图分别是表视图和详细信息视图。
时间线视图上方的工具栏提供了缩小，放大和自适应三个按钮，以及一个下拉框，我们可以选择将所有线程、活动线程或者完成的线程显示在视图中。
图 10. 线程时间线视图
图 11. 线程表视图
我们在详细信息视图中不但可以查看所有线程、活动线程和结束的线程的详细数据，而且也可以查看某个线程的详细情况。
图 12. 线程详细视图
快照功能
我们可以使用 VisualVM 的快照功能生成任意个性能分析快照并保存到本地来辅助我们进行性能分析。快照为捕获应用程序性能分析数据提供了一个很便捷的方式因为快照一旦生成可以在任何时候离线打开和查看，也可以相互传阅。
VisualVM 提供了两种类型的快照：
-
Profiler 快照：当有一个性能分析会话（内存或者 CPU）正在进行时，我们可以通过性能分析结果工具栏的"快照"按钮生成 Profiler 快照捕获当时的性能分析数据。
图 13. Profiler 快照
-
应用程序快照：我们可以右键点击左侧 Applications 窗口中应用程序节点，选择"应用程序快照"为生成一个应用程序快照。应用程序快照会收集某一时刻的堆转储，线程转储和 Profiler 快照，同时也会捕获 JVM 的一些基本信息。
图 14. 应用程序快照
转储功能
线程转储的生成与分析
VisualVM 能够对正在运行的本地应用程序生成线程转储，把活动线程的堆栈踪迹打印出来，帮助我们有效了解线程运行的情况，诊断死锁、应用程序瘫痪等问题。
图 15. 线程标签及线程转储功能
当 VisualVM 统计完应用程序内线程的相关数据，会把这些信息显示新的线程转储标签。
图 16. 线程转储结果
堆转储的生成与分析
VisualVM 能够生成堆转储，统计某一特定时刻 JVM 中的对象信息，帮助我们分析对象的引用关系、是否有内存泄漏情况的发生等。
图 17. 监视标签及堆转储功能
当 VisualVM 统计完堆内对象数据后，会把堆转储信息显示在新的堆转储标签内，我们可以看到摘要、类、实例数等信息以及通过 OQL 控制台执行查询语句功能。
堆转储的摘要包括转储的文件大小、路径等基本信息，运行的系统环境信息，也可以显示所有的线程信息。
图 18. 堆转储的摘要视图
从类视图可以获得各个类的实例数和占用堆大小数，分析出内存空间的使用情况，找出内存的瓶颈，避免内存的过度使用。
图 19. 堆转储的类视图
通过实例数视图可以获得每个实例内部各成员变量的值以及该实例被引用的位置。首先需要在类视图选择需要查看实例的类。
图 20. 选择查询实例数的类
图 21. 实例数视图
此外，还能对两个堆转储文件进行比较。通过比较我们能够分析出两个时间点哪些对象被大量创建或销毁。
图 22. 堆转储的比较
图 23. 堆转储的比较结果
线程转储和堆转储均可以另存成文件，以便进行离线分析。
图 24. 转储文件的导出
https://www.ibm.com/developerworks/cn/java/j-5things7.html