我們可能經(jīng)常會用到Thead.sleep()函數(shù)來吧使線程掛起一段時間。但是你真的了解這個函數(shù)的真正作用嗎？

先思考兩個問題：

假設(shè)現(xiàn)在是 2022-5-26 12:00:00.000，如果我調(diào)用一下 Thread.Sleep(1000) ，在 2022-5-26 12:00:01.000 的時候，這個線程會不會被喚醒？

Thread.Sleep(0) 。既然是 Sleep 0 毫秒，那么他跟去掉這句代碼相比，有啥區(qū)別么？

其實(shí)回答這個問題的本質(zhì)就是操作系統(tǒng)對資源的分配

不管有沒有學(xué)習(xí)過操作系統(tǒng)的小伙伴，都一起看一下操作系統(tǒng)的原理。

操作系統(tǒng)中，CPU競爭有很多種策略：

• Unix系統(tǒng)使用的是時間片算法
• 而Windows則屬于搶占式的。

在時間片算法中，所有的進(jìn)程排成一個隊(duì)列。操作系統(tǒng)按照他們的順序，給每個進(jìn)程分配一段時間，即該進(jìn)程允許運(yùn)行的時間。如果在時間片結(jié)束時進(jìn)程還在運(yùn)行，則CPU將被剝奪并分配給另一個進(jìn)程。如果進(jìn)程在時間片結(jié)束前阻塞或結(jié)束，則CPU當(dāng)即進(jìn)行切換。調(diào)度程序所要做的就是維護(hù)一張就緒進(jìn)程列表，當(dāng)進(jìn)程用完它的時間片后，它被移到隊(duì)列的末尾。

所謂搶占式操作系統(tǒng)，就是說如果一個進(jìn)程得到了 CPU 時間，除非它自己放棄使用 CPU ，否則將完全霸占 CPU 。因此可以看出，在搶占式操作系統(tǒng)中，操作系統(tǒng)假設(shè)所有的進(jìn)程都是“人品很好”的，會主動退出 CPU 。

在搶占式操作系統(tǒng)中，假設(shè)有若干進(jìn)程，操作系統(tǒng)會根據(jù)他們的優(yōu)先級、饑餓時間（已經(jīng)多長時間沒有使用過 CPU 了），給他們算出一個總的優(yōu)先級來。操作系統(tǒng)就會把 CPU 交給總優(yōu)先級最高的這個進(jìn)程。

當(dāng)進(jìn)程執(zhí)行完畢或者自己主動掛起后，操作系統(tǒng)就會重新計算一 次所有進(jìn)程的總優(yōu)先級，然后再挑一個優(yōu)先級最高的把 CPU 控制權(quán)交給他。

我們用分蛋糕的場景來描述這兩種算法。假設(shè)有源源不斷的蛋糕（源源不斷的時間），一副刀叉（一個CPU），10個等待吃蛋糕的人（10 個進(jìn)程）。

先來看看unix系統(tǒng)是怎么分蛋糕的：

如果是 Unix操作系統(tǒng)來負(fù)責(zé)分蛋糕，那么他會這樣定規(guī)矩：每個人上來吃 1 分鐘，時間到了換下一個。最后一個人吃完了就再從頭開始。于是，不管這10個人是不是優(yōu)先級不同、饑餓程度不同、飯量不同，每個人上來的時候都可以吃 1 分鐘。

當(dāng)然，如果有人本來不太餓，或者飯量小，吃了30秒鐘之后就吃飽了，那么他可以跟操作系統(tǒng)說：我已經(jīng)吃飽了（掛起）。于是操作系統(tǒng)就會讓下一個人接著來。

如果是 Windows 操作系統(tǒng)來負(fù)責(zé)分蛋糕的，那么場面就很有意思了。他會這樣定規(guī)矩：我會根據(jù)你們的優(yōu)先級、饑餓程度去給你們每個人計算一個優(yōu)先級。優(yōu)先級最高的那個人，可以上來吃蛋糕——吃到你不想吃為止。等這個人吃完了，我再重新根據(jù)優(yōu)先級、饑餓程度來計算每個人的優(yōu)先級，然后再分給優(yōu)先級最高的那個人。

這樣看來，這個場面就有意思了：可能有些人是個帥鍋或者是個美眉，因此具有高優(yōu)先級，于是她就可以經(jīng)常來吃蛋糕。可能另外一個人是個丑男，而去很ws，所以優(yōu)先級特別低，于是好半天了才輪到他一次（因?yàn)殡S著時間的推移，他會越來越饑餓，因此算出來的總優(yōu)先級就會越來越高，因此總有一天會輪到他的）。

而且，如果一不小心讓一個大胖子得到了刀叉，因?yàn)樗埩看?，可能他會霸占著蛋糕連續(xù)吃很久很久，導(dǎo)致旁邊的人在那里咽口水~

而且，還可能會有這種情況出現(xiàn)：操作系統(tǒng)現(xiàn)在計算出來的結(jié)果，5號PPMM總優(yōu)先級最高，而且高出別人一大截。因此就叫5號來吃蛋糕。5號吃了一小會兒，覺得沒那么餓了，于是說“我不吃了”（掛起）。因此操作系統(tǒng)就會重新計算所有人的優(yōu)先級。

因?yàn)?號剛剛吃過，因此她的饑餓程度變小了，于是總優(yōu)先級變小了；而其他人因?yàn)槎嗟攘艘粫海囸I程度都變大了，所以總優(yōu)先級也變大了。不過這時候仍然有可能5號的優(yōu)先級比別的都高，只不過現(xiàn)在只比其他的高一點(diǎn)點(diǎn)——但她仍然是總優(yōu)先級最高的啊。
因此操作系統(tǒng)就會說：5號mm上來吃蛋糕……（5號mm心里郁悶，這不剛吃過嘛……人家要減肥……誰叫你長那么漂亮，獲得了那么高的優(yōu)先級）。

那么問題來了，說了這一堆，Thread.Sleep 函數(shù)到底是干嗎的呢？

還用剛才的分蛋糕的場景來描述。上面的場景里面，5號MM在吃了一次蛋糕之后，覺得已經(jīng)有8分飽了，她覺得在未來的半個小時之內(nèi)都不想再來吃蛋糕了，那么她就會跟操作系統(tǒng)說：在未來的半個小時之內(nèi)不要再叫我上來吃蛋糕了。

這樣，操作系統(tǒng)在隨后的半個小時里面重新計算所有人總優(yōu)先級的時候，就會忽略5號mm。Sleep函數(shù)就是干這事的，他告訴操作系統(tǒng)“在未來的多少毫秒內(nèi)我不參與CPU競爭”。

知道了Sleep函數(shù)的作用之后，在回過頭來繼續(xù)看看文章初始時提到的兩個問題：

1.假設(shè)現(xiàn)在是 2022-5-26 12:00:00.000，如果我調(diào)用一下 Thread.Sleep(1000) ，在 2022-5-26 12:00:01.000 的時候，這個線程會不會被喚醒？

答案是：不一定。因?yàn)槟阒皇歉嬖V操作系統(tǒng)：在未來的1000毫秒內(nèi)我不想再參與到CPU競爭。那么1000毫秒過去之后，這時候也許另外一個線程正在使用CPU，那么這時候操作系統(tǒng)是不會重新分配CPU的，直到那個線程掛起或結(jié)束；況且，即使這個時候恰巧輪到操作系統(tǒng)進(jìn)行CPU 分配，那么當(dāng)前線程也不一定就是總優(yōu)先級最高的那個，CPU還是可能被其他線程搶占去。
與此相似的，Thread有個Resume函數(shù)，是用來喚醒掛起的線程的。好像上面所說的一樣，這個函數(shù)只是“告訴操作系統(tǒng)我從現(xiàn)在起開始參與CPU競爭了”，這個函數(shù)的調(diào)用并不能馬上使得這個線程獲得CPU控制權(quán)。

2.使用Thread.Sleep(0)跟去掉這句代碼相比，有啥區(qū)別么？

答案是：有，而且區(qū)別很明顯。假設(shè)我們剛才的分蛋糕場景里面，有另外一個PPMM 7號，她的優(yōu)先級也非常非常高（因?yàn)榉浅７浅Ｆ粒?，所以操作系統(tǒng)總是會叫道她來吃蛋糕。而且，7號也非常喜歡吃蛋糕，而且飯量也很大。不過，7號人品很好，她很善良，她沒吃幾口就會想：如果現(xiàn)在有別人比我更需要吃蛋糕，那么我就讓給他。

因此，她可以每吃幾口就跟操作系統(tǒng)說：我們來重新計算一下所有人的總優(yōu)先級吧。不過，操作系統(tǒng)不接受這個建議——因?yàn)椴僮飨到y(tǒng)不提供這個接口。于是7號mm就換了個說法：“在未來的0毫秒之內(nèi)不要再叫我上來吃蛋糕了”。這個指令操作系統(tǒng)是接受的，于是此時操作系統(tǒng)就會重新計算大家的總優(yōu)先級——注意這個時候是連7號一起計算的，因?yàn)?ldquo;0毫秒已經(jīng)過去了”嘛。因此如果沒有比7號更需要吃蛋糕的人出現(xiàn)，那么下一次7號還是會被叫上來吃蛋糕。

因此，Thread.Sleep(0)的作用，就是“觸發(fā)操作系統(tǒng)立刻重新進(jìn)行一次CPU競爭”。競爭的結(jié)果也許是當(dāng)前線程仍然獲得CPU控制權(quán)，也許會換成別的線程獲得CPU控制權(quán)。這也是我們在大循環(huán)里面經(jīng)常會寫一句Thread.Sleep(0) ，因?yàn)檫@樣就給了其他線程比如Paint線程獲得CPU控制權(quán)的權(quán)力，這樣界面就不會假死在那里。

另外，雖然上面提到說“除非它自己放棄使用 CPU ，否則將完全霸占 CPU”，但這個行為仍然是受到制約的——操作系統(tǒng)會監(jiān)控你霸占CPU的情況，如果發(fā)現(xiàn)某個線程長時間霸占CPU，會強(qiáng)制使這個線程掛起，因此在實(shí)際上不會出現(xiàn)“一個線程一直霸占著 CPU 不放”的情況。至于我們的大循環(huán)造成程序假死，并不是因?yàn)檫@個線程一直在霸占著CPU。

實(shí)際上在這段時間操作系統(tǒng)已經(jīng)進(jìn)行過多次CPU競爭了，只不過其他線程在獲得CPU控制權(quán)之后很短時間內(nèi)馬上就退出了，于是就又輪到了這個線程繼續(xù)執(zhí)行循環(huán)，于是就又用了很久才被操作系統(tǒng)強(qiáng)制掛起。。。因此反應(yīng)到界面上，看起來就好像這個線程一直在霸占著CPU一樣。

關(guān)于sleep()方法和yield()方法的區(qū)別如下

• sleep()方法暫停 當(dāng)前線程后，會給其他線程執(zhí)行機(jī)會，不會理會其他線程的優(yōu)先級:但yield()方法只會給優(yōu)先級相同，或優(yōu)先級更高的線程執(zhí)行機(jī)會。
• sleep()方法 會將線程轉(zhuǎn)入阻塞狀態(tài)，直到經(jīng)過阻塞時間才會轉(zhuǎn)入就緒狀態(tài);而yield()不會將線程轉(zhuǎn)入阻塞狀態(tài)，它只是強(qiáng)制當(dāng)前線程進(jìn)入就緒狀態(tài)。因此完全有可能某個線程調(diào)用yield()方法暫停之后，立即再次獲得處理器資源被執(zhí)行。
• sleep()方法聲明拋出了InterruptedException異常，所以調(diào)用sleep()方法時要么捕捉該異常,要么顯式聲明拋出該異常:而yield()方法則沒有聲明拋出任何異常。
• sleep()方法比yield()方法有更好的可移植性，通常不建議使用yield()方法來控制并發(fā)線程的執(zhí)行。

 到此這篇關(guān)于淺談Thread.sleep(0)到底有什么用的文章就介紹到這了,更多相關(guān)Thread.sleep(0)作用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論