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上鎖，grep stack文件找locked 查找獲得鎖的線程；

>>>"waiting for monitor entry" 線程通過synchronized(obj){……}申請進入了臨界區，但該obj對應的monitor被其他線程擁有，從而處于等待。

3>>WAITING/TIMED_WAITING{定時}(關注):

>>>"TIMED_WAITING (parking)":等待狀態，且指定了時間，到達指定的時間后自動退出等待狀態，parking指線程處于掛起中；

>>>"waiting on condition"需與堆棧中的"parking to wait for? (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)

參考：

總結

以上是生活随笔為你收集整理的java程序cpu突然飚高_简单排查java应用CPU飙高的线程问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。