本文轉發來自博主figo_2009的博客，這裏有地址可以鏈接過去：https://blog.csdn.net/figo_2009/article/details/84395703。內容一樣。我拿過來的目的是在從寫一遍加深記憶，也可以做個保留，爲以後解決，分析內存，線程問題做一些技術儲備。
--------------------------------------------------------------------分割線--------------------------------------------------------------------
公司內部同事分享的一篇文章週末看到一個用jstack查看死鎖的例子。昨天晚上總結了一下jstack(查看線程)、jmap(查看內存)和jstat(性能分析)命令。供大家參考
1.jstack(查看線程)
1.1 jstack能得到運行java程序的java stack和native stack的信息。可以輕鬆得知當前線程的運行情況。如下所示，注：這個和thread dump是同樣的結果。但是thread dump是用kill -3 pid命令，還是服務器上面少用kill爲妙
RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:201)
- waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234)
at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)
1）線程狀態是 Blocked，阻塞狀態。說明線程等待資源超時！
2）“ waiting to lock <0x00000000acf4d0c0>”指，線程在等待給這個 0x00000000acf4d0c0 地址上鎖（英文可描述爲：trying to obtain 0x00000000acf4d0c0 lock）。
3）在 dump 日誌裏查找字符串 0x00000000acf4d0c0，發現有大量線程都在等待給這個地址上鎖。如果能在日誌裏找到誰獲得了這個鎖（如locked < 0x00000000acf4d0c0 >），就可以順藤摸瓜了。
4）“waiting for monitor entry”說明此線程通過 synchronized(obj) {……} 申請進入了臨界區，從而進入了下圖1中的“Entry Set”隊列，但該 obj 對應的 monitor 被其他線程擁有，所以本線程在 Entry Set 隊列中等待。
5）第一行裏，"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native線程的id。prio是線程優先級。[0x00007fd4f8684000]是線程棧起始地址。
1.2 命名行格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
最常用的還是jstack pid.這裏的pid是通過dump文件中
下面有詳細的例子講這種分析，大家參考原著
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html