java程序 cpu佔用太高分析

         linux終端下用 top命令看到cpu佔用超過100%。之因此超過100%。說明cpu是多核。默認top顯示的是cpu加起來的使用率，運行top後按大鍵盤1看看，能夠顯示每一個cpu的使用率，top裏顯示的是把全部使用率加起來。若是是4核cpu佔用率最高可達400%。

 

java進程佔用CPU太高常見的兩種狀況及分析定位

https://blog.csdn.net/dingjianmin/article/details/85705812

在linux中的定位方法
4.1.找到CPU佔用高的進程號 如：使用top命令查看（可使用其它方法，只要找到對應的進程號便可）

注：圖中第一列PID爲進程號；

4.二、根據進程號找到CPU佔用高的線程
如：使用命令top -H -p (其中要換成第一步找到的進程號)

 

top鏈接參數說明

-H :Threads-mode operation
Instructs top to display individual threads. Without this command-line option a summation of all threads in each process is shown. Later this can be changed with the `H' interactive command.
 
-p :Monitor-PIDs mode as: -pN1 -pN2 ... or -pN1,N2,N3 ...
Monitor only processes with specified process IDs. This option can be given up to 20 times, or you can provide a comma delimited list with up to 20 pids. Co-mingling both approaches is permitted.
1
2
查看某個進程內部線程佔用狀況分析:
top -H -p 18605
 

 

注：圖中第一列PID此時爲線程號；

4.3.導出java進程執行堆棧，並找到對應的線程
使用jstack > jstack_xxx.txt (其中要換成第一步找到的進程號)
從第二步中的PID中找出一個CPU佔用高的線程號，把它轉成16進制，好比3261轉成CBD
從導出的堆棧信息裏找到nid爲cbd的線程堆棧

 

http://www.javashuo.com/article/p-vyrnyqvz-cy.html

 

4.4：從堆棧裏找到對應的代碼執行類和方法
若代碼爲業務代碼，則須要具體分析代碼，找出代碼中死循環或接近死循環的地方，並修正；定位結束；

若堆棧信息爲gc線程（相似下圖），則須要進行下一步

4.5：dump出java進程的堆對象使用狀況
使用jmap -histo > jmap_xxx.txt

找出量比較大的、且跟業務有關的對象，找到這些對象建立的地方進行分析；通常須要持續建立大量的對象，使得內存不夠用時，纔會頻繁觸發gc進行回收，gc回收時jvm有停頓，CPU也佔用很高。

線程之間的切換，是很耗費性能的，因此帶來CPU飆升.
新生代設置太小，也會頻繁觸發gc。有大對象始終根節點路徑可達，沒法釋放,jvm在瘋狂的Full GC。
---------------------
 

 

一篇文章：

https://blog.csdn.net/whupanyinghua/article/details/51649819

 

簡單記錄下對這個問題的跟蹤

首先固然要看下具體是java中哪一個線程一直在佔用cpu時間哈(說明下， java進程號是 26178)
1.根據java進程ID進行CPU佔用排查  ps -mp 26178 -o THREAD,tid,time | sort -rn | more  （sort -rn 以數值的方式進行逆序排列）

 

2.根據1中查找到的CPU最高的排序中的結果，找出幾個佔用cpu時間比較高的TID，好比這裏的26217 26182 26183
將進程ID轉換爲16進制，printf "%x\n" 26217

3.再使用jstack命名查詢是哪一個線程
TID十進制-》十六進制
26217 -》 6669
26182 -》 6646
26183 -》 6647
拿到線程ID的16進制以後，就能夠從jstack中查找具體是對應的線程
jstack 26178 |grep 6669 -A 30

能夠發現，幾個佔用大量cpu時間的線程都是GC相關。

（grep -A:

Context control:
-B, --before-context=NUM print NUM lines of leading context
-A, --after-context=NUM print NUM lines of trailing context

找出filename中帶有keyword的行，輸出中除顯示該行外，還顯示以後的x行。其中，數字能夠變。

 

-C, --context=NUM print NUM lines of output context

 

）

 

4.再次確認gc信息，查看gc time等信息，jstat -gcutil 26178 1000 100

 

能夠看到s0、s一、eden、old、metaspace都已經爆了，而且FGC次數一直在增長，可是卻沒有回收到任何空間，致使FGC一直在跑，進入循環，應該是程序存在內存泄露咯。（gc有日誌，後續有空再出一篇簡單分析gc日誌的blog）

5.jmap -histo:live 26178 | more  簡單查看對象的大小數目

6.dump內存，使用工具分析內存鏡像，jmap -dump:live,format=b,file=problem.bin 26178

7.使用MAT（Memory Analyzer tool）進行數據分析，注意，若是步驟6中dump出來文件過大，須要設置MAT配置文件（MemoryAnalyzer.ini）的xmx參數的大小。---------------------