Java命令學習
1、jps
功能
jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一個顯示當前所有java程序pid的命令，簡單實用，非常適合在linux/unix平臺上簡單察看當前java程序的一些簡單情況。
原理
jdk中的jps命令可以顯示當前執行的java程序以及相關引數，它的實現機制如下：
java程式在啟動以後，會在java.io.tmpdir指定的目錄下，就是臨時資料夾裡，生成一個類似於hsperfdata_User的資料夾，這個資料夾裡（在windows中為C:\Users\dup\AppData\Local\Temp\hsperfdat_user），有幾個檔案，名字就是java程序的pid，因此列出當前執行的java程序，只是把這個目錄裡的檔名列一下而已。 至於系統的引數什麼，就可以解析這幾個檔案獲得。
上面的內容就是我機器中C:\Users\dup\AppData\Local\Temp\hsperfdat_user目錄下的內容，其中9160就是我機器上當前執行中的java的程序的pid，我們執行jps驗證一下：
執行了jps命令之後，我們發現有兩個java程序，一個是pid為9160的myeclipse執行的程序，另外一個是pid為10176的jps使用的程序（他也是java命令，也要開一個程序）
使用
想要學習一個命令，先來看看幫助，使用jps -help檢視幫助：
接下來，為了詳細介紹這些引數，我們編寫幾個類，在main方法裡寫一個while(true)的迴圈，檢視java程序情況。程式碼如下：
package com.JavaCommand;
/**
* @author dup
*/
public class JpsDemo {
public static void main(String[] args) {
while(true){
System.out.println(1);
}
}
}-q 只顯示pid，不顯示class名稱,jar檔名和傳遞給main 方法的引數
-m 輸出傳遞給main 方法的引數，在嵌入式jvm上可能是null， 在這裡，在啟動main方法的時候，我給String[] args傳遞兩個引數。hollis,chuang,執行jsp -m
-l 輸出應用程式main class的完整package名 或者 應用程式的jar檔案完整路徑名
-v 輸出傳遞給JVM的引數 在這裡，在啟動main方法的時候，我給jvm傳遞一個引數：-Dfile.encoding=UTF-8,執行jps -v：
PS:jps命令有個地方很不好，似乎只能顯示當前使用者的java程序，要顯示其他使用者的還是隻能用unix/linux的ps命令
JPS失效處理
現象： 用ps -ef|grep java能看到啟動的java程序，但是用jps檢視卻不存在該程序的id。待會兒解釋過之後就能知道在該情況下，jconsole、jvisualvm可能無法監控該程序，其他java自帶工具也可能無法使用
分析： jps、jconsole、jvisualvm等工具的資料來源就是這個檔案（C:\Users\dup\AppData\Local\Temp\hsperfdat_user\pid)。所以當該檔案不存在或是無法讀取時就會出現jps無法檢視該程序號，jconsole無法監控等問題
原因：
（1）、磁碟讀寫、目錄許可權問題 若該使用者沒有許可權寫C:\Users\dup\AppData\Local\Temp\hsperfdat_user\pid目錄或是磁碟已滿，則無法建立C:\Users\dup\AppData\Local\Temp\hsperfdat_user\pid\pid檔案。或該檔案已經生成，但使用者沒有讀許可權
（2）、臨時檔案丟失，被刪除或是定期清理 對於linux機器，一般都會存在定時任務對臨時資料夾進行清理，導致/tmp目錄被清空。這也是我第一次碰到該現象的原因。常用的可能定時刪除臨時目錄的工具為crontab、redhat的tmpwatch、ubuntu的tmpreaper等等
這個導致的現象可能會是這樣，用jconsole監控程序，發現在某一時段後進程仍然存在，但是卻沒有監控資訊了。
（3）、java程序資訊檔案儲存地址被設定，不在C:\Users\dup\AppData\Local\Temp\hsperfdat_user\目錄下 上面我們在介紹時說預設會在C:\Users\dup\AppData\Local\Temp\hsperfdat_user\目錄儲存程序資訊，但由於以上1、2所述原因，可能導致該檔案無法生成或是丟失，所以java啟動時提供了引數(-Djava.io.tmpdir)，可以對這個檔案的位置進行設定，而jps、jconsole都只會從C:\Users\dup\AppData\Local\Temp\hsperfdat_user目錄讀取，而無法從設定後的目錄讀物資訊，這是我第二次碰到該現象的原因
2、jstack
功能
jstack用於生成java虛擬機器當前時刻的執行緒快照。執行緒快照是當前java虛擬機器內每一條執行緒正在執行的方法堆疊的集合，生成執行緒快照的主要目的是定位執行緒出現長時間停頓的原因，如執行緒間死鎖、死迴圈、請求外部資源導致的長時間等待等。 執行緒出現停頓的時候通過jstack來檢視各個執行緒的呼叫堆疊，就可以知道沒有響應的執行緒到底在後臺做什麼事情，或者等待什麼資源。 如果java程式崩潰生成core檔案，jstack工具可以用來獲得core檔案的java stack和native stack的資訊，從而可以輕鬆地知道java程式是如何崩潰和在程式何處發生問題。另外，jstack工具還可以附屬到正在執行的java程式中，看到當時執行的java程式的java stack和native stack的資訊, 如果現在執行的java程式呈現hung的狀態，jstack是非常有用的。jstack命令主要用來檢視Java執行緒的呼叫堆疊的，可以用來分析執行緒問題（如死鎖）。
執行緒狀態
想要通過jstack命令來分析執行緒的情況的話，首先要知道執行緒都有哪些狀態，下面這些狀態是我們使用jstack命令檢視執行緒堆疊資訊時可能會看到的執行緒的幾種狀態：
NEW,未啟動的。不會出現在Dump中。
RUNNABLE,在虛擬機器內執行的。
BLOCKED,受阻塞並等待監視器鎖。
WATING,無限期等待另一個執行緒執行特定操作。
TIMED_WATING,有時限的等待另一個執行緒的特定操作。
TERMINATED,已退出的。
Monitor
在多執行緒的 JAVA程式中，實現執行緒之間的同步，就要說說 Monitor。 Monitor是 Java中用以實現執行緒之間的互斥與協作的主要手段，它可以看成是物件或者 Class的鎖。每一個物件都有，也僅有一個 monitor。下 面這個圖，描述了執行緒和 Monitor之間關係，以 及執行緒的狀態轉換圖：
進入區(Entrt Set):表示執行緒通過synchronized要求獲取物件的鎖。如果物件未被鎖住,則進入擁有者;否則則在進入區等待。一旦物件鎖被其他執行緒釋放,立即參與競爭。
擁有者(The Owner):表示某一執行緒成功競爭到物件鎖。
等待區(Wait Set):表示執行緒通過物件的wait方法,釋放物件的鎖,並在等待區等待被喚醒。
從圖中可以看出，一個 Monitor在某個時刻，只能被一個執行緒擁有，該執行緒就是 “Active Thread”，而其它執行緒都是“Waiting Thread”，分別在兩個佇列 “ Entry Set”和 “Wait Set”裡面等候。在 “Entry Set”中等待的執行緒狀態是“Waiting for monitor entry”，而在 “Wait Set”中等待的執行緒狀態是 “in Object.wait()”。 先看 “Entry Set”裡面的執行緒。我們稱被 synchronized保護起來的程式碼段為臨界區。當一個執行緒申請進入臨界區時，它就進入了 “Entry Set”佇列。對應的 code就像：
synchronized(obj) {
.........
}呼叫修飾
表示執行緒在方法呼叫時,額外的重要的操作。執行緒Dump分析的重要資訊。修飾上方的方法呼叫。
locked <地址> 目標：使用synchronized申請物件鎖成功,監視器的擁有者。
waiting to lock <地址> 目標：使用synchronized申請物件鎖未成功,在迚入區等待。
waiting on <地址> 目標：使用synchronized申請物件鎖成功後,釋放鎖幵在等待區等待。
parking to wait for <地址> 目標
locked
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at com.jiuqi.dna.core.internal.db.datasource.PooledConnection.prepareStatement通過synchronized關鍵字,成功獲取到了物件的鎖,成為監視器的擁有者,在臨界區內操作。物件鎖是可以執行緒重入的。
waiting to lock
at com.jiuqi.dna.core.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)
at com.jiuqi.dna.core.impl.CacheGroup$Index.findHolder
at com.jiuqi.dna.core.impl.ContextImpl.find
at com.jiuqi.dna.bap.basedata.common.util.BaseDataCenter.findInfo通過synchronized關鍵字,沒有獲取到了物件的鎖,執行緒在監視器的進入區等待。在呼叫棧頂出現,執行緒狀態為Blocked。
waiting on
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo
- locked <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run通過synchronized關鍵字,成功獲取到了物件的鎖後,呼叫了wait方法,進入物件的等待區等待。在呼叫棧頂出現,執行緒狀態為WAITING或TIMED_WATING。
parking to wait for
park是基本的執行緒阻塞原語,不通過監視器在物件上阻塞。隨concurrent包會出現的新的機制,不synchronized體系不同。
執行緒動作
執行緒狀態產生的原因
runnable:狀態一般為RUNNABLE。
in Object.wait():等待區等待,狀態為WAITING或TIMED_WAITING。
waiting for monitor entry:進入區等待,狀態為BLOCKED。
waiting on condition:等待區等待、被park。
sleeping:休眠的執行緒,呼叫了Thread.sleep()。
Wait on condition 該狀態出現線上程等待某個條件的發生。具體是什麼原因，可以結合 stacktrace來分析。 最常見的情況就是執行緒處於sleep狀態，等待被喚醒。 常見的情況還有等待網路IO：在java引入nio之前，對於每個網路連線，都有一個對應的執行緒來處理網路的讀寫操作，即使沒有可讀寫的資料，執行緒仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給作業系統的執行緒排程也帶來壓力。在 NewIO裡採用了新的機制，編寫的伺服器程式的效能和可擴充套件性都得到提高。 正等待網路讀寫，這可能是一個網路瓶頸的徵兆。因為網路阻塞導致執行緒無法執行。一種情況是網路非常忙，幾 乎消耗了所有的頻寬，仍然有大量資料等待網路讀 寫；另一種情況也可能是網路空閒，但由於路由等問題，導致包無法正常的到達。所以要結合系統的一些效能觀察工具來綜合分析，比如 netstat統計單位時間的傳送包的數目，如果很明顯超過了所在網路頻寬的限制 ; 觀察 cpu的利用率，如果系統態的 CPU時間，相對於使用者態的 CPU時間比例較高；如果程式執行在 Solaris 10平臺上，可以用 dtrace工具看系統呼叫的情況，如果觀察到 read/write的系統呼叫的次數或者執行時間遙遙領先；這些都指向由於網路頻寬所限導致的網路瓶頸。http://www.blogjava.net/jzone/articles/303979.html
執行緒Dump的分析
原則
結合程式碼閱讀的推理。需要執行緒Dump和原始碼的相互推導和印證。
造成Bug的根源往往會在呼叫棧上直接體現,一定格外注意執行緒當前呼叫之前的所有呼叫。
入手點
進入區等待
執行緒狀態BLOCKED,執行緒動作wait for monitor entry,呼叫修飾waiting to lock總是一起出現。表示在程式碼級別已經存在衝突的呼叫。必然有問題的程式碼,需要儘可能減少其發生。
同步塊阻塞
一個執行緒鎖住某物件,大量其他執行緒在該物件上等待。
持續執行的IO IO操作是可以以RUNNABLE狀態達成阻塞。例如:資料庫死鎖、網路讀寫。 格外注意對IO執行緒的真實狀態的分析。 一般來說,被捕捉到RUNNABLE的IO呼叫,都是有問題的。
分執行緒排程的休眠
正常的執行緒池等待
"d&a-131" in Object.wait()
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo(WorkingManager.java:322)
- locked <0x0000000313f656f8> (a com.jiuqi.dna.core.impl.WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run(WorkingThread.java:40)可疑的執行緒等待
"d&a-121" in Object.wait()
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.jiuqi.dna.core.impl.AcquirableAccessor.exclusive()
- locked <0x00000003011678d8> (a com.jiuqi.dna.core.impl.CacheGroup)
at com.jiuqi.dna.core.impl.Transaction.lock()入手點總結
wait on monitor entry： 被阻塞的,肯定有問題
runnable ： 注意IO執行緒
in Object.wait()： 注意非執行緒池等待
使用
首先，我們分析這麼一段程式的執行緒情況：
package com.test;
public class JstackDemo {
public static void main(String[] args) {
while (true) {
//Do Nothing
}
}
}
先是有jps檢視程序號：
然後使用jstack 檢視堆疊資訊：
我們可以從這段堆疊資訊中看出什麼來呢？我們可以看到，當前一共有一條使用者級別執行緒,執行緒處於runnable狀態，執行到JStackDemo1.java的第5行。 看下面程式碼：
package com.test;
public class JstackDemo1 {
public static void main(String[] args) {
Thread thread = new Thread(new Thread1());
thread.start();
}
}
class Thread1 implements Runnable{
@Override
public void run() {
synchronized (Thread1.class) {
while(true){
System.out.println(1);
try {
Thread1.class.wait();
} catch (InterruptedException e) {
}
}
}
}
}執行緒堆疊資訊如下：
我們能看到：
執行緒的狀態： WAITING 執行緒的呼叫棧 執行緒的當前鎖住的資源： <0x04b9b7f0> 執行緒當前等待的資源：<0x04b9b7f0>
為什麼同時鎖住的等待同一個資源：
執行緒的執行中，先獲得了這個物件的 Monitor（對應於 locked <0x04b9b7f0>）。當執行到 obj.wait(), 執行緒即放棄了 Monitor的所有權，進入 “wait set”佇列（對應於 waiting on <0x04b9b7f0> ）
死鎖分析
學會了怎麼使用jstack命令之後，我們就可以看看，如何使用jstack分析死鎖了，這也是我們一定要掌握的內容。 啥叫死鎖？ 所謂死鎖： 是指兩個或兩個以上的程序在執行過程中，由於競爭資源或者由於彼此通訊而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序稱為死鎖程序。 說白了，我現在想吃雞蛋灌餅，桌子上放著雞蛋和餅，但是我和我的朋友同時分別拿起了雞蛋和病，我手裡拿著雞蛋，但是我需要他手裡的餅。他手裡拿著餅，但是他想要我手裡的雞蛋。就這樣，如果不能同時拿到雞蛋和餅，那我們就不能繼續做後面的工作（做雞蛋灌餅）。所以，這就造成了死鎖。 看一段死鎖的程式：
package com.test;
public class JstackDemo2 {
public static void main(String[] args) {
Thread t1 = new Thread(new DeadLockclass(true));//建立一個執行緒
Thread t2 = new Thread(new DeadLockclass(false));//建立另一個執行緒
t1.start();//啟動一個執行緒
t2.start();//啟動另一個執行緒
}
}
class DeadLockclass implements Runnable {
public boolean falg;// 控制執行緒
DeadLockclass(boolean falg) {
this.falg = falg;
}
public void run() {
/**
* 如果falg的值為true則呼叫t1執行緒
*/
if (falg) {
while (true) {
synchronized (Suo.o1) {
System.out.println("o1 " + Thread.currentThread().getName());
synchronized (Suo.o2) {
System.out.println("o2 " + Thread.currentThread().getName());
}
}
}
}
/**
* 如果falg的值為false則呼叫t2執行緒
*/
else {
while (true) {
synchronized (Suo.o2) {
System.out.println("o2 " + Thread.currentThread().getName());
synchronized (Suo.o1) {
System.out.println("o1 " + Thread.currentThread().getName());
}
}
}
}
}
}
class Suo {
static Object o1 = new Object();
static Object o2 = new Object();
}當我啟動該程式時，我們看一下控制檯：
我們發現，程式只輸出了兩行內容，然後程式就不再列印其它的東西了，但是程式並沒有停止。這樣就產生了死鎖。 當執行緒1使用synchronized鎖住了o1的同時，執行緒2也是用synchronized鎖住了o2。當兩個執行緒都執行完第一個列印任務的時候，執行緒1想鎖住o2，執行緒2想鎖住o1。但是，執行緒1當前鎖著o1，執行緒2鎖著o2。所以兩個想成都無法繼續執行下去，就造成了死鎖。
然後，我們使用jstack來看一下執行緒堆疊資訊：
哈哈，堆疊寫的很明顯，它告訴我們 Found one Java-level deadlock，然後指出造成死鎖的兩個執行緒的內容。然後，又通過 Java stack information for the threads listed above來顯示更詳細的死鎖的資訊。
3、Jmap
什麼是堆Dump
堆Dump是反應Java堆使用情況的記憶體映象，其中主要包括系統資訊、虛擬機器屬性、完整的執行緒Dump、所有類和物件的狀態等。 一般，在記憶體不足、GC異常等情況下，我們就會懷疑有記憶體洩露。這個時候我們就可以製作堆Dump來檢視具體情況。分析原因。
基礎知識
常見記憶體錯誤：
outOfMemoryError 年老代記憶體不足。
outOfMemoryError:PermGen Space 永久代記憶體不足。
outOfMemoryError:GC overhead limit exceed 垃圾回收時間佔用系統執行時間的98%或以上。
jmap用法
C:\Users\dup>jmap -help
Usage:
jmap [option] <pid>
(to connect to running process)
jmap [option] <executable <core>
(to connect to a core file)
jmap [option] [[email protected]]<remote server IP or hostname>
(to connect to remote debug server)
where <option> is one of:
<none> to print same info as Solaris pmap
-heap to print java heap summary
-histo[:live] to print histogram of java object heap; if the "live"
suboption is specified, only count live objects
-clstats to print class loader statistics
-finalizerinfo to print information on objects awaiting finalization
-dump:<dump-options> to dump java heap in hprof binary format
dump-options:
live dump only live objects; if not specified
,
all objects in the heap are dumped.
format=b binary format
file=<file> dump heap to <file>
Example: jmap -dump:live,format=b,file=heap.bin <pid>
-F force. Use with -dump:<dump-options> <pid> or -histo
to force a heap dump or histogram when <pid> does not
respond. The "live" suboption is not supported
in this mode.
-h | -help to print this help message
-J<flag> to pass <flag> directly to the runtime system引數：
option 選項引數是互斥的(不可同時使用)。想要使用選項引數，直接跟在命令名稱後即可。
pid 需要列印配置資訊的程序ID。該程序必須是一個Java程序。想要獲取執行的Java程序列表，你可以使用jps。
executable 產生核心dump的Java可執行檔案。
core 需要列印配置資訊的核心檔案。
remote-hostname-or-IP 遠端除錯伺服器的(請檢視jsadebugd)主機名或IP地址。
server-id 可選的唯一id，如果相同的遠端主機上運行了多臺除錯伺服器，用此選項引數標識伺服器。
選項:
<no option>如果使用不帶選項引數的jmap列印共享物件對映，將會列印目標虛擬機器中載入的每個共享物件的起始地址、對映大小以及共享物件檔案的路徑全稱。這與Solaris的pmap工具比較相似。
-dump:[live,]format=b,file=<filename>以hprof二進位制格式轉儲Java堆到指定filename的檔案中。live子選項是可選的。如果指定了live子選項，堆中只有活動的物件會被轉儲。想要瀏覽heap dump，你可以使用jhat(Java堆分析工具)讀取生成的檔案。
-finalizerinfo列印等待終結的物件資訊。
-heap列印一個堆的摘要資訊，包括使用的GC演算法、堆配置資訊和generation wise heap usage。
-histo[:live]列印堆的柱狀圖。其中包括每個Java類、物件數量、記憶體大小(單位：位元組)、完全限定的類名。列印的虛擬機器內部的類名稱將會帶有一個’*’字首。如果指定了live子選項，則只計算活動的物件。
-permstat列印Java堆記憶體的永久儲存區域的類載入器的智慧統計資訊。對於每個類載入器而言，它的名稱、活躍度、地址、父類載入器、它所載入的類的數量和大小都會被列印。此外，包含的字串數量和大小也會被列印。
-F強制模式。如果指定的pid沒有響應，請使用jmap -dump或jmap -histo選項。此模式下，不支援live子選項。
-h列印幫助資訊。
-help列印幫助資訊。
-J<flag>指定傳遞給執行jmap的JVM的引數。
檢視java 堆（heap）使用情況,執行命令：jmap -heap 4644
Attaching to process ID 31846, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
using thread-local object allocation.
Parallel GC with 4 thread(s)//GC 方式
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
670 interned Strings occupying 43720 bytes.檢視堆記憶體(histogram)中的物件數量及大小。執行命令：jmap -histo 4464
num #instances #bytes class name
編號 個數 位元組 類名
----------------------------------------------
1: 7 1322080 [I
2: 5603 722368 <methodKlass>
3: 5603 641944 <constMethodKlass>
4: 34022 544352 java.lang.Integer
5: 371 437208 <constantPoolKlass>
6: 336 270624 <constantPoolCacheKlass>
7: 371 253816 <instanceKlassKlass>jmap -histo:live 這個命令執行，JVM會先觸發gc，然後再統計資訊。
將記憶體使用的詳細情況輸出到檔案，jmap -dump:format=b,file=heapDump 4644
然後用jhat命令可以參看 jhat -port 5000 heapDump 在瀏覽器中訪問：http://localhost:5000/ 檢視詳細資訊
C:\Users\dup>jmap -dump:format=b,file=heapDump 4644
Dumping heap to C:\Users\dup\heapDump ...
Heap dump file created
C:\Users\dup>jhat port 5000 heapDump
Reading from heapDump...
Dump file created Sun Oct 14 09:19:16 CST 2018
Snapshot read, resolving...
Resolving 21860 objects...
Chasing references, expect 4 dots....
Eliminating duplicate references....
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.
這個命令執行，JVM會將整個heap的資訊dump寫入到一個檔案，heap如果比較大的話，就會導致這個過程比較耗時，並且執行的過程中為了保證dump的資訊是可靠的，所以會暫停應用。
總結
1.如果程式記憶體不足或者頻繁GC，很有可能存在記憶體洩露情況，這時候就要藉助Java堆Dump檢視物件的情況。
2.要製作堆Dump可以直接使用jvm自帶的jmap命令
3.可以先使用jmap -heap命令檢視堆的使用情況，看一下各個堆空間的佔用情況。
4.使用jmap -histo:[live]檢視堆記憶體中的物件的情況。如果有大量物件在持續被引用，並沒有被釋放掉，那就產生了記憶體洩露，就要結合程式碼，把不用的物件釋放掉。
5.也可以使用 jmap -dump:format=b,file=<fileName>命令將堆資訊儲存到一個檔案中，再借助jhat命令檢視詳細內容
6.在記憶體出現洩露、溢位或者其它前提條件下，建議多dump幾次記憶體，把記憶體檔案進行編號歸檔，便於後續記憶體整理分析。
4、 jstat
jstat(JVM Statistics Monitoring Tool)是用於監控虛擬機器各種執行狀態資訊的命令列工具。他可以顯示本地或遠端虛擬機器程序中的類裝載、記憶體、垃圾收集、JIT編譯等執行資料，在沒有GUI圖形的伺服器上，它是執行期定位虛擬機器效能問題的首選工具。
jstat 命令格式
引數解釋：
Option — 選項，我們一般使用 -gcutil 檢視gc情況
vmid — VM的程序號，即當前執行的java程序號
interval– 間隔時間，單位為秒或者毫秒
count — 列印次數，如果預設則列印無數次
引數interval和count代表查詢間隔和次數，如果省略這兩個引數，說明只查詢一次。假設需要每250毫秒查詢一次程序5828垃圾收集狀況，一共查詢5次，那命令列如下：
C:\Users\dup>jstat -gc 4644 250 5
S0C S1C S0U S1U EC EU OC OU MC MU
CCSC CCSU YGC YGCT FGC FGCT GCT
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000對於命令格式中的VMID與LVMID需要特別說明下：如果是本地虛擬機器程序，VMID(Virtual Machine IDentifier,虛機識別符號)和LVMID(Local Virtual Machine IDentifier,虛機識別符號)是一致的，如果是遠端虛擬機器程序，那VMID的格式應當是：[protocol:][//] lvmid [@hostname[:port]/servername]
–class 監視類裝載、解除安裝數量、總空間及類裝載所耗費的時間 –gc 監視Java堆狀況，包括Eden區、2個Survivor區、老年代、永久代等的容量 –gccapacity 監視內容與-gc基本相同，但輸出主要關注Java堆各個區域使用到的最大和最小空間 –gcutil 監視內容與-gc基本相同，但輸出主要關注已使用空間佔總空間的百分比 –gccause 與-gcutil功能一樣，但是會額外輸出導致上一次GC產生的原因 –gcnew 監視新生代GC的狀況 –gcnewcapacity 監視內容與-gcnew基本相同，輸出主要關注使用到的最大和最小空間 –gcold 監視老年代GC的狀況 –gcoldcapacity 監視內容與——gcold基本相同，輸出主要關注使用到的最大和最小空間 –gcpermcapacity 輸出永久代使用到的最大和最小空間 –compiler 輸出JIT編譯器編譯過的方法、耗時等資訊 –printcompilation 輸出已經被JIT編譯的方法
常見術語
1、jstat –class<pid> : 顯示載入class的數量，及所佔空間等資訊。
C:\Users\dup>jstat -class 4644
Loaded Bytes Unloaded Bytes Time
418 452.1 0 0.0 0.10Loaded 裝載的類的數量 Bytes 裝載類所佔用的位元組數 Unloaded 解除安裝類的數量 Bytes 解除安裝類的位元組數 Time 裝載和解除安裝類所花費的時間
2、jstat -compiler <pid>顯示VM實時編譯的數量等資訊。
C:\Users\dup>jstat -compiler 4644
Compiled Failed Invalid Time FailedType FailedMethod
24 0 0 0.01 0Compiled 編譯任務執行數量 Failed 編譯任務執行失敗數量 Invalid 編譯任務執行失效數量Time 編譯任務消耗時間 FailedType 最後一個編譯失敗任務的型別 FailedMethod 最後一個編譯失敗任務所在的類及方法
3、jstat -gc <pid>: 可以顯示gc的資訊，檢視gc的次數，及時間。
C:\Users\dup>jstat -gc 4644
S0C S1C S0U S1U EC EU OC OU MC MU
CCSC CCSU YGC YGCT FGC FGCT GCT
512.0 512.0 0.0 0.0 4416.0 1762.2 10944.0 0.0 2240.0 515.9
0.0 0.0 0 0.000 0 0.000 0.000S0C 年輕代中第一個survivor（倖存區）的容量 (位元組) S1C 年輕代中第二個survivor（倖存區）的容量 (位元組) S0U 年輕代中第一個survivor（倖存區）目前已使用空間 (位元組) S1U 年輕代中第二個survivor（倖存區）目前已使用空間 (位元組) EC 年輕代中Eden（伊甸園）的容量 (位元組) EU 年輕代中Eden（伊甸園）目前已使用空間 (位元組) OC Old代的容量 (位元組) OU Old代目前已使用空間 (位元組) PC Perm(持久代)的容量 (位元組) PU Perm(持久代)目前已使用空間 (位元組)YGC 從應用程式啟動到取樣時年輕代中gc次數 YGCT 從應用程式啟動到取樣時年輕代中gc所用時間(s) FGC 從應用程式啟動到取樣時old代(全gc)gc次數 FGCT 從應用程式啟動到取樣時old代(全gc)gc所用時間(s) GCT 從應用程式啟動到取樣時gc用的總時間(s)
4、jstat -gccapacity <pid>:可以顯示，VM記憶體中三代（young,old,perm）物件的使用和佔用大小
C:\Users\dup>jstat -gccapacity 4644
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC
OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC
5440.0 87360.0 5440.0 512.0 512.0 4416.0 10944.0 174784.0 10944
.0 10944.0 0.0 4480.0 2240.0 0.0 0.0 0.0 0 0NGCMN 年輕代(young)中初始化(最小)的大小(位元組) NGCMX 年輕代(young)的最大容量 (位元組)NGC 年輕代(young)中當前的容量 (位元組) S0C 年輕代中第一個survivor（倖存區）的容量 (位元組) S1C 年輕代中第二個survivor（倖存區）的容量 (位元組) EC 年輕代中Eden（伊甸園）的容量 (位元組) OGCMN old代中初始化(最小)的大小 (位元組) OGCMX old代的最大容量(位元組) OGC old代當前新生成的容量 (位元組) OC Old代的容量 (位元組) PGCMN perm代中初始化(最小)的大小 (位元組)PGCMX perm代的最大容量 (位元組)
PGC perm代當前新生成的容量 (位元組) PC Perm(持久代)的容量 (位元組) YGC 從應用程式啟動到取樣時年輕代中gc次數 FGC 從應用程式啟動到取樣時old代(全gc)gc次數
5、jstat -gcutil <pid>:統計gc資訊
C:\Users\dup>jstat -gcutil 4644
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 0.00 39.90 0.00 23.03 - 0 0.000 0 0.000 0.00
0S0 年輕代中第一個survivor（倖存區）已使用的佔當前容量百分比 S1 年輕代中第二個survivor（倖存區）已使用的佔當前容量百分比 E 年輕代中Eden（伊甸園）已使用的佔當前容量百分比 O old代已使用的佔當前容量百分比 P perm代已使用的佔當前容量百分比 YGC 從應用程式啟動到取樣時年輕代中gc次數 YGCT 從應用程式啟動到取樣時年輕代中gc所用時間(s)FGC 從應用程式啟動到取樣時old代(全gc)gc次數 FGCT 從應用程式啟動到取樣時old代(全gc)gc所用時間(s) GCT 從應用程式啟動到取樣時gc用的總時間(s)
6、jstat -gcnew <pid>:年輕代物件的資訊。
C:\Users\dup>jstat -gcnew 4644
S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT
512.0 512.0 0.0 0.0 15 15 0.0 4416.0 1762.2 0 0.000S0C 年輕代中第一個survivor（倖存區）的容量 (位元組) S1C 年輕代中第二個survivor（倖存區）的容量 (位元組) S0U 年輕代中第一個survivor（倖存區）目前已使用空間 (位元組) S1U 年輕代中第二個survivor（倖存區）目前已使用空間 (位元組) TT 持有次數限制 MTT 最大持有次數限制EC 年輕代中Eden（伊甸園）的容量 (位元組) EU 年輕代中Eden（伊甸園）目前已使用空間 (位元組) YGC 從應用程式啟動到取樣時年輕代中gc次數 YGCT 從應用程式啟動到取樣時年輕代中gc所用時間(s)
7、jstat -gcnewcapacity<pid>: 年輕代物件的資訊及其佔用量。
C:\Users\dup>jstat -gcnewcapacity 4644
NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX
EC YGC FGC
5440.0 87360.0 5440.0 8704.0 512.0 8704.0 512.0 69952.0
4416.0 0 0NGCMN 年輕代(young)中初始化(最小)的大小(位元組) NGCMX 年輕代(young)的最大容量 (位元組)NGC 年輕代(young)中當前的容量 (位元組) S0CMX 年輕代中第一個survivor（倖存區）的最大容量 (位元組) S0C 年輕代中第一個survivor（倖存區）的容量 (位元組) S1CMX 年輕代中第二個survivor（倖存區）的最大容量 (位元組) S1C 年輕代中第二個survivor（倖存區）的容量 (位元組)ECMX 年輕代中Eden（伊甸園）的最大容量 (位元組) EC 年輕代中Eden（伊甸園）的容量 (位元組)YGC 從應用程式啟動到取樣時年輕代中gc次數 FGC 從應用程式啟動到取樣時old代(全gc)gc次數
8、jstat -gcold <pid>：old代物件的資訊。
C:\Users\dup>jstat -gcold 4644
MC MU CCSC CCSU OC OU YGC FGC FGCT
GCT
2240.0 515.9 0.0 0.0 10944.0 0.0 0 0 0.00
0 0.000PC Perm(持久代)的容量 (位元組) PU Perm(持久代)目前已使用空間 (位元組) OC Old代的容量 (位元組) OU Old代目前已使用空間 (位元組) YGC 從應用程式啟動到取樣時年輕代中gc次數 FGC 從應用程式啟動到取樣時old代(全gc)gc次數 FGCT 從應用程式啟動到取樣時old代(全gc)gc所用時間(s) GCT 從應用程式啟動到取樣時gc用的總時間(s)
9、jstat-gcoldcapacity <pid>:old代物件的資訊及其佔用量。
C:\Users\dup>jstat -gcoldcapacity 4644
OGCMN OGCMX OGC OC YGC FGC FGCT GCT
10944.0 174784.0 10944.0 10944.0 0 0 0.000 0.000OGCMN old代中初始化(最小)的大小 (位元組) OGCMX old代的最大容量(位元組) OGC old代當前新生成的容量 (位元組) OC Old代的容量 (位元組) YGC 從應用程式啟動到取樣時年輕代中gc次數 FGC 從應用程式啟動到取樣時old代(全gc)gc次數 FGCT 從應用程式啟動到取樣時old代(全gc)gc所用時間(s) GCT 從應用程式啟動到取樣時gc用的總時間(s)
10、jstat -gcpermcapacity<pid>: perm物件的資訊及其佔用量。
PGCMN perm代中初始化(最小)的大小 (位元組) PGCMX perm代的最大容量 (位元組)
PGC perm代當前新生成的容量 (位元組) PC Perm(持久代)的容量 (位元組) YGC 從應用程式啟動到取樣時年輕代中gc次數 FGC 從應用程式啟動到取樣時old代(全gc)gc次數 FGCT 從應用程式啟動到取樣時old代(全gc)gc所用時間(s) GCT 從應用程式啟動到取樣時gc用的總時間(s)
11、jstat -printcompilation <pid>：當前VM執行的資訊。
C:\Users\dup>jstat -printcompilation 4644
Compiled Size Type Method
24 26 1 java/util/ArrayList ensureExplicitCapacityCompiled 編譯任務的數目 Size 方法生成的位元組碼的大小 Type 編譯型別 Method 類名和方法名用來標識編譯的方法。類名使用/做為一個名稱空間分隔符。方法名是給定類中的方法。上述格式是由-XX:+PrintComplation選項進行設定的
5、jinfo
jinfo可以輸出java程序、core檔案或遠端debug伺服器的配置資訊。這些配置資訊包括JAVA系統引數及命令列引數,如果程序執行在64位虛擬機器上，需要指明-J-d64引數，如：jinfo -J-d64 -sysprops pid
6、jhat
hat(Java Heap Analysis Tool),是一個用來分析java的堆情況的命令。之前的文章講到過，使用jmap可以生成Java堆的Dump檔案。生成dump檔案之後就可以用jhat命令，將dump檔案轉成html的形式，然後通過http訪問可以檢視堆情況。jhat命令會Java解析堆dump並啟動一個web伺服器，然後就可以在瀏覽器中檢視堆的dump檔案了。
一、匯出dump檔案
關於dump檔案的生成可以看jmap命令的詳細介紹.
1、執行java程式
package com.test;
public class JhatDemo {
public static void main(String[] args) {
while(true) {
String string = new String("hollis");
System.out.println(string);
}
}
}2、檢視該程序的ID，生成dump檔案
C:\Users\dup>jmap -dump:format=b,file=headDump 1064
Dumping heap to C:\Users\dup\headDump ...
Heap dump file created除了使用jmap命令，還可以通過以下方式：
1、使用 jconsole 選項通過 HotSpotDiagnosticMXBean 從執行時獲得堆轉儲（生成dump檔案）、
2、虛擬機器啟動時如果指定了 -XX:+HeapDumpOnOutOfMemoryError 選項, 則在丟擲 OutOfMemoryError 時, 會自動執行堆轉儲。
3、使用 hprof 命令
二、解析Java堆轉儲檔案,並啟動一個 web server
C:\Users\dup>jhat headDump
Reading from headDump...
Dump file created Sun Oct 14 10:04:16 CST 2018
Snapshot read, resolving...
Resolving 85722 objects...
Chasing references, expect 17 dots.................
Eliminating duplicate references.................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.使用jhat命令，就啟動了一個http服務，埠是7000
然後在訪問http://localhost:7000/
頁面如下：
三、分析
在瀏覽器裡面看到dump檔案之後就可以進行分析了。這個頁面會列出當前程序中的所有對像情況。
該頁面提供了幾個查詢功能可供使用：
All classes including platform
Show all members of the rootset
Show instance counts for all classes (including platform)
Show instance counts for all classes (excluding platform)
Show heap histogram
Show finalizer summary
Execute Object Query Language (OQL) query一般檢視堆異常情況主要看這個兩個部分：
Show instance counts for all classes (excluding platform)，平臺外的所有物件資訊。如下圖：
Show heap histogram 以樹狀圖形式展示堆情況。如下圖：
具體排查時需要結合程式碼，觀察是否大量應該被回收的物件在一直被引用或者是否有佔用記憶體特別大的物件無法被回收。
用法摘要
C:\Users\dup>jhat -help
Usage: jhat [-stack <bool>] [-refs <bool>] [-port <port>] [-baseline <file>] [-
debug <int>] [-version] [-h|-help] <file>
-J<flag> Pass <flag> directly to the runtime system. For
example, -J-mx512m to use a maximum heap size of 512MB
-stack false: Turn off tracking object allocation call stack.
-refs false: Turn off tracking of references to objects
-port <port>: Set the port for the HTTP server. Defaults to 7000
-exclude <file>: Specify a file that lists data members that should
be excluded from the reachableFrom query.
-baseline <file>: Specify a baseline object dump. Objects in
both heap dumps with the same ID and same class will
be marked as not being "new".
-debug <int>: Set debug level.
0: No debug output
1: Debug hprof file parsing
2: Debug hprof file parsing, no server
-version Report version number
-h|-help Print this help and exit
<file> The file to read
For a dump file that contains multiple heap dumps,
you may specify which dump in the file
by appending "#<number>" to the file name, i.e. "foo.hprof#3".
All boolean options default to "true"-stack false|true
關閉物件分配呼叫棧跟蹤(tracking object allocation call stack)。 如果分配位置資訊在堆轉儲中不可用. 則必須將此標誌設定為 false. 預設值為 true.
-refs false|true
關閉物件引用跟蹤(tracking of references to objects)。 預設值為 true. 預設情況下, 返回的指標是指向其他特定物件的物件,如反向連結或輸入引用(referrers or incoming references), 會統計/計算堆中的所有物件。
-port port-number
設定 jhat HTTP server 的埠號. 預設值 7000.
-exclude exclude-file
指定物件查詢時需要排除的資料成員列表檔案(a file that lists data members that should be excluded from the reachable objects query)。 例如, 如果檔案列列出了 java.lang.String.value , 那麼當從某個特定物件 Object o 計算可達的物件列表時, 引用路徑涉及 java.lang.String.value 的都會被排除。
-baseline exclude-file
指定一個基準堆轉儲(baseline heap dump)。 在兩個 heap dumps 中有相同 object ID 的物件會被標記為不是新的(marked as not being new). 其他物件被標記為新的(new). 在比較兩個不同的堆轉儲時很有用.
-debug int
設定 debug 級別. 0 表示不輸出除錯資訊。 值越大則表示輸出更詳細的 debug 資訊.
-version
啟動後只顯示版本資訊就退出
-J< flag >
因為 jhat 命令實際上會啟動一個JVM來執行, 通過 -J 可以在啟動JVM時傳入一些啟動引數. 例如, -J-Xmx512m 則指定執行 jhat 的Java虛擬機器使用的最大堆記憶體為 512 MB. 如果需要使用多個JVM啟動引數,則傳入多個 -Jxxxxxx.