熟悉java的人都知道jdk的bin目录中有很多小工具，其中就包括用于监视虚拟机和故障处理的工具，今天就来仔细了解下各个工具的用法
jps
JVM Process Status Tool，用于显示指定系统的内所有的Hotapot的虚拟机进程
1.用法
jps [options] [hostid]
2.参数列表
q：只输出LVMID，省略主类的名称
m：输出虚拟机进程启动时传递给主类main()函数的参数
l：输出主类的全名。若进程执行的是jar包，则输出jar路径
v：输出虚拟机进程启动时JVM参数
3.实际举例：
1. jps -q ：只输出LVMID，省略主类的名称
2. jps -m：输出虚拟机进程启动时传递给主类main()函数的参数
3.jps -l:输出主类的全名。若进程执行的是jar包，则输出jar路径
4.jps -v：输出虚拟机进程启动时JVM参数
5.参数 vl一起：这样我们就能很方便的查看各个程序设定的参数了
jstat
Java Statisstic Monitoring Tool :一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量
1.用法
jstat [Options] vmid [interval] [count]
Options，选项，我们一般使用 -gcutil 查看gc情况
vmid，VM的进程号，即当前运行的java进程号
interval，间隔时间，单位为秒或者毫秒
count，打印次数，如果缺省则打印无数次
2.参数列表
jstat -class pid:显示加载class的数量，及所占空间等信息。 jstat -compiler pid:显示VM实时编译的数量等信息。 jstat -gc pid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。 jstat -gccapacity:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推， OC是old内纯的占用量。 jstat -gcnew pid:new对象的信息。 jstat -gcnewcapacity pid:new对象的信息及其占用量。 jstat -gcold pid:old对象的信息。 jstat -gcoldcapacity pid:old对象的信息及其占用量。 jstat -gcpermcapacity pid: perm对象的信息及其占用量。 jstat -util pid:统计gc信息统计。 jstat -printcompilation pid:当前VM执行的信息。 除了以上一个参数外，还可以同时加上 两个数字，如：jstat -printcompilation 3024 250 6是每250毫秒打印一次，一共打印6次，还可以加上-h3每三行显示一下标题。
3.实际举例
1. -gc：监视java堆状况
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden的容量 (字节)
EU：年轻代中Eden目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
2.-gcutil：与-gc基本相同，但输出的是已使用空间占总空间的大小
jinfo
Configuration Info for Java：实时的查看和调整虚拟机各项参数
1.用法：
jinfo [option] <pid>
2.参数：
jinfo 主要就是flag参数了，上图已经解释的很清楚了，这里直接做演示好了
3.实际举例
1.获取进程30018的SurvivorRatio信息
2.获取进程30018 所有的jvm信息
这个命令比jps -v更加详细
jmap
打印出某个java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。 可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成 文本。使用方法 jmap -histo pid。如果连用SHELL jmap -histo pid>a.log 可以将其保存到文本中去，在一段时间后，使用文本对比工具，可以对比出GC 回收了哪些对象。jmap -dump:format=b,file=outfile 3024可以将3024进 程的内存heap输出出来到outfile文件里，再配合MAT（内存分析工具(Memory Analysis Tool）或与jhat (Java Heap Analysis Tool)一起使用， 能够以图像的形式直观的展示当前内存是否有问题。
1.用法
jmap [option] <pid>
2.参数
1)、options： executable Java executable from which the core dump was produced. (可能是产生core dump的java可执行程序) core 将被打印信息的core dump文件 remote-hostname-or-IP 远程debug服务的主机名或ip server-id 唯一id,假如一台主机上多个远程debug服务 2）、基本参数： -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子参数无效. -h | -help 打印辅助信息 -J 传递参数给jmap启动的jvm. pid 需要被打印配相信息的java进程id
3.实际举例
1.jmap -heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.
Heap Configuration: //堆内存初始化配置
MinHeapFreeRatio = 0 //对应jvm启动参数-XX:MinHeapFreeRatio设置JVM堆最小空闲比率(default 40)
MaxHeapFreeRatio = 100 //对应jvm启动参数 -XX:MaxHeapFreeRatio设置JVM堆最大空闲比率(default 70)
MaxHeapSize = 2082471936 (1986.0MB) //对应jvm启动参数-XX:MaxHeapSize=设置JVM堆的最大大小
NewSize = 1310720 (1.25MB)//对应jvm启动参数-XX:NewSize=设置JVM堆的‘新生代’的默认大小
MaxNewSize = 17592186044415 MB//对应jvm启动参数-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小
OldSize = 5439488 (5.1875MB)//对应jvm启动参数-XX:OldSize=<value>:设置JVM堆的‘老生代’的大小
NewRatio = 2 //对应jvm启动参数-XX:NewRatio=:‘新生代’和‘老生代’的大小比率
SurvivorRatio = 8 //对应jvm启动参数-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值
PermSize = 21757952 (20.75MB) //对应jvm启动参数-XX:PermSize=<value>:设置JVM堆的‘永生代’的初始大小
MaxPermSize = 85983232 (82.0MB)//对应jvm启动参数-XX:MaxPermSize=<value>:设置JVM堆的‘永生代’的最大大小
G1HeapRegionSize = 0 (0.0MB)
Heap Usage://堆内存使用情况
PS Young Generation
Eden Space://Eden区内存分布
capacity = 33030144 (31.5MB)//Eden区总容量
used = 1524040 (1.4534378051757812MB) //Eden区已使用
free = 31506104 (30.04656219482422MB) //Eden区剩余容量
4.614088270399305% used //Eden区使用比率
From Space: //其中一个Survivor区的内存分布
capacity = 5242880 (5.0MB)
used = 0 (0.0MB)
free = 5242880 (5.0MB)
0.0% used
To Space: //另一个Survivor区的内存分布
capacity = 5242880 (5.0MB)
used = 0 (0.0MB)
free = 5242880 (5.0MB)
0.0% used
PS Old Generation //当前的Old区内存分布
capacity = 86507520 (82.5MB)
used = 0 (0.0MB)
free = 86507520 (82.5MB)
0.0% used
PS Perm Generation//当前的 “永生代” 内存分布
capacity = 22020096 (21.0MB)
used = 2496528 (2.3808746337890625MB)
free = 19523568 (18.619125366210938MB)
11.337498256138392% used
这个命令非常直观的显示了JVM各个区域的生存情况，线上内存出现异常可以先用这个命令做一个大致的了解
2.jmap -histo：
这个命令会把所有的类都打出来，并按占用内存的大小进行排序
jmap -histo:live 10765 | more
加上live参数只会打印存活的对象
3.jmap -dump:
解释下 jmap -F -dump:format=b,file=payment.bin 30018： 使用hprof二进制形式,输出进程为30018的jvm的heap内容到文件payment.bin
jhat
是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言
我们现在来分析下上文产生的payment.bin
用浏览器访问http://localhost:7000/，会发现所有的类按包名进行分类，我们可以访问底部的这个标签，看到的内容和jmap -histo：是一样的
jstack
用于生成java虚拟机当前时刻的线程快照
1.用法
jstack [-l] <pid>
2.参数
3.用法
获取到各个线程的状态后，主要有以下几个注意点
死锁， Deadlock（重点关注）:死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。
执行中，Runnable
等待资源， Waiting on condition（重点关注） :
该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读 写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
等待获取监视器， Waiting on monitor entry（重点关注）
暂停，Suspended
对象等待中，Object.wait() 或 TIMED_WAITING
阻塞， Blocked（重点关注）
停止，Parked
参考
http://www.cnblogs.com/ggjucheng/archive/2013/04/16/3024986.html
http://blog.csdn.net/zlzlei/article/details/46471627
http://www.ccblog.cn/84.htm