1. 獲取要查看的進程的ID
ps aux | grep xxx
2. 查看此進程下的線程信息
- top -H -p <pid>
- top -p <pid> 按shift+h
- top -Hp <pid>
3. 查看棧信息
jstack <pid> > stack
- sudo -u tomcat $JAVA_HOME/bin/jstack <pid> > stack.log
- sudo vim-->sh-->獲取root權限-->su - tomcat--> $JAVA_HOME/bin/jstack
4. 簡單分析
- 線程ID為十進制-->十六進制：printf "%x\n" xxx
- 觀察占用cpu高的線程ID
1>>若此線程ID固定不變
2>>占cpu高的線程不斷變化，多觀察，統計
3>>cat stack | grep 'java.lang.Thread.State' | awk '{print $2$3$4$5}' | sort | uniq -c
562 RUNNABLE
5 TIMED_WAITING(onobjectmonitor)
174 TIMED_WAITING(parking)
7 TIMED_WAITING(sleeping)
3 WAITING(onobjectmonitor)
330 WAITING(parking)
- 線程的state
1>>RUNNABLE: 線程正在執行中，占用了資源，比如處理某個請求/進行計算/文件操作等
2>>BLOCKED/Waiting to lock(需關注):
>>>線程處於阻塞狀態，等待某種資源(可理解為等待資源超時的線程)；
>>>"waiting to lock <xxx>"，即等待給xxx上鎖，grep stack文件找locked <xxx> 查找獲得鎖的線程；
>>>"waiting for monitor entry" 線程通過synchronized(obj){……}申請進入了臨界區，但該obj對應的monitor被其他線程擁有，從而處於等待。
3>>WAITING/TIMED_WAITING{定時}(關注):
>>>"TIMED_WAITING (parking)":等待狀態，且指定了時間，到達指定的時間后自動退出等待狀態，parking指線程處於掛起中；
>>>"waiting on condition"需與堆棧中的"parking to wait for <xxx> (atjava.util.concurrent.SynchronousQueue$TransferStack)"結合來看。first-->此線程是在等待某個條件的發生，來把自己喚醒，second-->SynchronousQueue不是一個隊列，其是線程之間移交信息的機制，當我們把一個元素放入到 SynchronousQueue 中時必須有另一個線程正在等待接受移交的任務，因此這就是本線程在等待的條件。
4>>Deadlock(需關注):死鎖，資源相互占用。
5. other
- 線程狀態為“waiting for monitor entry”
意味着它 在等待進入一個臨界區 ，所以它在”Entry Set“隊列中等待。
此時線程狀態一般都是 Blocked：
java.lang.Thread.State: BLOCKED (on object monitor)
- 線程狀態為“waiting on condition”
說明它在等待另一個條件的發生，來把自己喚醒，或者干脆它是調用了 sleep(N)。
此時線程狀態大致為以下幾種：
java.lang.Thread.State: WAITING (parking)：一直等那個條件發生；
java.lang.Thread.State: TIMED_WAITING (parking或sleeping)：定時的，那個條件不到來，也將定時喚醒自己。
- 如果大量線程在“waiting for monitor entry”
可能是一個全局鎖阻塞住了大量線程。
如果短時間內打印的 thread dump 文件反映，隨着時間流逝，waiting for monitor entry 的線程越來越多，沒有減少的趨勢，可能意味着某些線程在臨界區里呆的時間太長了，以至於越來越多新線程遲遲無法進入臨界區。
- 如果大量線程在“waiting on condition”
可能是它們又跑去獲取第三方資源，尤其是第三方網絡資源，遲遲獲取不到Response，導致大量線程進入等待狀態。
所以如果你發現有大量的線程都處在 Wait on condition，從線程堆棧看，正等待網絡讀寫，這可能是一個網絡瓶頸的征兆，因為網絡阻塞導致線程無法執行。
線程狀態為“in Object.wait()”：
說明它獲得了監視器之后，又調用了 java.lang.Object.wait() 方法。
每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的線程狀態是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態是 “in Object.wait()”。
當線程獲得了 Monitor，如果發現線程繼續運行的條件沒有滿足，它則調用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進入 “Wait Set”隊列。
此時線程狀態大致為以下幾種：
java.lang.Thread.State: TIMED_WAITING (on object monitor)；
java.lang.Thread.State: WAITING (on object monitor)；
一般都是RMI相關線程（RMI RenewClean、 GC Daemon、RMI Reaper），GC線程（Finalizer），引用對象垃圾回收線程（Reference Handler）等系統線程處於這種狀態。
6. Test
"DubboServerHandler-10.88.132.160:20088-thread-3"{線程名} daemon prio=10{優先級} tid=0x00007f2770004800{java線程ID} nid=0x1b0b{native線程ID} waiting on condition [0x00007f2445a99000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000005f9e9dcc8> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
參考：