CPU被打滿的常見原因

1. 死循環(huán)

在實(shí)際工作中，可能每個開發(fā)都寫過死循環(huán)的代碼。

死循環(huán)有兩種：

1. 在 while、for、forEach 循環(huán)中的死循環(huán)。
2. 無限遞歸。

這兩種情況，程序會不停地運(yùn)行，使用寄存器保存循環(huán)次數(shù)或者遞歸深度，一直占用 cpu，導(dǎo)致 cpu 使用率飆升。

在使用 JDK1.7 時，還有些死循環(huán)比如多線程的環(huán)境下，往 HashMap 中 put 數(shù)據(jù)，可能會導(dǎo)致鏈表出現(xiàn)死循環(huán)。

就會導(dǎo)致cpu不斷飆高。

2.大量GC

我之前參與過餐飲相關(guān)的業(yè)務(wù)系統(tǒng)開發(fā)，當(dāng)時我所在的團(tuán)隊是菜品的下游業(yè)務(wù)。

當(dāng)時菜品系統(tǒng)有菜品的更新，會發(fā)kafka消息，我們系統(tǒng)訂閱該topic，就能獲取到最近更新的菜品數(shù)據(jù)。

同步菜品數(shù)據(jù)的功能，上線了一年多的時候，沒有出現(xiàn)過什么問題。

但在某一天下午，我們收到了大量 CPU100% 的報警郵件。

追查原因之后發(fā)現(xiàn)，菜品系統(tǒng)出現(xiàn)了 bug，我們每次獲取到的都是全量的菜品數(shù)據(jù)，并非增量的數(shù)據(jù)。

一次性獲取的數(shù)據(jù)太多。

菜品修改還是比較頻繁的，也就是說我們系統(tǒng)，會頻繁地讀取和解析大量的數(shù)據(jù)，導(dǎo)致 CPU 不斷飆升。

其根本原因是頻繁的full gc。

3. 大量計算密集型任務(wù)

有時候，我們的業(yè)務(wù)系統(tǒng)需要實(shí)時計算數(shù)據(jù)，比如：電商系統(tǒng)中需要實(shí)時計算優(yōu)惠后的最終價格。

或者需要在代碼中，從一堆數(shù)據(jù)中，統(tǒng)計匯總出我們所需要的數(shù)據(jù)。

如果這個實(shí)時計算或者實(shí)時統(tǒng)計的場景，是一個非常耗時的操作，并且該場景的請求并發(fā)量還不小，就可能會導(dǎo)致 cpu 飆高。

因為實(shí)時計算需要消耗 cpu 資源，如果一直計算，就會一直消耗 cpu 資源。

4. 死鎖

為了防止并發(fā)場景中，多個線程修改公共資源，導(dǎo)致的數(shù)據(jù)異常問題，很多時候我們會在代碼中使用synchronized或者Lock加鎖。

這樣多個線程進(jìn)入臨界方法或者代碼段時，需要競爭某個對象或者類的鎖，只有搶到相應(yīng)的鎖，才能訪問臨界資源。其他的線程，則需要等待，擁有鎖的線程釋放鎖，下一次可以繼續(xù)競爭那把鎖。

有些業(yè)務(wù)場景中，某段代碼需要線程獲取多把鎖，才能完成業(yè)務(wù)邏輯。

但由于代碼的 bug，或者釋放鎖的順序不正確，可能會引起死鎖的問題。

例如：

"pool-4-thread-1" prio=10 tid=0x00007f27bc11a000 nid=0x2ae9 waiting on condition [0x00007f2768ef9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0000000090e1d048> (a java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

比如線程 a 擁有鎖 c，需要獲取鎖 d，才能完成業(yè)務(wù)邏輯。

而剛好此時線程 b 擁有鎖 d，需要獲取鎖 c，才能完成業(yè)務(wù)邏輯。

線程 a 等待線程 b 釋放鎖，而線程 b 等待線程 a 釋放鎖，兩個線程都持有對方需要的鎖，無法主動釋放，就會出現(xiàn)死鎖問題。

死鎖會導(dǎo)致 CPU 使用率飆升。

CPU被打滿如何排查

1. 使用系統(tǒng)工具和JDK自帶的jstack工具

第一步：使用top命令找出占用CPU最高的Java進(jìn)程

首先，使用top命令確認(rèn)是不是Java進(jìn)程是罪魁禍?zhǔn)住ava進(jìn)程要么是個后臺任務(wù)，要么是個jar包，比如一個Spring Boot服務(wù)。

圖片

假設(shè)發(fā)現(xiàn)占用CPU 99.7%的線程是Java進(jìn)程，進(jìn)程PID為13731。

第二步：找到占用CPU最高的線程

接下來，還是用top命令，只不過加一個參數(shù)-Hp，就是下面這樣：

top -Hp 13731

H參數(shù)表示要顯示線程級別的信息，p則表示指定的pid，也就是進(jìn)程ID。執(zhí)行之后，這個Java進(jìn)程中占用線程占用CPU的情況就列出來了。假設(shè)占用CPU最高的那個線程PID為13756。

圖片

第三步：保存線程堆棧信息

這就要用到JDK默認(rèn)提供的一個工具——jstack。jstack用于生成Java進(jìn)程的線程快照（thread dump）。線程快照是一個關(guān)于Java進(jìn)程中所有線程當(dāng)前狀態(tài)的快照，包括每個線程的堆棧信息。通過分析線程快照，可以了解Java進(jìn)程中各個線程的運(yùn)行狀態(tài)、鎖信息等。

我們用jstack的目的是將那個占用CPU最高的線程的堆棧信息搞下來，然后進(jìn)一步分析。使用命令jstack pid > out.log將某個進(jìn)程的堆棧信息輸出到out.log文件中。

jstack 13731 > thread_stack.log

第四步：在線程棧中查找罪魁禍?zhǔn)椎木€程

將13756轉(zhuǎn)換為16進(jìn)制，可以用在線進(jìn)制轉(zhuǎn)換工具直接轉(zhuǎn)換，比如這個。轉(zhuǎn)換結(jié)果為0x35bc。

然后在線程棧中，也就是上一步保存的那個thread_stack.log文件，查找這個16進(jìn)制的線程ID（0x35bc）。

這樣，我們就能看到需要的線程名稱、線程狀態(tài)，哪個方法的哪一行代碼消耗了最多的CPU都很清楚了。

圖片

2. 使用Arthas探測工具

Arthas是阿里開源的一款線上監(jiān)控診斷產(chǎn)品，通過全局視角實(shí)時查看應(yīng)用load、內(nèi)存、GC、線程的狀態(tài)信息，并能在不修改應(yīng)用代碼的情況下，對業(yè)務(wù)問題進(jìn)行診斷，包括查看方法調(diào)用的入?yún)?、異常，監(jiān)測方法執(zhí)行耗時，類加載信息等，大大提升線上問題排查效率。

安裝Arthas

要使用Arthas，你需要先把它安裝到你的目標(biāo)服務(wù)器上。

1. 下載jar包：

curl -O https://arthas.aliyun.com/arthas-boot.jar

1. 啟動Arthas服務(wù)：

java -jar arthas-boot.jar

啟動之后，會列出當(dāng)前這臺服務(wù)器上的所有Java進(jìn)程，選擇你要排查的那個服務(wù)即可。出現(xiàn)arthas@之后表示已經(jīng)啟動，并成功attach到目標(biāo)進(jìn)程上。

圖片

可以輸入命令dashboard看一下實(shí)時面板，默認(rèn)5秒刷新一次，在這個面板上能夠看到線程、內(nèi)存堆棧、GC和Runtime的基本信息。如果你用過VisualVM的話，操作界面與之類似。

找到占用CPU最高的線程

執(zhí)行thread命令，這個命令會顯示所有線程的信息，并且把CPU使用率高的線程排在前面。

這樣，一眼就看出來了，第一個線程的CPU使用率高達(dá)99%。

圖片

查看堆棧信息

使用thread ID獲取堆棧信息，其實(shí)就是jstack pid相同的作用。通過前一步看到這個線程的ID是18，然后執(zhí)行：

thread 18

圖片

直接就看出來了出現(xiàn)問題的位置，比如TestController.java文件的high方法的第23行。然后可以進(jìn)入代碼查看具體問題。

參考答案

面試官：“你碰到過CPU 100%的情況嗎？你是怎么處理的？”

生產(chǎn)環(huán)境如果cpu已經(jīng)被打滿了，不要一上來就說什么top，jstack，記住，真實(shí)的生產(chǎn)環(huán)境如果CPU已經(jīng)要被打爆了的話

第一選擇肯定是重啟，并且如果你近段時間有發(fā)布的話，還要考慮是否可以回滾，保障生產(chǎn)環(huán)境的穩(wěn)定性是最重要的

還有就是，如果CPU已經(jīng)被打爆了，不管arthas還是jstack大概率也是執(zhí)行不了的，jvm無法響應(yīng)

我：“之前碰到過CPU被打滿的情況，我們線上第一時間做了重啟，在重啟的過程中，我們?nèi)ゲ榱朔?wù)在那段時間的日志、鏈路、指標(biāo)，沒有發(fā)現(xiàn)特殊的異常?！?/p>

有時候CPU100&會伴隨非常明顯的日志、鏈路或者指標(biāo)異常。例如：通過gc的指標(biāo)發(fā)現(xiàn)，發(fā)現(xiàn)full gc的次數(shù)激增，或者發(fā)現(xiàn)內(nèi)存的使用率很高，這個時候大概率是因為gc導(dǎo)致的cpu 100%。這個時候就不要再去jstack了，應(yīng)該第一次時間查看堆dump文件，確認(rèn)是哪個對象占用了大量內(nèi)存

我：“當(dāng)服務(wù)重啟完成后，我們開始排查具體的原因。我們通過定期執(zhí)行top命令，發(fā)現(xiàn)java進(jìn)程的CPU的使用率確實(shí)在慢慢增加”

我：“接著，我通過top -Hp以及jstack命令拿到了應(yīng)用里cpu使用率最高的那個線程的堆棧，通過分析堆棧最終定位到了具體的代碼，是因為代碼觸發(fā)了一個臨界值，進(jìn)入了死循環(huán)”

下面這段代碼是我實(shí)際工作碰到一個導(dǎo)致線上CPU 100%的代碼：

public ShortUrlRandomSeed getAvailableSeed()  {
  MachineInfo machineInfo = UrlConverUtil.getMachineInfo();
  for (; ; ) {
    // 獲取種子
    ShortUrlRandomSeed seed = shortUrlSeedService.getAvailableSeed(machineInfo);
    if (seed != null) {
      int influenceNum = shortUrlSeedService.updateSeedStatus(seed.getId());
      if (influenceNum > 0) {
        return seed;
      }
    }
  }
}

這段代碼的作用是為了獲取一個種子用于短鏈的生成，在項目上線之初預(yù)生成了接近21w個種子，這個代碼在線上跑了3年了一直沒有問題，直到去年的某一天，21w個種子用光了，seed一直為null，開始死循環(huán)，最終導(dǎo)致CPU 100%