前提概要： 

       JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。

现实企业级Java开发中，有时候我们会碰到下面这些问题：

• OutOfMemoryError，内存不足

• 内存泄露

• 线程死锁

• 锁争用（Lock Contention）

• Java进程消耗CPU过高

• ......

这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。

一、 jps(Java Virtual Machine Process Status Tool)      ： 基础工具

实际中这是最常用的命令，下面要介绍的小工具更多的都是先要使用jps查看出当前有哪些Java进程，获取该Java进程的id后再对该进程进行处理。

jps主要用来输出JVM中运行的进程状态信息。语法格式如下：

 如果不指定hostid就默认为当前主机或服务器。

命令行参数选项说明如下：

比如

1、我现在有一个WordCountTopo的Strom程序正在本机运行。

2、使用java -jar deadlock.jar & 启动一个线程死锁的程序

二、 jstack    jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：

    jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。

下面我们来一个实例：

找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。

 第一步： 先找出Java进程ID，服务器上的Java应用名称为wordcount.jar：

得到进程ID为2860,

第二步:找出该进程内最耗费CPU的线程，可以使用如下3个命令，这里我们使用第3个命令得出如下结果：

TIME列就是各个Java线程耗费的CPU时间，显然CPU时间最长的是ID为2968的线程，用

得到2968的十六进制值为b98，下面会用到。

   第三步：终于轮到jstack上场了，它用来输出进程2860的堆栈信息，然后根据线程ID的十六进制值grep，如下：

可以看到CPU消耗在SessionTracker这个类的Object.wait()，于是就能很容易的定位到相关的代码了。

三、 jmap（Memory Map）和 jhat（Java Heap Analysis Tool）：

jmap导出堆内存，然后使用jhat来进行分析

jmap用来查看堆内存使用状况，一般结合jhat使用。

jmap语法格式如下：

如果运行在64位JVM上，由于linux操作系统的不同，可能需要指定-J-d64命令选项参数。

 1、打印进程的类加载器和类加载器加载的持久代对象信息： jmap -permstat pid

个人感觉这个不是太有用

输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如图：

2、查看进程堆内存使用情况:包括使用的GC算法、堆配置参数和各代中堆内存使用：jmap -heap pid

比如下面的例子

 3、查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象：jmap -histo[:live] pid

class name是对象类型，说明如下:

4、还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。需要注意的是 dump出来的文件还可以用MAT、VisualVM等工具查看。

jmap进行dump命令格式如下：

 

我一样地对上面进程ID为2860进行Dump：

然后使用jhat来对上面dump出来的内容进行分析

   注意如果Dump文件太大，可能需要加上-J-Xmx512m参数以指定最大堆内存，即jhat -J-Xmx512m -port 8888 /home/dump.dat。然后就可以在浏览器中输入主机地址:8888查看了：

点击每一个蓝色的超链接，你都会看到其相关更具体的信息，而最后一项更是支持OQL（对象查询语言）。

四、jstat（JVM统计监测工具）: 看看各个区内存和GC的情况

语法格式如下：

vmid是Java虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为6：

要明白上面各列的意义，先看JVM堆内存布局：

可以看出：

现在来解释各列含义：

五、hprof（Heap/CPU Profiling Tool）：    hprof能够展现CPU使用率，统计堆内存使用情况。

HPROF: 一个Heap/CPU Profiling工具：J2SE中提供了一个简单的命令行工具来对java程序的cpu和heap进行 profiling，叫做HPROF。HPROF实际上是JVM中的一个native的库，它会在JVM启动的时候通过命令行参数来动态加载，并成为 JVM进程的一部分。若要在java进程启动的时候使用HPROF，用户可以通过各种命令行参数类型来使用HPROF对java进程的heap或者 （和）cpu进行profiling的功能。HPROF产生的profiling数据可以是二进制的，也可以是文本格式的。这些日志可以用来跟踪和分析 java进程的性能问题和瓶颈，解决内存使用上不优的地方或者程序实现上的不优之处。二进制格式的日志还可以被JVM中的HAT工具来进行浏览和分析，用 以观察java进程的heap中各种类型和数据的情况。在J2SE 5.0以后的版本中，HPROF已经被并入到一个叫做Java Virtual Machine Tool Interface（JVM TI）中。

语法格式如下：

完整的命令选项如下：

- Get sample cpu information every 20 millisec, with a stack depth of 3:

java -agentlib:hprof=cpu=samples,interval=20,depth=3 classname 
     - Get heap usage information based on the allocation sites: 
         java -agentlib:hprof=heap=sites classname

上面每隔20毫秒采样CPU消耗信息，堆栈深度为3，生成的profile文件名称是java.hprof.txt，在当前目录。

默认情况下，java进程profiling的信息（sites和dump）都会被 写入到一个叫做java.hprof.txt的文件中。大多数情况下，该文件中都会对每个trace，threads，objects包含一个ID，每一 个ID代表一个不同的观察对象。通常，traces会从300000开始。 默认，force=y，会将所有的信息全部输出到output文件中，所以如果含有 多个JVMs都采用的HRPOF enable的方式运行，最好将force=n，这样能够将单独的JVM的profiling信息输出到不同的指定文件。 interval选项只在 cpu=samples的情况下生效，表示每隔多少毫秒对java进程的cpu使用情况进行一次采集。 msa选项仅仅在Solaris系统下才有效， 表示会使用Solaris下的Micro State Accounting功能

第二部分： 实例部分：

该部分将使用相关的实例和前面提到的JVM性能调优工具来进行性能诊断。

1、使用jstack来分析死锁问题：

上面说明中提到 jstack主要用来查看某个Java进程内的线程堆栈信息,您可以使用它查明问题。jstack [-l] <pid>,pid可以通过使用jps命令来查看当前Java程序的pid值,-l是可选参数,它可以显示线程阻塞/死锁情况

以上DeadLock类是一个死锁的例子,假使在我们不知情的情况下,运行DeadLock后,发现等了N久都没有在屏幕打印线程完成信息。这个时候我们就可以使用jps查看该程序的pid值和使用jstack来生产堆栈结果问题。

结果文件deadlock.jstack内容如下：

从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。

可通过下面的代码解决死锁问题：

 2、继续使用jstack来分析HashMap在多线程情况下的死锁问题：

对于如下代码，使用10个线程来处理提交的2000个任务，每个任务会分别循环往hashmap中分别存入和取出1000个数，通过测试发现，程序并不能完整执行完成。[PS:该程序能不能成功执行完，有时也取决于所使用的服务器的运行状况，我在笔记本上测试的时候，大多时候该程序不能成功执行完成，有时会出现CPU转速加快，发热等情况]

1） 使用jps查看线程可得：

2）使用jstack导出多线程栈区信息：

3) hash.jstack的内容如下：

4）从红色高亮部分可看出，代码中的30行出问题了，即往hashmap中写入数据出问题了：

很快就明白因为Hashmap不是线程安全的，所以问题就出在这个地方，我们可以使用线程安全的map即

ConcurrentHashMap后者HashTable来解决该问题：

改成ConcurrentHashMap后，重新执行该程序，你会发现很快该程序就执行完了。