自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

閑魚一面:Thread.sleep(0) 到底有什么用?

開發(fā) 后端
我們可能經(jīng)常會(huì)用到 Thread.Sleep 函數(shù)來使線程掛起一段時(shí)間。那么你有沒有正確的理解這個(gè)函數(shù)的用法呢?來看一下吧。

思考下面這兩個(gè)問題:

假設(shè)現(xiàn)在是 2008-4-7 12:00:00.000,如果我調(diào)用一下 Thread.Sleep(1000) ,在 2008-4-7 12:00:01.000 的時(shí)候,這個(gè)線程會(huì) 不會(huì)被喚醒?

某人的代碼中用了一句看似莫明其妙的話:Thread.Sleep(0) 。

既然是 Sleep 0 毫秒,那么他跟去掉這句代碼相比,有啥區(qū)別么?我們先回顧一下操作系統(tǒng)原理。

操作系統(tǒng)中,CPU競(jìng)爭(zhēng)有很多種策略。Unix系統(tǒng)使用的是時(shí)間片算法,而Windows則屬于搶占式的。

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

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

在搶占式操作系統(tǒng)中,假設(shè)有若干進(jìn)程,操作系統(tǒng)會(huì)根據(jù)他們的優(yōu)先級(jí)、饑餓時(shí)間(已經(jīng)多長時(shí)間沒有使用過 CPU 了),給他們算出一 個(gè)總的優(yōu)先級(jí)來。操作系統(tǒng)就會(huì)把 CPU 交給總優(yōu)先級(jí)最高的這個(gè)進(jìn)程。當(dāng)進(jìn)程執(zhí)行完畢或者自己主動(dòng)掛起后,操作系統(tǒng)就會(huì)重新計(jì)算一 次所有進(jìn)程的總優(yōu)先級(jí),然后再挑一個(gè)優(yōu)先級(jí)最高的把 CPU 控制權(quán)交給他。

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

如果是 Unix操作系統(tǒng)來負(fù)責(zé)分蛋糕,那么他會(huì)這樣定規(guī)矩:每個(gè)人上來吃 1 分鐘,時(shí)間到了換下一個(gè)。最后一個(gè)人吃完了就再從頭開始。于是,不管這10個(gè)人是不是優(yōu)先級(jí)不同、饑餓程度不同、飯量不同,每個(gè)人上來的時(shí)候都可以吃 1 分鐘。當(dāng)然,如果有人本來不太餓,或者飯量小,吃了30秒鐘之后就吃飽了,那么他可以跟操作系統(tǒng)說:我已經(jīng)吃飽了(掛起)。于是操作系統(tǒng)就會(huì)讓下一個(gè)人接著來。

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

這樣看來,這個(gè)場(chǎng)面就有意思了——可能有些人是PPMM,因此具有高優(yōu)先級(jí),于是她就可以經(jīng)常來吃蛋糕。可能另外一個(gè)人是個(gè)丑男,而去很ws,所以優(yōu)先級(jí)特別低,于是好半天了才輪到他一次(因?yàn)殡S著時(shí)間的推移,他會(huì)越來越饑餓,因此算出來的總優(yōu)先級(jí)就會(huì)越來越高,因此總有一天會(huì)輪到他的)。

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

而且,還可能會(huì)有這種情況出現(xiàn):操作系統(tǒng)現(xiàn)在計(jì)算出來的結(jié)果,5號(hào)PPMM總優(yōu)先級(jí)最高,而且高出別人一大截。因此就叫5號(hào)來吃蛋糕。5號(hào)吃了一小會(huì)兒,覺得沒那么餓了,于是說“我不吃了”(掛起)。最新多線程面試題整理好了,大家可以在Java面試庫小程序在線刷題。

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

那么,Thread.Sleep 函數(shù)是干嗎的呢?還用剛才的分蛋糕的場(chǎng)景來描述。上面的場(chǎng)景里面,5號(hào)MM在吃了一次蛋糕之后,覺得已經(jīng)有8分飽了,她覺得在未來的半個(gè)小時(shí)之內(nèi)都不想再來吃蛋糕了,那么她就會(huì)跟操作系統(tǒng)說:在未來的半個(gè)小時(shí)之內(nèi)不要再叫我上來吃蛋糕了。這樣,操作系統(tǒng)在隨后的半個(gè)小時(shí)里面重新計(jì)算所有人總優(yōu)先級(jí)的時(shí)候,就會(huì)忽略5號(hào)mm。Sleep函數(shù)就是干這事的,他告訴操作系統(tǒng)“在未來的多少毫秒內(nèi)我不參與CPU競(jìng)爭(zhēng)”。

看完了 Thread.Sleep 的作用,我們?cè)賮硐胂胛恼麻_頭的兩個(gè)問題。

對(duì)于第一個(gè)問題,答案是:不一定。因?yàn)槟阒皇歉嬖V操作系統(tǒng):在未來的1000毫秒內(nèi)我不想再參與到CPU競(jìng)爭(zhēng)。那么1000毫秒過去之后,這時(shí)候也許另外一個(gè)線程正在使用CPU,那么這時(shí)候操作系統(tǒng)是不會(huì)重新分配CPU的,直到那個(gè)線程掛起或結(jié)束;況且,即使這個(gè)時(shí)候恰巧輪到操作系統(tǒng)進(jìn)行CPU 分配,那么當(dāng)前線程也不一定就是總優(yōu)先級(jí)最高的那個(gè),CPU還是可能被其他線程搶占去。

與此相似的,Thread有個(gè)Resume函數(shù),是用來喚醒掛起的線程的。好像上面所說的一樣,這個(gè)函數(shù)只是“告訴操作系統(tǒng)我從現(xiàn)在起開始參與CPU競(jìng)爭(zhēng)了”,這個(gè)函數(shù)的調(diào)用并不能馬上使得這個(gè)線程獲得CPU控制權(quán)。

對(duì)于第二個(gè)問題,答案是:有,而且區(qū)別很明顯。假設(shè)我們剛才的分蛋糕場(chǎng)景里面,有另外一個(gè)PPMM 7號(hào),她的優(yōu)先級(jí)也非常非常高(因?yàn)榉浅7浅F粒?,所以操作系統(tǒng)總是會(huì)叫道她來吃蛋糕。

另外,Java 多線程系列面試題和答案全部整理好了,大家可以在Java面試庫小程序在線刷題。

而且,7號(hào)也非常喜歡吃蛋糕,而且飯量也很大。不過,7號(hào)人品很好,她很善良,她沒吃幾口就會(huì)想:如果現(xiàn)在有別人比我更需要吃蛋糕,那么我就讓給他。因此,她可以每吃幾口就跟操作系統(tǒng)說:我們來重新計(jì)算一下所有人的總優(yōu)先級(jí)吧。不過,操作系統(tǒng)不接受這個(gè)建議——因?yàn)椴僮飨到y(tǒng)不提供這個(gè)接口。

于是7號(hào)mm就換了個(gè)說法:“在未來的0毫秒之內(nèi)不要再叫我上來吃蛋糕了”。這個(gè)指令操作系統(tǒng)是接受的,于是此時(shí)操作系統(tǒng)就會(huì)重新計(jì)算大家的總優(yōu)先級(jí)——注意這個(gè)時(shí)候是連7號(hào)一起計(jì)算的,因?yàn)椤?毫秒已經(jīng)過去了”嘛。因此如果沒有比7號(hào)更需要吃蛋糕的人出現(xiàn),那么下一次7號(hào)還是會(huì)被叫上來吃蛋糕。

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

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

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

末了再說明一下,文中線程、進(jìn)程有點(diǎn)混亂,其實(shí)在Windows原理層面,CPU競(jìng)爭(zhēng)都是線程級(jí)的,本文中把這里的進(jìn)程、線程看成同一個(gè)東西就好了。

責(zé)任編輯:龐桂玉 來源: Java技術(shù)棧
相關(guān)推薦

2022-08-29 10:52:37

線程函數(shù)操作系統(tǒng)

2024-11-18 17:06:11

Java線程

2020-10-20 09:57:04

量子計(jì)算人工智能技術(shù)

2022-07-29 08:25:02

volatileC語言原子

2022-12-28 08:10:31

ThreadjavaGC

2023-09-07 23:06:07

2024-02-28 16:18:41

2020-04-30 09:41:04

數(shù)據(jù)中臺(tái)CIO觀點(diǎn)

2019-05-16 10:30:49

JavaTCP協(xié)議

2021-05-11 10:44:51

飛行模式通信設(shè)備通信干擾

2019-10-14 10:29:42

Java消息隊(duì)列

2025-03-24 07:35:00

開發(fā)注解Spring

2021-04-28 09:55:52

JavaLock接口并發(fā)編程

2022-05-17 08:41:41

協(xié)程I/O模式

2024-10-15 09:48:56

2021-12-28 20:05:19

數(shù)字交通信息

2021-02-02 07:37:39

NextTickvueDOM

2018-06-26 14:29:44

LinuxUnix不同

2022-05-10 08:11:15

MySQL技巧結(jié)構(gòu)

2022-05-11 15:57:16

優(yōu)化SQL
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)