直接上一個工作中碰到的問題，另外一個系統開啟多線程調用我這邊的接口，然后我這邊會開啟多線程批量查詢第三方接口並且返回給調用方。使用的是兩三年前別人遺留下來的方法，放到線上后發現確實是可以正常取到結果，但是一旦調用，CPU占用就直接100%(部署環境是win server服務器)。因此查看了下相關的老代碼並使用JProfiler查看發現是在某個while循環的時候有問題。具體項目代碼就不貼了，類似於下面這段代碼。
-
while(flag) {
-
//your code;
-
}
先放上我的解決方法，上述代碼修改如下：
-
while(flag) {
-
Thread.sleep(
1);
-
//your code;
-
}
為什么上述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)
參考了兩篇文章，寫得很好，在這里貼出來。