前言

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

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

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

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

2、kafka自動確認(rèn)

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

上游系統(tǒng)中產(chǎn)生了數(shù)據(jù)，寫入db之后，然后把相關(guān)業(yè)務(wù)單據(jù)的id，通過kafka消息發(fā)送到broker上。

下游系統(tǒng)訂閱相關(guān)topic的消息，獲取業(yè)務(wù)單據(jù)的id，然后調(diào)用上游系統(tǒng)的業(yè)務(wù)查詢接口，獲取相關(guān)業(yè)務(wù)數(shù)據(jù)。

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

剛開始問題不大。

隨著業(yè)務(wù)的發(fā)展，用戶量越來越多，每天產(chǎn)生的kafka消息也越來越多。

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

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

3、死循環(huán)

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

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

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

這兩種情況，程序會不停的運行，使用寄存器保存循環(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不斷飆高。

4、多線程導(dǎo)數(shù)據(jù)

之前我們組有位同事做了一個供應(yīng)商excel數(shù)據(jù)導(dǎo)入功能。

該功能上線之后發(fā)現(xiàn)excel中數(shù)據(jù)只要稍微多一點，導(dǎo)入的耗時時間就會很長。

因為導(dǎo)入供應(yīng)商相關(guān)的業(yè)務(wù)邏輯有些復(fù)雜，涉及了多張表，而且是單線程中一條條按順序?qū)氲摹?/p>

那位同事為了提升導(dǎo)入數(shù)據(jù)的性能，將單線程導(dǎo)入，改成了使用線程池的多線程導(dǎo)入。

這樣改造之后，excel數(shù)據(jù)導(dǎo)入的速度確實提升了很多。

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

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

5、同步大量文件

我之前參與過游戲平臺的開發(fā)。

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

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

當(dāng)時出于性能考慮，我們當(dāng)時使用了FreeMarker模板引擎，為每一款游戲都生成專門的html的靜態(tài)官網(wǎng)。

當(dāng)時提供了十幾個不同的模板，可以給游戲的運營同學(xué)選擇。

原本是沒啥問題的。

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

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

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

由于涉及到了大量文件的同步，導(dǎo)致存放文件的那臺應(yīng)用服務(wù)器CPU飆升的很高。

6、死鎖

為了防止并發(fā)場景中，多個線程修改公共資源，導(dǎo)致的數(shù)據(jù)異常問題。

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

這樣多個線程進入臨界方法或者代碼段時，需要競爭某個對象或者類的鎖，只有搶到相應(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使用率飆升。

7、正則匹配

不知道你使用過正則表達式?jīng)]有?

有時候我們?yōu)榱蓑炞C用戶輸入的手機號、郵箱、身份證號、網(wǎng)頁地址是否合法。

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

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

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

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

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

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

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

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

8、耗時計算

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

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

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

就可能會導(dǎo)致cpu飆高。

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