常用java自帶命令概覽

ref:http://www.hollischuang.com/archives/308

一、常用命令

• jps: 查看本機的Java中進程信息。
• jstack: 打印線程的執行棧信息。
• jmap: 打印內存映射,制作堆Dump。
• jstat: 性能監控工具。
• jhat: 內存分析工具。
• jconsole:簡易的可視化控制台。
• jvisualvm:功能強大的控制台。

二、什么是Java Dump

Java虛擬機的運行時快照。將Java虛擬機運行時的狀態和信息保存到文件。

線程Dump,包含所有線程的運行狀態。純文本格式。
堆Dump,包含線程Dump,包含所有堆對象的狀態。二進制格式。

• Java Dump有什么用？
  補足傳統Bug分析手段的不足: 可在任何Java環境使用;信息量充足。 針對非功能正確性的Bug,主要為:多線程幵發、內存泄漏。

三、JPS 命令
查看顯示當前用戶所有java進程的pid信息，類似 ps -ef | grep java ，且更通用，可以查看所有進程。

• 實現機制:

jdk中的jps命令可以顯示當前運行的java進程以及相關參數，它的實現機制如下：
java程序在啟動以后，會在java.io.tmpdir指定的目錄下，就是臨時文件夾里，生成一個類似於hsperfdata_User的文件夾，這個文件夾里（在Linux中為/tmp/hsperfdata_{userName}/），有幾個文件，名字就是java進程的pid，因此列出當前運行的java進程，只是把這個目錄里的文件名列一下而已。 至於系統的參數什么，就可以解析這幾個文件獲得。

• JPS失效處理

- 現象：
     用ps -ef|grep java能看到啟動的java進程，但是用jps查看卻不存在該進程的id。待會兒解釋過之后就能知道在該情況下，jconsole、jvisualvm可能無法監控該進程，其他java自帶工具也可能無法使用
- 分析：
     jps、jconsole、jvisualvm等工具的數據來源就是前面說過的一個文件---（/tmp/hsperfdata_userName/pid)。所以當該文件不存在或是無法讀取時就會出現jps無法查看該進程號，jconsole無法監控等問題
- 可能原因：
（1）磁盤讀寫、目錄權限問題 若該用戶沒有權限寫/tmp目錄或是磁盤已滿，則無法創建/tmp/hsperfdata_userName/pid文件。或該文件已經生成，但用戶沒有讀權限
（2）臨時文件丟失，被刪除或是定期清理 對於linux機器，一般都會存在定時任務對臨時文件夾進行清理，導致/tmp目錄被清空。這也是我第一次碰到該現象的原因。常用的可能定時刪除臨時目錄的工具為crontab、redhat的tmpwatch、ubuntu的tmpreaper等等
這個導致的現象可能會是這樣，用jconsole監控進程，發現在某一時段后進程仍然存在，但是卻沒有監控信息了。
（3）java進程信息文件存儲地址被設置，不在/tmp目錄下 上面我們在介紹時說默認會在/tmp/hsperfdata_userName目錄保存進程信息，但由於以上1、2所述原因，可能導致該文件無法生成或是丟失，所以java啟動時提供了參數(-Djava.io.tmpdir)，可以對這個文件的位置進行設置，而jps、jconsole都只會從/tmp目錄讀取，而無法從設置后的目錄讀物信息，這是我第二次碰到該現象的原因

四、jstack 命令 - 打印線程dump

• 功能
  jstack用於生成java虛擬機當前時刻的線程快照。線程快照是當前java虛擬機內每一條線程正在執行的方法堆棧的集合，生成線程快照的主要目的是定位線程出現長時間停頓的原因，如線程間死鎖、死循環、請求外部資源導致的長時間等待等。 線程出現停頓的時候通過jstack來查看各個線程的調用堆棧，就可以知道沒有響應的線程到底在后台做什么事情，或者等待什么資源。 如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和native stack的信息，從而可以輕松地知道java程序是如何崩潰和在程序何處發生問題。另外，jstack工具還可以附屬到正在運行的java程序中，看到當時運行的java程序的java stack和native stack的信息, 如果現在運行的java程序呈現hung的狀態，jstack是非常有用的。
  So,jstack命令主要用來查看Java線程的調用堆棧的，可以用來分析線程問題（如死鎖）。

線程狀態：

• NEW 未啟動的，不會出現在dump中

• RUNNABLE 運行中的，

• Blocked 被阻塞且並 等待監控器鎖

• Waiting 無限期等待其他線程執行特定操作

• Timed_waiting 有時限的等待另一個線程執行特定操作

• Terminated 已退出的

• monitor
  每個對象有且僅有一個monitor，相當於鎖，想要獲取對象的訪問或使用權，需要先獲取對象的鎖，如果沒有獲取到，則等待（entry set）；如果獲取之后，執行object.wait（wait set）方法，會進入等待；獲取到鎖的線程可以得到訪問權（owner）。

線程動作

• runnable:狀態一般為runnable
• wait on condition：等待區等待，被park
• in Object.wait()：等待區等待，狀態為waiting 或 timed_waiting
• waiting for monitor entry，：進入區等待，狀態為 blocked
• sleeping：休眠的線程，調用了Thread.sleep().

調用修飾

• locked <地址> :鎖定了目標，獲取了對象的鎖,見識器的擁有者
• wait to lock <地址> :未獲取成功，進入去等待
• wait on <地址>:使用synchron申請對象鎖成功后，釋放鎖並在等待區等待
• 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體系不同。

線程Dump的分析
原則
結合代碼閱讀的推理。需要線程Dump和源碼的相互推導和印證。
造成Bug的根源往往丌會在調用棧上直接體現,一定格外注意線程當前調用之前的所有調用。
入手點
進入區等待

"d&a-3588" daemon waiting for monitor entry [0x000000006e5d5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()
- waiting to lock <0x0000000602f38e90> (a java.lang.Object)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()

線程狀態BLOCKED,線程動作wait on monitor entry,調用修飾waiting to lock總是一起出現。表示在代碼級別已經存在沖突的調用。必然有問題的代碼,需要盡可能減少其發生。
同步塊阻塞
一個線程鎖住某對象,大量其他線程在該對象上等待。

"blocker" runnable
java.lang.Thread.State: RUNNABLE
at com.jiuqi.hcl.javadump.Blocker$1.run(Blocker.java:23)
- locked <0x00000000eb8eff68> (a java.lang.Object)
"blockee-11" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)
"blockee-86" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)

持續運行的IO IO操作是可以以RUNNABLE狀態達成阻塞。例如:數據庫死鎖、網絡讀寫。 格外注意對IO線程的真實狀態的分析。 一般來說,被捕捉到RUNNABLE的IO調用,都是有問題的。
以下堆棧顯示： 線程狀態為RUNNABLE。 調用棧在SocketInputStream或SocketImpl上,socketRead0等方法。 調用棧包含了jdbc相關的包。很可能發生了數據庫死鎖

"d&a-614" daemon prio=6 tid=0x0000000022f1f000 nid=0x37c8 runnable
[0x0000000027cbd000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at oracle.net.ns.Packet.receive(Packet.java:240)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:588)
分線程調度的休眠
正常的線程池等待
"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()： 注意非線程池等待
使用
想要學習一個命令，先來看看幫助，使用jstack -help查看幫助：

hollis@hos:~$ jstack -help
Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

-F當’jstack [-l] pid’沒有相應的時候強制打印棧信息 -l長列表. 打印關於鎖的附加信息,例如屬於java.util.concurrent的ownable synchronizers列表. -m打印java和native c/c++框架的所有棧信息. -h | -help打印幫助信息 pid 需要被打印配置信息的java進程id,可以用jps查詢.
首先，我們分析這么一段程序的線程情況：

/**
 * @author hollis
 */
public class JStackDemo1 {
    public static void main(String[] args) {
        while (true) {
            //Do Nothing
        }
    }
}

先是有jps查看進程號：

hollis@hos:~$ jps
29788 JStackDemo1
29834 Jps
22385 org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar

然后使用jstack 查看堆棧信息：
hollis@hos:~$ jstack 29788
2015-04-17 23:47:31
...此處省略若干內容...
"main" prio=10 tid=0x00007f197800a000 nid=0x7462 runnable [0x00007f197f7e1000]
java.lang.Thread.State: RUNNABLE
at javaCommand.JStackDemo1.main(JStackDemo1.java:7)
我們可以從這段堆棧信息中看出什么來呢？我們可以看到，當前一共有一條用戶級別線程,線程處於runnable狀態，執行到JStackDemo1.java的第七行。 看下面代碼：

/**
 * @author hollis
 */
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() {
        while(true){
            System.out.println(1);
        }
    }
}

線程堆棧信息如下：

"Reference Handler" daemon prio=10 tid=0x00007fbbcc06e000 nid=0x286c in Object.wait() [0x00007fbbc8dfc000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000783e066e0> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x0000000783e066e0> (a java.lang.ref.Reference$Lock)

我們能看到：
線程的狀態： WAITING 線程的調用棧 線程的當前鎖住的資源： <0x0000000783e066e0> 線程當前等待的資源：<0x0000000783e066e0>
為什么同時鎖住的等待同一個資源：
線程的執行中，先獲得了這個對象的 Monitor（對應於 locked <0x0000000783e066e0>）。當執行到 obj.wait(), 線程即放棄了 Monitor的所有權，進入 “wait set”隊列（對應於 waiting on <0x0000000783e066e0> ）。
死鎖分析
學會了怎么使用jstack命令之后，我們就可以看看，如何使用jstack分析死鎖了，這也是我們一定要掌握的內容。 啥叫死鎖？ 所謂死鎖： 是指兩個或兩個以上的進程在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。 說白了，我現在想吃雞蛋灌餅，桌子上放着雞蛋和餅，但是我和我的朋友同時分別拿起了雞蛋和病，我手里拿着雞蛋，但是我需要他手里的餅。他手里拿着餅，但是他想要我手里的雞蛋。就這樣，如果不能同時拿到雞蛋和餅，那我們就不能繼續做后面的工作（做雞蛋灌餅）。所以，這就造成了死鎖。 看一段死鎖的程序：

package javaCommand;
/**
 * @author hollis
 */
public class JStackDemo {
    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:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f0134003ae8 (object 0x00000007d6aa2c98, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007f0134006168 (object 0x00000007d6aa2ca8, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
    at javaCommand.DeadLockclass.run(JStackDemo.java:40)
    - waiting to lock <0x00000007d6aa2c98> (a java.lang.Object)
    - locked <0x00000007d6aa2ca8> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:745)
"Thread-0":
    at javaCommand.DeadLockclass.run(JStackDemo.java:27)
    - waiting to lock <0x00000007d6aa2ca8> (a java.lang.Object)
    - locked <0x00000007d6aa2c98> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

哈哈，堆棧寫的很明顯，它告訴我們 Found one Java-level deadlock，然后指出造成死鎖的兩個線程的內容。然后，又通過 Java stack information for the threads listed above來顯示更詳細的死鎖的信息。 他說
Thread-1在想要執行第40行的時候，當前鎖住了資源<0x00000007d6aa2ca8>,但是他在等待資源<0x00000007d6aa2c98> Thread-0在想要執行第27行的時候，當前鎖住了資源<0x00000007d6aa2c98>,但是他在等待資源<0x00000007d6aa2ca8> 由於這兩個線程都持有資源，並且都需要對方的資源，所以造成了死鎖。 原因我們找到了，就可以具體問題具體分析，解決這個死鎖了。

• 其他
  虛擬機執行Full GC時,會阻塞所有的用戶線程。因此,即時獲取到同步鎖的線程也有可能被阻塞。 在查看線程Dump時,首先查看內存使用情況。