cpu是時分(time division)的，操作系統里有很多線程，每個線程的運行時間由cpu決定，cpu會分給每個線程一個時間片，時間片是一個很短的時間長度，如果在時間片內，線程一直占有，則是100%；我們應該意識到，cpu運行速度很快（主頻非常高），除非密集型耗費cpu的運算，其它類型任務都會在小於時間片的時間內結束。
產生CPU100%的原因：
某一程序一直占用CPU是導致CPU100%的原因，大概有以下幾種情況：
1、Java 內存不夠或溢出導致GC overhead問題, GC overhead 導致的CPU 100%問題;
2、死循環問題. 如常見的HashMap被多個線程並發使用導致的死循環, 或者死循環;
3、某些操作一直占用CPU
第一步：使用top命令，查看占用cpu的進程
[root@sdfsdfseZ codeimage]# top
第二步：ps -ef | grep java 或jps命令，找出服務器的所有java進程
第三步：找出CPU耗用最厲害的進程pid
第四步：查找出具體占用cpu利用率最厲害的線程號，top -H -p pid 。然后按下shift+p，跳出CPU監控
當前線程號為：1747
第五步：將獲取到的線程號轉換成16進制
因為java線程棧文件中的線程id是十六進制，需要將線程id從十進制轉為十六進制。十進制 轉十六進制的命令如下：
結果為：
第六步：導出線程棧
將具體的占用CPU過高的java進程的線程棧導出，導出命令如下：
pid.tdump文件后綴名隨意，通常以tdump結尾。
[root@sdfsdfsdeZ codeimage]# jstack 1747 > tmp/1747.tdump
可能會拋出異常；
1747: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
原因分析
jvm運行時會生成一個目錄hsperfdata_$USER($USER是啟動java進程的用戶),在linux中默認是/tmp,目錄下會有些pid文件,存放jvm進程信息,而jmap,jstack等工具會讀取/tmp/hsperfdata_$USER下的pid文件獲取連接信息.
檢查了/tmp/hsperfdata_root目,,但在$TOMCAT_HOME目錄中的temp目錄中有對應的文件.
解決辦法
到
或使用
[root@iZ2zeab8t820b5ywp0rkfeZ bin]# jstack 1706 > /tmp/hsperfdata_root/1706.tdump
第七步：導出堆
[root@sddsdfsaZ bin]# jstat -gcutil 1706
第八步：jvisualvm分析快照
使用JAVA_HOME/bin/jvisualvm.exe，載入快照
文件----->載入—>文件類型（Dump）
