線上快速定位CPU100%

連續兩天下午CPU都達到了100%,第一次是因爲打印日誌時使用fastJson打印了很是大的保單對象，並且仍是在一個List中；第二次是因爲循環保單集合時建立了大量的對象致使，因爲第一種狀況從日誌中就能夠看到，今天咱們就第二種狀況進行分析。

步驟1、找到最耗CPU的進程

• 工具：top
• 方法：
  • 執行top顯示進程運行信息列表
  • 輸入P，進程按照CPU使用率進行排序

如上圖所示，最耗CPU的進程PID爲1

步驟2、找到最耗CPU的線程

• 工具：top
• 方法：
  • top -Hp 1 ,顯示一個進程的線程運行信息列表
  • 輸入P，線程按照CPU使用率排序

如上圖，進程1中，最耗CPU的線程PID爲2616

步驟3、將線程PID轉化爲十六進制

• 工具：printf
• 方法：printf "%x\n" 2616

如上圖所示，2616對應的16進制是Oxa38，之因此要轉換成十六進制，是由於堆棧裏，線程ID是十六進制表示的。

步驟4、查看堆棧，找到線程在幹嗎

• 工具：pstack/jstack/grep
• jstack 2606 | grep 'Oxa38' -C5 --color
• 打印進程堆棧信息，經過線程ID過濾獲得線程堆棧

jstack用於打印出給定的Java進程ID或core file或遠程調試服務的Java堆棧信息

如上圖找到了耗CPU高的線程對應的線程名稱「pool-1-thread-1」，以及看到了該線程正在執行代碼的堆棧

步驟5、分析線程的狀態

線程的state

• 一、RUNNABLE:線程正在執行中，佔用了資源，好比處理某個請求/進行計算/文件操做等
• 二、BLOCKED/Waiting to lock(需關注)：
  • 線程處於阻塞狀態，等待某種資源(可理解爲等待資源超時的線程)；
  • "waiting to lock "，即等待給xxx上鎖，grep stack文件找locked 查找得到鎖的線程；
  • "waiting for monitor entry" 線程經過synchronized(obj){……}申請進入了臨界區，但該obj對應的monitor被其餘線程擁有，從而處於等待。
• 三、WAITING/TIMED_WAITING{定時}(關注)：
  • "TIMED_WAITING (parking)":等待狀態，且指定了時間，到達指定的時間後自動退出等待狀態，parking指線程處於掛起中；
  • "waiting on condition"需與堆棧中的"parking to wait for (atjava.util.concurrent.SynchronousQueue$TransferStack)"結合來看。first-->此線程是在等待某個條件的發生，來把本身喚醒，second-->SynchronousQueue不是一個隊列，其是線程之間移交信息的機制，當咱們把一個元素放入到 SynchronousQueue 中時必須有另外一個線程正在等待接受移交的任務，所以這就是本線程在等待的條件。
• 四、Deadlock(需關注):死鎖，資源相互佔用。

其餘

線程狀態爲"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.TIME_WAITING(on object monitor); java.lang.Thread.State.WAITING(on object monitor); 通常都是RMI相關線程（RMI RenewClean、 GC Daemon、RMI Reaper），GC線程（Finalizer），引用對象垃圾回收線程（Reference Handler）等系統線程處於這種狀態。