熟悉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