前言
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資源。