（转自：http://yhjhappy234.blog.163.com/blog/static/31632832201222691738865/）
我们知道，在JVM编译期和加载器，甚至运行期已经做了大量的调优操作，但是那些都是JVM针对Java程序所做的通用的、简单的优化，程序在运行时由于运行环境的复杂性、业务逻辑的复杂性，很多JVM是无法进行优化处理的，这就需要我们自己在写代码的时候就注意，以便我们的程序在特定的业务场景发挥到最佳性能。
要进行性能调优，首先我们要找到程序的性能瓶颈在哪里？而要知道性能瓶颈在哪里，我们需要借助一定的工具进行处理。
在windows操作系统下，当我们的系统运行很慢的时候，80%的人首先查看的就是任务管理器，因为它可以让我们快读的知道是那个程序占用了较多的资源（如CPU、内存、磁盘IO等），或者是那个进程不能响应导致整个操作系统巨卡，我们通过任务管理器可以轻松的查看和管理我们的应用程序，如下图所示：
而从windowsVista内核以后（win7、win8、win2008等OS），windows操作系统还提供了更为详细的一个资源监视器，它可以让我们更清晰的知道更多的细节信息，在资源管理器上有一个资源监视器的入口，如下图所示
打开对应的资源监视器，如下图所示：
概述
tab页面我们可以大致的看到对应的进程信息，哪些进程占用了多少的资源等信息，而对应的CPU、内存、磁盘、网络则更详细的展示了具体的信息，如下图所示，磁盘的信息，哪些进程在操作哪些个文件，磁盘的队列有多少？都一目了然。
以上是
windows自带的一些监控工具，当然我们知道面向windows的监控工具比比皆是，我在这里就不多说了。
而我们的服务器大部分是运行在Linux下，如我们现在的服务器使用的是CentOS5.5的操作系统(Linux2.6内核)，那在Linux下都有哪些工具可以使用的呢？
在Linux下使用的最频繁的一个命令是top，如下图所示
这个就相当于
windows下的任务管理器，能够简单的描述每个进程占用的资源信息，包含CPU、磁盘、内存等信息，按1可以将CPU拆解，看单个CPU的运行信息。使用ps –ef | grep 进程名可以查看对应进程的简单信息，如ps –ef|grep java，如下图所示：
当然，针对我们
Java开发人员，这一点是远远不够的，我们还需要更详细的信息。Linux工具集SysStat（下载地址：http://sebastien.godard.pagesperso-orange.fr/download.html）为我们提供了一系列指令集，我们在寻找下面会提到，但其实JDK已经为我们提供了很多很好的针对Java的性能监控工具，下面我们就来一起看一下JDK都为我们提供了哪些性能检测工具。
一、Jps（JVM Process Status Tools）
Jps是参照Unix系统的取名规则命名的，而他的功能和ps的功能类似，可以列举正在运行的饿虚拟机进程并显示虚拟机执行的主类以及这些进程的唯一ID（ＬＶＭＩＤ，对应本机来说和PID相同），他的用法如下：
Jps [option] [hostid]
其中hostid默认为本机，而option选项包含以下选项
|
Option |
Function |
|
-q |
只输出LVMID |
|
-m |
输出JVM启动时传给主类的方法 |
|
-l |
输出主类的全名，如果是Jar则输出jar的路径 |
|
-v |
输出JVM的启动参数 |
二、
jstat（JVM Statistics Monitoring Tools）
Jstat主要用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上，这款工具是首选的一款监控工具。其用法如下：
jstat [option vmid [interval [s|ms] [vount] ] ]
参数interval和count分别表示查询间隔和查询次数，如每1毫秒查询一次进程20445的垃圾回收情况，监控20次，命令如下所示：
jstat –gc 20445 1 20
相关的输出参数介绍可参照
选项option代表用户需要查询的虚拟机的信息，主要分为3类：类装载、垃圾回收和运行期的编译情况，具体如下表所示：
|
Option |
Function |
|
-class |
监视类的装载、卸载数量以及类的装载总空间和耗费时间等 |
|
-gc |
监视Java堆，包含eden、2个survivor区、old区和永久带区域的容量、已用空间、GC时间合计等信息 |
|
-gccapcity |
监视内容与-gc相同，但输出主要关注Java区域用到的最大和最小空间 |
|
-gcutil |
监视内容与-gc相同，但输出主要关注已使用空间占总空间的百分比 |
|
-gccause |
与-gcutil输出信息相同，额外输出导致上次GC产生的原因 |
|
-gcnew |
监控新生代的GC情况 |
|
-gcnewcapacity |
与-gcnew监控信息相同，输出主要关注使用到的最大和最小空间 |
|
-gcold |
监控老生代的GC情况 |
|
-gcoldcapacity |
与-gcold监控信息相同，输出主要关注使用到的最大和最小空间 |
|
-gcpermcapacity |
输出永久带用到的最大和最小空间 |
|
-compiler |
输出JIT编译器编译过的方法、耗时信息 |
|
-printcompilation |
输出已经被JIT编译的方法 |
三、jinfo（JVM configuration Info for Java）
Jinfo的作用是实时查看虚拟机的各项参数信息jps –v可以查看虚拟机在启动时被显式指定的参数信息，但是如果你想知道默认的一些参数信息呢？除了去查询对应的资料以外，jinfo就显得很重要了。jinfo的用法如下：
Jinfo [option] pid
如 jinfo –sysprops {pid}
…
还有很多参数信息，我们可以看到除了我们显式指定的参数信息以外，JVM的默认参数一览无余。同时，从JDK1.6以后，jinfo加入了运行时修改参数信息的能力，可以使用-flag [+|-]name 或者-flag name=value来修改一部分运行期可以写入的虚拟机参数。更多信息可参考官方文档。
四、jmap（JVM Memory Map for Java）
Jmap用于生成堆快照（heapdump）。当然我们有很多方法可以取到对应的dump信息，如我们通过JVM启动时加入启动参数 –XX:HeapDumpOnOutOfMemoryError参数，可以让JVM在出现内存溢出错误的时候自动生成dump文件，亦可以通过-XX:HeapDumpOnCtrlBreak参数，在运行时使用ctrl+break按键生成dump文件，当然我们也可以使用kill -3 pid的方式去恐吓JVM生成dump文件。Jmap的作用不仅仅是为了获取dump文件，还可以用于查询finalize执行队列、Java堆和永久带的详细信息，如空间使用率、垃圾回收器等。其运行格式如下：
Jmap [option] vmip
Option的信息如下表所示
|
Option |
Function |
|
-dump |
生成对应的dump信息，用法为-dump:[live,]format=b,file={fileName} |
|
-finalizerinfo |
显示在F-Queue中等待的Finalizer方法的对象（只在linux下生效） |
|
-heap |
显示堆的详细信息、垃圾回收器信息、参数配置、分代详情等 |
|
-histo |
显示堆栈中的对象的统计信息，包含类、实例数量和合计容量 |
|
-permstat |
以ClassLoder为统计口径显示永久带的内存状态 |
|
-F |
当虚拟机对-dump无响应时可使用这个选项强制生成dump快照 |
示例：jmap -dump:format=b,file=yhj.dump 20445
五、
jhat（JVM Heap Analysis Tool）
Jhat是用来分析dump文件的一个微型的HTTP/HTML服务器，它能将生成的dump文件生成在线的HTML文件，让我们可以通过浏览器进行查阅，然而实际中我们很少使用这个工具，因为一般服务器上设置的堆、栈内存都比较大，生成的dump也比较大，直接用jhat容易造成内存溢出，而是我们大部分会将对应的文件拷贝下来，通过其他可视化的工具进行分析。启用法如下：
Jhat {dump_file}
执行命令后，我们看到系统开始读取这段dump信息，当系统提示Server is ready的时候，用户可以通过在浏览器键入http://ip地址:7000进行查询。
我们可以看到刚才生成的dump文件有多大
我们来生成以下看看！
jhat yhj.dump
//……..
然后我们启动浏览器查看
我们可以看到，很详细的类信息都被抓了出来
六、
jstack（JVM Stack Trace for java）
Jstack用于JVM当前时刻的线程快照，又称threaddump文件，它是JVM当前每一条线程正在执行的堆栈信息的集合。生成线程快照的主要目的是为了定位线程出现长时间停顿的原因，如线程死锁、死循环、请求外部时长过长导致线程停顿的原因。通过jstack我们就可以知道哪些进程在后台做些什么？在等待什么资源等！其运行格式如下：
Jstack [option] vmid
相关的option和function如下表所示
|
Option |
Function |
|
-F |
当正常输出的请求不响应时强制输出线程堆栈 |
|
-l |
除堆栈信息外，显示关于锁的附加信息 |
|
-m |
显示native方法的堆栈信息 |
示例：jstack -l 20445
从
JDK1.5以后，java.lang.Thread类增加了一个getAllStackTraces()方法用于获取虚拟机中的StackTraceElement对象，使用这段代码我们可以通过很简单的代码获取对应JVM的信息，下面是一个简单的示例：
package com.yhj.monitor; import java.util.Map; import java.util.Set; /** * @Described：线程监控器 * @author YHJ create at 2012-3-26 下午05:20:18 * @FileNmae com.yhj.monitor.Threadmonitor.java */ public class Threadmonitor { public static void main(String[] args) { Map<Thread, StackTraceElement[]> map = Thread.getAllStackTraces(); Set<Thread> set = map.keySet(); for(Thread thread : set){ System.out.println("检测到线程 ["+thread.getId()+":"+thread.getName()+"],线程详细信息："); for(StackTraceElement trace:map.get(thread)){ System.out.println(trace); } } } }
一次运行结果如下：
如果我们把这个写入一个
web工程的一个监控页面上，一个小的监控线程的程序就有了， ！
介绍了前面几个命令，大家也许还在担心如何记住这么多详细的参数，其实JDK为我们提供了更为强大的GUI的监控工具，囊括了上面所有的监控工具的功能，同时还增加了很多工具方便我们的故障分析与性能监控！
从JDK1.5开始，JDK加入了可视化监控工具Jconsole，而从JDK1.6u7以后加了了多功能于一体的可视化监控工具VisualVM。下面我们来逐一看一下！
一、JConsole（JVM Monitoring and management console）
在JDK的bin目录下，我们很容易找到jconsole.exe这个程序，双击即可启动！
这款工具既可以实现本地监控，亦可以实现远程监控
.
启动后界面如图所示：
我们可以清楚的查看对应的
CPu、内存、类和一起其他的详细信息。
在内存的tab页面，我们可以看到内存的变化。
在线程
tab，我们可以追踪对应线程的变化情况
package com.yhj.monitor; /** * @Described：死锁演示 * @author YHJ create at 2012-3-26 下午05:46:36 * @FileNmae com.yhj.monitor.Deadlock.java */ public class Deadlock implements Runnable{ private int a; private int b; public Deadlock(int a, int b) { super(); this.a = a; this.b = b; } @Override public void run() { synchronized (Integer.valueOf(a)) { synchronized (Integer.valueOf(b)) { System.out.println("a+b="+(a+b)); } } } public static void main(String[] args) { for(int i = 0; i < 1000; ++i){ new Thread(new Deadlock(1, 2)).start(); new Thread(new Deadlock(2, 1)).start(); } } }
这段代码执行一段时间你会发现他不动了，如下图所示：
我们使用
Jconsole的线程tab，下面有一个检测死锁的按钮，点击一下
Jconsole很清楚的告诉我们发生了死锁，如上图所示。并且明确的告诉我们死锁线程每个线程都在干什么？什么资源导致了死锁的发生，很精确。
很多人还在迷惑，上段代码怎么可能发生死锁的？每个线程独享一个a和一个b，互不相干，怎么可能发生死锁呢？
其实发生死锁的原因是我们调用了Integer.valueOf()方法，这个方法是基于减少创建对象次数和节省内存设计的，出于这个的考虑，在[-128~127]之间的数字会被缓存掉，也就是我们循环中传输了那么多的1和2其实就返回的2个，当某个对象持有1，而另外一个对象持有2的时候，第一个等待2的释放，而第二个等待1的释放，因此就发生了死锁。其实这个程序的循环也是不需要的，2个线程就可能引发死锁，但是程序执行太快，概率太小，加一个1000次的循环就是为了增大这种概率。
二、VisualVM
VisualVM被成为是more in one的工具集，它可以实现以下功能点：
1、 显示虚拟机的进程以及进程的配置信息和环境信息(jps、jinfo)
2、 监视应用程序的CPU、内存、堆、方法区和线程信息(jstat、jstack)
3、 Dump以及分析dump的功能(jmap、jhat)
4、 离线程序快照：离线dump分析
5、 方法运行性能分析，找出调用最多，运行最长的方法块
6、 Plugings动态扩展功能
VisualVM因为是基于netBean开发，因此天生就具有plug大量扩展的能力，我们可以通过他的插件页面轻松安装所需要的插件！
启用VisualVM工具会很醒目的告诉我们检测到一个死锁，而不需要我们在Jconsole下手动启用检测。如下图所示：
VisualVM
的插件安装图示如下图所示：
在
VisualVM中有一个开源的，强大的插件，叫做BTrace。这是一个很有意思的插件，假设这么一种场景，某天你的程序突然出现了某个差错，但是有没有写日志，怎么办呢？BTrace就可以通过简单的代码注入，在你不重启服务器的情况下动态加入相关的日志语句。相关示例请参见官方DEMO：https://hg.kenai.com/hg/btrace~hg/file/d31d25ebd48b/samples。
