資訊專欄INFORMATION COLUMN
摘要：指的是占用了一個(gè)核心，兩個(gè)核心是，以此類推。占用率及對應(yīng)進(jìn)程可以通過命令確定，在界面按顯示完整的命令行參數(shù)，按顯示每個(gè)核心的統(tǒng)計(jì)數(shù)據(jù)。查看線程堆棧，找到對應(yīng)的類及行號，然后閱讀代碼查找可能的問題原因。
100%指的是占用了CPU一個(gè)核心，兩個(gè)核心是200%，以此類推。
CPU占用率及對應(yīng)進(jìn)程ID（pid）可以通過top命令確定，在top界面按 c （顯示完整的命令行參數(shù)），按 1 （顯示每個(gè)核心的統(tǒng)計(jì)數(shù)據(jù)）。
這個(gè)問題最常見的有以下幾種可能：
1、堆內(nèi)存不足導(dǎo)致頻繁Full GC
可以通過兩個(gè)命令確定
sudo jmap -heap pid 查看堆內(nèi)存的消耗情況
sudo jstat -gc pid interval count 查看GC情況，示例：sudo jstat -gc 5746 3000 5 代表查看5746進(jìn)程的GC情況、每隔3000毫秒打印一次、總共打印5次。如果FGC/FGCT增長明顯，說明Full GC很頻繁。
后續(xù)處理：
如果情況緊急，那得馬上重啟Java應(yīng)用進(jìn)程
不緊急的話需要獲取相關(guān)信息用于分析為什么堆內(nèi)存被消耗完了，可能有內(nèi)存泄漏問題，可以用 1）sudo jmap -histo pid | head -n 20 查看Java對象的占用統(tǒng)計(jì)信息，2）sudo jmap -dump:live,format=b,file=heap.bin pid 把堆轉(zhuǎn)儲導(dǎo)出到本地文件，可以用 Eclipse MAT 工具分析內(nèi)存泄漏
2、代碼實(shí)現(xiàn)問題
思路：追查具體是哪個(gè)線程占用了CPU，1）先查到本地系統(tǒng)CPU占用率高的線程ID，2）找到對應(yīng)的Java線程及線程堆棧
top -H -p pid 查看某個(gè)進(jìn)程里面哪些線程占用了CPU，把對應(yīng)的線程ID拷貝下來，轉(zhuǎn)為十六進(jìn)制【IDEA》Tools》Groovy Console》println Long.toHexString(1234) 即可完成轉(zhuǎn)換】。
sudo jstack -l -F pid | less 獲取Java線程堆棧，用十六進(jìn)制的本地線程ID搜索，會在某一行的nid處找到對應(yīng)的線程。查看Java線程堆棧，找到對應(yīng)的Java類及行號，然后閱讀代碼查找可能的問題原因。
jstack堆棧信息里tid/nid的說明
https://docs.oracle.com/javas...
The thread dump consists of the thread stack, including the thread state, for all Java threads in the virtual machine. The header line contains the following information about the thread: - Thread ID (tid), which is the address of a thread structure in memory. - ID of the native thread (nid).
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/73757.html
摘要：很顯然對于不同規(guī)模，不同功能的系統(tǒng)，這個(gè)問題無法一概而論。生產(chǎn)事件上報(bào)客服上報(bào)此類問題往往來自用戶投訴，最重要的就是問題現(xiàn)象的復(fù)現(xiàn)。線上問題處理的核心是快速修復(fù)。以上說的都是問題發(fā)生后的消極應(yīng)對措施。 前言一線程序員在工作中經(jīng)常需要處理線上的問題或者故障，但工作幾年下來發(fā)現(xiàn)，有些同事其實(shí)并不知道該如何去分析和解決這些問題，毫無章法的猜測和嘗試，雖然在很多時(shí)候可以最終解決問題，但往往也會浪費(fèi)大...
摘要：發(fā)現(xiàn)這是的一個(gè)堆棧，前段時(shí)間正好解決過一個(gè)由于隊(duì)列引起的一次強(qiáng)如也發(fā)生內(nèi)存溢出沒想到又來一出。因此初步判斷為大量線程執(zhí)行函數(shù)之后互相競爭導(dǎo)致使用率增高，而通過對堆棧發(fā)現(xiàn)是和使用有關(guān)。 showImg(https://segmentfault.com/img/remote/1460000017395756?w=1816&h=1080); 前言 到了年底果然都不太平，最近又收到了運(yùn)維報(bào)警：...
閱讀 3462·2021-11-22 12:00
閱讀 679·2019-08-29 13:24
閱讀 2911·2019-08-29 11:31
閱讀 2599·2019-08-26 14:00
閱讀 3200·2019-08-26 11:42
閱讀 2481·2019-08-23 18:31
閱讀 806·2019-08-23 18:27
閱讀 2854·2019-08-23 16:58
