前言：在web開發過程中，不管是eclipse還是web服務有時候會經常遇到OutofMemoryError（記憶體不足），記憶體洩露，執行緒鎖死，java程序CPU過高等操作，伺服器可以允許這些問題的存在，導致這些問題在日常開發中被更多的人忽略掉。

jstack的作用：

　　jstack 用於答應給定的java程序ID或者core file或遠端除錯服務的java堆疊資訊，可以使用它查明問題。

詳細命令格式：

jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server[email protected]
 
] remote-hostname-or-IP

如果是在64位機器上，需要指定選項”-J-d64”，

首先看一下針對程式死鎖的錯誤排查

package **

/**
 * @author peng
 * @date 2015年9月14日
 * @desc 死鎖例子
 */
public class JstackLockTest {

    public static void main(String[] args) {
        final Object lock1 = new Object(), lock2 = new Object();

        Thread t1 = new
 
 Thread("t1") {
            @Override
            public void run() {
                synchronized (lock1) {
                        try {
                            Thread.sleep(3000);
                        } catch (InterruptedException e) {
                        }
                    synchronized
 
 (lock2) {
                        System.out.println("thread t1 done.");
                    }
                }
            }
        };
        Thread t2 = new Thread("t2") {
            @Override
            public void run() {
                synchronized (lock2) {
                    try {
                        Thread.sleep(3000);
                    } catch (InterruptedException e) {
                    }

                    synchronized (lock1) {
                        System.out.println("thread t2 done.");
                    }
                }
            }
        };
        t1.start();
        t2.start();
    }
}

上面示例程式碼是一個死鎖的例子，如果在開發過程中遇到這樣的例子，如圖一所示：

等了很長時間都沒有任何輸出，而程式一直在執行中，然後通過jsp檢視該程式的jpid值，使用jstack來檢視堆疊資訊：
Linux程式碼：

$jps
10502 JstackLockTest
12815 Jps
5393 org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar
10863 JstackLockTest
$jstack -l 10502

對應的結果：

......省略前面log
"Finalizer" daemon prio=10 tid=0x00007fbd7c079000 nid=0x2912 in Object.wait() [0x00007fbd80ff6000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f5561300> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x00000000f5561300> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)

   Locked ownable synchronizers:
        - None

"Reference Handler" daemon prio=10 tid=0x00007fbd7c077800 nid=0x2911 in Object.wait() [0x00007fbd810f7000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f55611d8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x00000000f55611d8> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
        - None
......省略後面log

從這個結果檔案我們一看到發現了一個死鎖,具體是執行緒t2在等待執行緒t1,而執行緒t1在等待執行緒t2造成的,同時也記錄了執行緒的堆疊和程式碼行數,通過這個堆疊和行數我們就可以去檢查對應的程式碼塊,從而發現問題和解決問題。

對於高cpu的排查

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26045 peng 20 0 3186184 1.239g 1.145g S 100.4 8.0 421:44.79 vmware-vmx
14938 peng 20 0 1920880 31368 13076 S 100.1 0.2 3:03.75 java
9564 peng 20 0 4404644 1.187g 1.163g S 3.3 7.6 462:03.29 vmware-vmx
1132 root 20 0 540820 122556 104088 S 1.7 0.8 22:07.77 Xorg
3746 peng 20 0 1612920 196932 36636 S 1.7 1.2 33:28.35 compiz
12545 peng 20 0 857900 50584 23196 S 1.0 0.3 0:07.37 /usr/bin/termin
10 root 20 0 0 0 0 S 0.3 0.0 0:32.85 rcuos/2
490 peng 20 0 1173848 171256 60884 S 0.3 1.0 0:51.94 chromium-browse
981 peng 20 0 1288652 290592 64952 S 0.3 1.8 0:49.72 chromi