天天看點

while循環&CPU占用率高問題深入分析與解決方案

        直接上一個工作中碰到的問題,另外一個系統開啟多線程調用我這邊的接口,然後我這邊會開啟多線程批量查詢第三方接口并且傳回給調用方。使用的是兩三年前别人遺留下來的方法,放到線上後發現确實是可以正常取到結果,但是一旦調用,CPU占用就直接100%(部署環境是win server伺服器)。是以檢視了下相關的老代碼并使用JProfiler檢視發現是在某個while循環的時候有問題。具體項目代碼就不貼了,類似于下面這段代碼。

  1. while(flag) {
  2. //your code;
  3. }

這裡的flag可能是true或者是某個需要很長時間才能跳出這個循環的條件。

      先放上我的解決方法,上述代碼修改如下:

  1. while(flag) {
  2. Thread.sleep(1);
  3. //your code;
  4. }

之後CPU占用率就正常了。其實這裡面涉及到的知識點很多,我在網上也查了一些資料,現在分析下這個問題的原因以及相關解決方案。

為什麼上述while循環會使得CPU占用率很高呢

這裡就涉及到了作業系統的知識:作業系統中,CPU競争有很多種政策。Unix系統使用的是時間片算法,而Windows則屬于搶占式的。

       在時間片算法中,所有的程序排成一個隊列。作業系統按照他們的順序,給每個程序配置設定一段時間,即該程序允許運作的時間。如果在 時間片結束時程序還在運作,則CPU将被剝奪并配置設定給另一個程序。如果程序在時間片結束前阻塞或結束,則CPU當即進行切換。排程程 序所要做的就是維護一張就緒程序清單,,當程序用完它的時間片後,它被移到隊列的末尾。

       所謂搶占式作業系統,就是說如果一個程序得到了 CPU 時間,除非它自己放棄使用 CPU ,否則将完全霸占 CPU 。是以可以看出,在搶 占式作業系統中,作業系統假設所有的程序都是“人品很好”的,會主動退出 CPU 。在搶占式作業系統中,假設有若幹程序,作業系統會根據他們的優先級、饑餓時間(已經多長時間沒有使用過 CPU 了),給他們算出一 個總的優先級來。作業系統就會把 CPU 交給總優先級最高的這個程序。當程序執行完畢或者自己主動挂起後,作業系統就會重新計算一 次所有程序的總優先級,然後再挑一個優先級最高的把

CPU 控制權交給他。

       我們用分蛋糕的場景來描述這兩種算法。假設有源源不斷的蛋糕(源源不斷的時間),一副刀叉(一個CPU),10個等待吃蛋糕的人(10 個程序)。

      如果是 Unix作業系統來負責分蛋糕,那麼他會這樣定規矩:每個人上來吃 1 分鐘,時間到了換下一個。最後一個人吃完了就再從頭開始。于是,不管這10個人是不是優先級不同、饑餓程度不同、飯量不同,每個人上來的時候都可以吃 1 分鐘。當然,如果有人本來不太餓,或者飯量小,吃了30秒鐘之後就吃飽了,那麼他可以跟作業系統說:我已經吃飽了(挂起)。于是作業系統就會讓下一個人接着來。

如果是 Windows 作業系統來負責分蛋糕的,那麼場面就很有意思了。他會這樣定規矩:我會根據你們的優先級、饑餓程度去給你們每個人計算一個優先級。優先級最高的那個人,可以上來吃蛋糕——吃到你不想吃為止。等這個人吃完了,我再重新根據優先級、饑餓程度來計算每個人的優先級,然後再分給優先級最高的那個人。

      這樣看來,這個場面就有意思了——可能有些人是PPMM,是以具有高優先級,于是她就可以經常來吃蛋糕。可能另外一個人是個醜男,而去很ws,是以優先級特别低,于是好半天了才輪到他一次(因為随着時間的推移,他會越來越饑餓,是以算出來的總優先級就會越來越高,是以總有一天會輪到他的)。而且,如果一不小心讓一個大胖子得到了刀叉,因為他飯量大,可能他會霸占着蛋糕連續吃很久很久,導緻旁邊的人在那裡咽口水。。。

     而且,還可能會有這種情況出現:作業系統現在計算出來的結果,5号PPMM總優先級最高,而且高出别人一大截。是以就叫5号來吃蛋糕。5号吃了一小會兒,覺得沒那麼餓了,于是說“我不吃了”(挂起)。是以作業系統就會重新計算所有人的優先級。因為5号剛剛吃過,是以她的饑餓程度變小了,于是總優先級變小了;而其他人因為多等了一會兒,饑餓程度都變大了,是以總優先級也變大了。不過這時候仍然有可能5号的優先級比别的都高,隻不過現在隻比其他的高一點點——但她仍然是總優先級最高的啊。是以作業系統就會說:5号mm上來吃蛋糕……(5号mm心裡郁悶,這不剛吃過嘛……人家要減肥……誰叫你長那麼漂亮,獲得了那麼高的優先級)。

相關的解決方案及分析:

除了這裡使用的Thread.sleep(1),相關的還有Thread.sleep(0) Thread.yeild()

Thread.Sleep 函數是幹嗎的呢?還用剛才的分蛋糕的場景來描述。上面的場景裡面,5号MM在吃了一次蛋糕之後,覺得已經有8分飽了,她覺得在未來的半個小時之内都不想再來吃蛋糕了,那麼她就會跟作業系統說:在未來的半個小時之内不要再叫我上來吃蛋糕了。這樣,作業系統在随後的半個小時裡面重新計算所有人總優先級的時候,就會忽略5号mm。Sleep函數就是幹這事的,他告訴作業系統“在未來的多少毫秒内我不參與CPU競争”。

現在有兩個問題:

1.如果我調用一下 Thread.sleep(1000) ,一秒後,這個線程會 不會被喚醒?

2.Thread.sleep(0) 。既然是 sleep 0 毫秒,那麼他跟去掉這句代碼相比,有什麼差別?

       對于第一個問題,答案是:不一定。因為你隻是告訴作業系統:在未來的1000毫秒内我不想再參與到CPU競争。那麼1000毫秒過去之後,這時候也許另外一個線程正在使用CPU,那麼這時候作業系統是不會重新配置設定CPU的,直到那個線程挂起或結束;況且,即使這個時候恰巧輪到作業系統進行CPU 配置設定,那麼目前線程也不一定就是總優先級最高的那個,CPU還是可能被其他線程搶占去。

       與此相似的,Thread有個Resume函數,是用來喚醒挂起的線程的。好像上面所說的一樣,這個函數隻是“告訴作業系統我從現在起開始參與CPU競争了”,這個函數的調用并不能馬上使得這個線程獲得CPU控制權。

       對于第二個問題,答案是:有,而且差別很明顯。假設我們剛才的分蛋糕場景裡面,有另外一個PPMM 7号,她的優先級也非常非常高(因為非常非常漂亮),是以作業系統總是會叫道她來吃蛋糕。而且,7号也非常喜歡吃蛋糕,而且飯量也很大。不過,7号人品很好,她很善良,她沒吃幾口就會想:如果現在有别人比我更需要吃蛋糕,那麼我就讓給他。是以,她可以每吃幾口就跟作業系統說:我們來重新計算一下所有人的總優先級吧。不過,作業系統不接受這個建議——因為作業系統不提供這個接口。于是7号mm就換了個說法:“在未來的0毫秒之内不要再叫我上來吃蛋糕了”。這個指令作業系統是接受的,于是此時作業系統就會重新計算大家的總優先級——注意這個時候是連7号一起計算的,因為“0毫秒已經過去了”嘛。是以如果沒有比7号更需要吃蛋糕的人出現,那麼下一次7号還是會被叫上來吃蛋糕。

       是以,Thread.Sleep(0)的作用,就是“觸發作業系統立刻重新進行一次CPU競争”。競争的結果也許是目前線程仍然獲得CPU控制權,也許會換成别的線程獲得CPU控制權。這也是我們在大循環裡面經常會寫一句Thread.sleep(0) ,因為這樣就給了其他線程比如Paint線程獲得CPU控制權的權力,這樣界面就不會假死在那裡。末了說明一下,雖然上面提到說“除非它自己放棄使用 CPU ,否則将完全霸占

CPU”,但這個行為仍然是受到制約的——作業系統會監控你霸占CPU的情況,如果發現某個線程長時間霸占CPU,會強制使這個線程挂起,是以在實際上不會出現“一個線程一直霸占着 CPU 不放”的情況。至于我們的大循環造成程式假死,并不是因為這個線程一直在霸占着CPU。實際上在這段時間作業系統已經進行過多次CPU競争了,隻不過其他線程在獲得CPU控制權之後很短時間内馬上就退出了,于是就又輪到了這個線程繼續執行循環,于是就又用了很久才被作業系統強制挂起。是以反應到界面上,看起來就好像這個線程一直在霸占着CPU一樣。

Thread.Yeild()

        Yield 的中文翻譯為 “放棄”,這裡意思是主動放棄目前線程的時間片,并讓作業系統排程其它就緒态的線程使用一個時間片。但是如果調用 Yield,隻是把目前線程放入到就緒隊列中,而不是阻塞隊列。如果沒有找到其它就緒态的線程,則目前線程繼續運作。

優勢:比 Thread.Sleep(0) 速度要快,可以讓低于目前優先級的線程得以運作。可以通過傳回值判斷是否成功排程了其它線程。

劣勢:隻能排程同一個處理器的線程,不能排程其它處理器的線程。當沒有其它就緒的線程,會一直占用 CPU 時間片,造成 CPU 100%占用率

Thread.sleep(0)

  sleep 的意思是告訴作業系統自己要休息 n 毫秒,這段時間就讓給另一個就緒的線程吧。當 n=0 的時候,意思是要放棄自己剩下的時間片,但是仍然是就緒狀态,其實意思和 Yield 有點類似。但是 sleep(0) 隻允許那些優先級相等或更高的線程使用目前的CPU,其它線程隻能等着挨餓了。如果沒有合适的線程,那目前線程會重新使用 CPU 時間片。

優勢:相比 Yield,可以排程任何處理器的線程使用時間片。

劣勢:隻能排程優先級相等或更高的線程,意味着優先級低的線程很難獲得時間片,很可能永遠都調用不到。當沒有符合條件的線程,會一直占用 CPU 時間片,造成 CPU 100%占用率。

Thread.sleep(1)

       該方法使用 1 作為參數,這會強制目前線程放棄剩下的時間片,并休息 1 毫秒(因為不是實時作業系統,時間無法保證精确,一般可能會滞後幾毫秒或一個時間片)。但是以的好處是,所有其它就緒狀态的線程都有機會競争時間片,而不用在乎優先級。

優勢:可以排程任何處理器的線程使用時間片。無論有沒有符合的線程,都會放棄 CPU 時間,是以 CPU 占用率較低。

劣勢:相比 Thread.sleep(0),因為至少會休息一定時間,是以速度要更慢。

一般我會用Thread.sleep(1)

參考了兩篇文章,寫得很好,在這裡貼出來。

了解Thread.sleep()函數

Thread.Sleep(0) vs Sleep(1) vs Yeild

繼續閱讀