Thread.sleep(0)并不是寫錯了，而是有妙用？

來源：https://www.cnblogs.com/keyyang/p/4128424.html

我們可能經常會用到 Thread.Sleep 函數來使線程挂起一段時間。那麼你有沒有正确的了解這個函數的用法呢？思考下面這兩個問題：

1. 假設現在是 2008-4-7 12:00:00.000，如果我調用一下 Thread.Sleep(1000) ，在 2008-4-7 12:00:01.000 的時候，這個線程會不會被喚醒？
2. 某人的代碼中用了一句看似莫明其妙的話：Thread.Sleep(0) 。既然是 Sleep 0 毫秒，那麼他跟去掉這句代碼相比，有啥差別麼？

我們先回顧一下作業系統原理。

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

看完了 Thread.Sleep 的作用，我們再來想想文章開頭的兩個問題。

對于第一個問題，答案是：不一定。因為你隻是告訴作業系統：在未來的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一樣。

末了再說明一下，文中線程、程序有點混亂，其實在Windows原理層面，CPU競争都是線程級的，本文中把這裡的程序、線程看成同一個東西就好了。

最後，求關注。如果你還想看更多優質原創文章，歡迎關注我們的公衆号「運維開發故事」。

如果我的文章對你有所幫助，還請幫忙一下，你的支援會激勵我輸出更高品質的文章，非常感謝！

你還可以把我的公衆号設為「星标」，這樣當公衆号文章更新時，你會在第一時間收到推送消息，避免錯過我的文章更新。