前言

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

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

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

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

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

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

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

追查原因之后發(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進(jìn)行通信的。

上游系統(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ù)。

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

剛開始問題不大。

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

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

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

3.死循環(huán)

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

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

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

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

在使用JDK1.7時(shí)，還有些死循環(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ù)只要稍微多一點(diǎn)，導(dǎo)入的耗時(shí)時(shí)間就會很長。

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

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

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

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

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

5.同步大量文件

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

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

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

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

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

原本是沒啥問題的。

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

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

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

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

6.死鎖

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

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

這樣多個線程進(jìn)入臨界方法或者代碼段時(shí)，需要競爭某個對象或者類的鎖，只有搶到相應(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ù)邏輯。

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

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

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

7.正則匹配

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

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

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

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

這個正則表達(dá)式可以分為三個部分：

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

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

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

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

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

8.耗時(shí)計(jì)算

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

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

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

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

因?yàn)閷?shí)時(shí)計(jì)算需要消耗cpu資源，如果一直計(jì)算，就會一直消耗cpu資源。