定位CPU的問題一般可以分為以下幾個步驟： 1. 定位進程 2. 定位線程 3. 查看線程信息 4. 定位具體方法(代碼) ### 定位進程 通過`top -c`（然后按`P`按cpu排序），`htop`等工具定位到具體的高CPU進程 假設定位到的進程ID為14279 或者使用jps查看java進程號 ### 定位線程 `top -H -p 14279`定位占cpu的線程： ``` %Cpu(s): 0.5 us, 0.7 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 8168236 total, 231696 free, 3660496 used, 4276044 buff/cache KiB Swap: 969964 total, 969964 free, 0 used. 4197860 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14293 faceless 20 0 4508772 97036 18112 S 45 1.2 152:35.42 java 14279 faceless 20 0 4508772 97036 18112 S 23 1.2 0:00.00 java 14282 faceless 20 0 4508772 97036 18112 S 0.0 1.2 0:00.37 java ``` 一般超過80%就是比較高的，80%左右是合理情況 ### 查看線程信息 方法一：手動定位 使用jstack 分別找也上面的線程的具體內容，比如第一個線程 14293： ``` # 將線程ID轉換為16進制 ``` printf '0x%x' 14293 => 0x37d5 ``` # 通過jstack查看進程中該線程的信息： `jstack pid | grep tid`找到線程堆棧 jstack 12816 | grep 0x3211 -A 30 # 【示例輸出】 "VM Periodic Task Thread" os_prio=0 tid=0x00007ff1802d5800 nid=0x37d5 waiting on condition ``` 當然這里也可以直接使用`jstack 14279 > ~/tmp/pid-14279.log`顯示所有線程，然后手動尋找對應的ID 當然更常見的是我們對整個jstack文件進行分析，通常我們會比較關注WAITING和TIMED\_WAITING的部分，BLOCKED就不用說了。我們可以使用命令`cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c`來對jstack的狀態有一個整體的把握，如果WAITING之類的特別多，那么多半是有問題啦 方法二：通過arthas定位 [Arthas]支持直接通過`thread`子命令顯示占用cpu最高的n個線程 展示當前最忙的前3個線程并打印堆棧： ``` $ thread -n 3 "as-command-execute-daemon" Id=29 cpuUsage=75% RUNNABLE at sun.management.ThreadImpl.dumpThreads0(Native Method) at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:440) at com.taobao.arthas.core.command.monitor200.ThreadCommand$1.action(ThreadCommand.java:58) at com.taobao.arthas.core.command.handler.AbstractCommandHandler.execute(AbstractCommandHandler.java:238) at com.taobao.arthas.core.command.handler.DefaultCommandHandler.handleCommand(DefaultCommandHandler.java:67) at com.taobao.arthas.core.server.ArthasServer$4.run(ArthasServer.java:276) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Number of locked synchronizers = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@6cd0b6f8 "as-session-expire-daemon" Id=25 cpuUsage=24% TIMED_WAITING at java.lang.Thread.sleep(Native Method) at com.taobao.arthas.core.server.DefaultSessionManager$2.run(DefaultSessionManager.java:85) "Reference Handler" Id=2 cpuUsage=0% WAITING on java.lang.ref.Reference$Lock@69ba0f27 at java.lang.Object.wait(Native Method) - waiting on java.lang.ref.Reference$Lock@69ba0f27 at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) ``` 根據Arthas`thread`命令打印出來的堆棧信息定位具體的業務代碼，review代碼并嘗試定位邏輯。如有必要， 還可以通過`watch`子命令監聽某個方法的調用次數和資源占用情況 > 要注意的是，arthas的cpu占比，和前面兩種cpu占比統計方式不同。前面兩種針對的是Java進程啟動開始到現在的cpu占比情況，arthas這種是一段采樣間隔內，當前JVM里各個線程所占用的cpu時間占總cpu時間的百分比 ### 定位具體方法 1) GC線程 如果是GC線程一直在占用cpu，那么就基本確定是內存泄漏。進一步按照內存問題定位 2) 業務線程 如果是業務線程，那么根據下一節的方法，繼續定位是哪些代碼占用cpu * io wait * 比如磁盤空間不夠導致的io阻塞 * 等待內核態鎖，如 synchronized * `jstack -l pid | grep BLOCKED`查看阻塞態線程堆棧 * dump 線程棧，分析線程持鎖情況 * arthas提供了`thread -b`，可以找出當前阻塞其他線程的線程。針對 synchronized 情況