線上CPU飈高（死循環，死鎖...）

以前排除服務器內存暴增的問題，在此看到一篇相似的文章，作個相似的記錄。

1.top基本使用

top 命令運行圖：

第一行：基本信息

第二行：任務信息

第三行：CPU使用狀況

第四行：物理內存使用狀況

buff/cache：

buffers 和 cache 都是內存中存放的數據，不一樣的是，buffers 存放的是準備寫入磁盤的數據，而 cache 存放的是從磁盤中讀取的數據 

在Linux系統中，有一個守護進程(daemon)會按期把buffers中的數據寫入的磁盤，也可使用 sync 命令手動把buffers中的數據寫入磁盤。使用buffers能夠把分散的 I/O 操做集中起來，減小了磁盤尋道的時間和磁盤碎片。

cache是Linux把讀取頻率高的數據，放到內存中，減小I/O。Linux中cache沒有固定大小，根據使用狀況自動增長或刪除。

第五行：交換區使用狀況

Swap(內存交換區)：

　　是硬盤上的一塊空間。在內存不足的狀況下，操做系統把內存中不用的數據存到硬盤的交換區，騰出內存來讓別的程序運行。所以，開啓swap會必定程度的引發 I/O 性能降低(阿里服務器默認不開)

第六行：進程詳細信息

2.死循環

構造的代碼以下：

.

這裏只介紹一下用到的top參數

 

先手動製造CPU飆高的場景，多執行幾回，小編這裏執行3次

執行top

jstack命令工具能夠獲得線程堆棧信息，根據這些線程堆棧信息，咱們能夠去檢查Java程序出現的問題

看到pid爲23757的進程CPU佔用較高，執行以下命令

看看pid爲23757的進程中線程的具體狀況

 

固然你也可使用交互命令

而後再輸入H，效果和上面同樣

能夠看到PID爲23772,23773和23774的線程佔用CPU較高

這裏可能有人有疑惑，爲何線程也有PID啊？其實線程進程都會有本身的ID，這個ID就叫作PID，PID是不特指進程ID，線程ID也能夠叫作PID

將10進制的23772轉爲16進制，由於jstack中PID用的是16進制

打開loop.txt文件，搜5cdc

能夠看到線程一直在執行ShowTopController中的第23行，即

好了定位到代碼中的位置了，固然生產環境中確定不會寫一個死循環的，有可能在特殊場景下出現死循環，或執行一個方法特別慢，用這種方法很快就能找到代碼位置。

3.死鎖

接着訪問

執行

 

打開loop.txt文件到最後

看到發現一個死鎖，死鎖代碼的位置描述的很清楚，生產環境發生的死鎖固然沒有這麼簡單，全部學會用這些命令排查仍是頗有必要的

Java架構：https://blog.51cto.com/13732225/2347907