前言

cpu使用率100%問題，是一個讓人非常頭疼的問題。因為出現這類問題的原因千奇百怪，最關鍵的是它不是必現的，有可能是系統運行了一段時間之后，在突然的某個時間點出現問題。

今天特地把我和同事，之前遇到過的cpu使用率100%的問題，總結了一下，給有需要的朋友一個參數。

1.一次性獲取的數據太多

我之前參與過餐飲相關的業務系統開發，當時我所在的團隊是菜品的下游業務。

當時菜品系統有菜品的更新，會發kafka消息，我們系統訂閱該topic，就能獲取到最近更新的菜品數據。

同步菜品數據的功能，上線了一年多的時候，沒有出現過什么問題。

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

追查原因之后發現，菜品系統出現了bug，我們每次獲取到的都是全量的菜品數據，并非增量的數據。

一次性獲取的數據太多。

菜品修改還是比較頻繁的，也就是說我們系統，會頻繁的讀取和解析大量的數據，導致CPU不斷飆升。

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

2.kafka自動確認

之前我們的餐飲子系統中間，是通過消息中間件：kafka進行通信的。

上游系統中產生了數據，寫入db之后，然后把相關業務單據的id，通過kafka消息發送到broker上。

下游系統訂閱相關topic的消息，獲取業務單據的id，然后調用上游系統的業務查詢接口，獲取相關業務數據。

剛開始為了方便，我們消費訂單消息時，kafka的確認機制，使用的是自動確認（可以少寫點代碼）。

剛開始問題不大。

隨著業務的發展，用戶量越來越多，每天產生的kafka消息也越來越多。

終于開始爆出了cpu使用率100%的問題。

后來，我們把kafka的consumer，消費消息后改成手動確認，cpu使用率100%的問題就被解決了。

3.死循環

在實際工作中，可能每個開發都寫過死循環的代碼。

死循環有兩種：

• 在while、for、forEach循環中的死循環。
• 無限遞歸。

這兩種情況，程序會不停的運行，使用寄存器保存循環次數或者遞歸深度，一直占用cpu，導致cpu使用率飆升。

在使用JDK1.7時，還有些死循環比如多線程的環境下，往HashMap中put數據，可能會導致鏈表出現死循環。

就會導致cpu不斷飆高。

4.多線程導數據

之前我們組有位同事做了一個供應商excel數據導入功能。

該功能上線之后發現excel中數據只要稍微多一點，導入的耗時時間就會很長。

因為導入供應商相關的業務邏輯有些復雜，涉及了多張表，而且是單線程中一條條按順序導入的。

那位同事為了提升導入數據的性能，將單線程導入，改成了使用線程池的多線程導入。

這樣改造之后，excel數據導入的速度確實提升了很多。

但上線之后，卻帶來另外一個問題，即：CPU使用率一路飆升。

多線程導入數據，如果線程數量比較多，會存在大量線程上下文切換的過程，這個過程非常消耗CPU資源。

5.同步大量文件

我之前參與過游戲平臺的開發。

游戲廠商的游戲接入我們平臺，我們幫他們推廣，賺了錢進行分成。

每一款游戲都有一個定制化的官網，域名、圖片和樣式都不一樣。

當時出于性能考慮，我們當時使用了FreeMarker模板引擎，為每一款游戲都生成專門的html的靜態官網。

當時提供了十幾個不同的模板，可以給游戲的運營同學選擇。

原本是沒啥問題的。

但有一次節日活動，為了增加一些喜慶的元素，在每一個模板文件中都加了一些樣式。

這就需要把所有游戲的官網，用新的模板重新生成一次了。

生成完畢之后，需要把所有的html文件，一次性同步到web服務器的指定目錄下。

由于涉及到了大量文件的同步，導致存放文件的那臺應用服務器CPU飆升的很高。

6.死鎖

為了防止并發場景中，多個線程修改公共資源，導致的數據異常問題。

很多時候我們會在代碼中使用synchronized或者Lock加鎖。

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

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

但由于代碼的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，才能完成業務邏輯。

而剛好此時線程b擁有鎖d，需要獲取鎖c，也能完成業務邏輯。

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

死鎖會導致CPU使用率飆升。

7.正則匹配

不知道你使用過正則表達式沒有?

有時候我們為了驗證用戶輸入的手機號、郵箱、身份證號、網頁地址是否合法。

通常情況下，會使用正則表達式，例如：

^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~/])+$

這個正則表達式可以分為三個部分：

• 第一部分匹配 http 和 https 協議。
• 第二部分匹配 www. 字符。
• 第三部分匹配許多字符。

一個寫的不好的正則表達式，就可以導致cpu使用率一下子飚升。

其實這里導致 CPU 使用率高的關鍵原因就是：Java 正則表達式使用的引擎實現是NFA自動機，這種正則表達式引擎在進行字符匹配時會發生回溯。

而一旦發生回溯，那其消耗的時間就會變得很長，有可能是幾分鐘，也有可能是幾個小時，時間長短取決于回溯的次數和復雜度。

我們寫的正則表達式，要盡量減少回溯。

8.耗時計算

有時候，我們的業務系統需要實時計算數據，比如：電商系統中需要實時計算優惠后的最終價格。

或者需要在代碼中，從一堆數據中，統計匯總出我們所需要的數據。

如果這個實時計算或者實時統計的場景，是一個非常耗時的操作，并且該場景的請求并發量還不小。

就可能會導致cpu飆高。

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