

下載本文檔
版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
1、 5/5JAVA線程池原理以及幾種線程池類型介紹 在什么情況下使用線程池? 1.單個(gè)任務(wù)處理的時(shí)間比較短 2.將需處理的任務(wù)的數(shù)量大 使用線程池的好處: 1.減少在創(chuàng)建和銷毀線程上所花的時(shí)間以及系統(tǒng)資源的開(kāi)銷 2.如不使用線程池,有可能造成系統(tǒng)創(chuàng)建大量線程而導(dǎo)致消耗完系統(tǒng)內(nèi)存以及”過(guò)度切換”。 線程池工作原理: 線程池為線程生命周期開(kāi)銷問(wèn)題和資源不足問(wèn)題提供了解決方案。通過(guò)對(duì)多個(gè)任務(wù)重用線程,線程創(chuàng)建的開(kāi)銷被分?jǐn)偟搅硕鄠€(gè)任務(wù)上。其好處是,因?yàn)樵谡?qǐng)求到達(dá)時(shí)線程已經(jīng)存在,所以無(wú)意中也消除了線程創(chuàng)建所帶來(lái)的延遲。這樣,就可以立即為請(qǐng)求服務(wù),使應(yīng)用程序響應(yīng)更快。而且,通過(guò)適當(dāng)?shù)卣{(diào)整線程池中的線程數(shù)目,
2、也就是當(dāng)請(qǐng)求的數(shù)目超過(guò)某個(gè)閾值時(shí),就強(qiáng)制其它任何新到的請(qǐng)求一直等待,直到獲得一個(gè)線程來(lái)處理為止,從而可以防止資源不足。 線程池的替代方案 線程池遠(yuǎn)不是服務(wù)器應(yīng)用程序內(nèi)使用多線程的唯一方法。如同上面所提到的,有時(shí),為每個(gè)新任務(wù)生成一個(gè)新線程是十分明智的。然而,如果任務(wù)創(chuàng)建過(guò)于頻繁而任務(wù)的平均處理時(shí)間過(guò)短,那么為每個(gè)任務(wù)生成一個(gè)新線程將會(huì)導(dǎo)致性能問(wèn)題。 另一個(gè)常見(jiàn)的線程模型是為某一類型的任務(wù)分配一個(gè)后臺(tái)線程與任務(wù)隊(duì)列。AWT 和 Swing 就使用這個(gè)模型,在這個(gè)模型中有一個(gè) GUI 事件線程,導(dǎo)致用戶界面發(fā)生變化的所有工作都必須在該線程中執(zhí)行。然而,由于只有一個(gè) AWT 線程,因此要在 AWT
3、線程中執(zhí)行任務(wù)可能要花費(fèi)相當(dāng)長(zhǎng)時(shí)間才能完成,這是不可取的。因此,Swing 應(yīng)用程序經(jīng)常需要額外的工作線程,用于運(yùn)行時(shí)間很長(zhǎng)的、同 UI 有關(guān)的任務(wù)。 每個(gè)任務(wù)對(duì)應(yīng)一個(gè)線程方法和單個(gè)后臺(tái)線程(single-background-thread)方法在某些情形下都工作得非常理想。每個(gè)任務(wù)一個(gè)線程方法在只有少量運(yùn)行時(shí)間很長(zhǎng)的任務(wù)時(shí)工作得十分好。而只要調(diào)度可預(yù)見(jiàn)性不是很重要,則單個(gè)后臺(tái)線程方法就工作得十分好,如低優(yōu)先級(jí)后臺(tái)任務(wù)就是這種情況。然而,大多數(shù)服務(wù)器應(yīng)用程序都是面向處理大量的短期任務(wù)或子任務(wù),因此往往希望具有一種能夠以低開(kāi)銷有效地處理這些任務(wù)的機(jī)制以及一些資源管理和定時(shí)可預(yù)見(jiàn)性的措施。線程池提
4、供了這些優(yōu)點(diǎn)。 工作隊(duì)列 就線程池的實(shí)際實(shí)現(xiàn)方式而言,術(shù)語(yǔ)“線程池”有些使人誤解,因?yàn)榫€程池“明顯的”實(shí)現(xiàn)在大多數(shù)情形下并不一定產(chǎn)生我們希望的結(jié)果。術(shù)語(yǔ)“線程池”先于Java 平臺(tái)出現(xiàn),因此它可能是較少面向?qū)ο蠓椒ǖ漠a(chǎn)物。然而,該術(shù)語(yǔ)仍繼續(xù)廣泛應(yīng)用著。 雖然我們可以輕易地實(shí)現(xiàn)一個(gè)線程池類,其中客戶機(jī)類等待一個(gè)可用線程、將任務(wù)傳遞給該線程以便執(zhí)行、然后在任務(wù)完成時(shí)將線程歸還給池,但這種方法卻存在幾個(gè)潛在的負(fù)面影響。例如在池為空時(shí),會(huì)發(fā)生什么呢?試圖向池線程傳遞任務(wù)的調(diào)用者都會(huì)發(fā)現(xiàn)池為空,在調(diào)用者等待一個(gè)可用的池線程時(shí),它的線程將阻塞。我們之所以要使用后臺(tái)線程的原因之一常常是為了防止正在提交的線程
5、被阻塞。完全堵住調(diào)用者,如在線程池的“明顯的”實(shí)現(xiàn)的情況,可以杜絕我們?cè)噲D解決的問(wèn)題的發(fā)生。 我們通常想要的是同一組固定的工作線程相結(jié)合的工作隊(duì)列,它使用 wait() 和 / If we dont catch RuntimeException, / the pool could leak threads try r.run(); catch (RuntimeException e) / You might want to log something here 您可能已經(jīng)注意到了清單 1 中的實(shí)現(xiàn)使用的是 notify() 而不是 notifyAll() 。大多數(shù)專家建議使用 notifyAl
6、l() 而不是 notify() ,而且理由很充分:使用 notify() 具有難以捉摸的風(fēng)險(xiǎn),只有在某些特定條件下使用該方法才是合適的。另一方面,如果使用得當(dāng), notify() 具有比 notifyAll() 更可取的性能特征;特別是, notify() 引起的環(huán)境切換要少得多,這一點(diǎn)在服務(wù)器應(yīng)用程序中是很重要的。 清單 1 中的示例工作隊(duì)列滿足了安全使用 notify() 的需求。因此,請(qǐng)繼續(xù),在您的程序中使用它,但在其它情形下使用 notify() 時(shí)請(qǐng)格外小心。 使用線程池的風(fēng)險(xiǎn) 雖然線程池是構(gòu)建多線程應(yīng)用程序的強(qiáng)大機(jī)制,但使用它并不是沒(méi)有風(fēng)險(xiǎn)的。用線程池構(gòu)建的應(yīng)用程序容易遭受任何其
7、它多線程應(yīng)用程序容易遭受的所有并發(fā)風(fēng)險(xiǎn),諸如同步錯(cuò)誤和死鎖,它還容易遭受特定于線程池的少數(shù)其它風(fēng)險(xiǎn),諸如與池有關(guān)的死鎖、資源不足和線程泄漏。 死鎖 任何多線程應(yīng)用程序都有死鎖風(fēng)險(xiǎn)。當(dāng)一組進(jìn)程或線程中的每一個(gè)都在等待一個(gè)只有該組中另一個(gè)進(jìn)程才能引起的事件時(shí),我們就說(shuō)這組進(jìn)程或線程死鎖了。死鎖的最簡(jiǎn)單情形是:線程 A 持有對(duì)象 X 的獨(dú)占鎖,并且在等待對(duì)象 Y 的鎖,而線程 B 持有對(duì)象 Y 的獨(dú)占鎖,卻在等待對(duì)象 X 的鎖。除非有某種方法來(lái)打破對(duì)鎖的等待(Java 鎖定不支持這種方法),否則死鎖的線程將永遠(yuǎn)等下去。 雖然任何多線程程序中都有死鎖的風(fēng)險(xiǎn),但線程池卻引入了另一種死鎖可能,在那種情況下
8、,所有池線程都在執(zhí)行已阻塞的等待隊(duì)列中另一任務(wù)的執(zhí)行結(jié)果的任務(wù),但這一任務(wù)卻因?yàn)闆](méi)有未被占用的線程而不能運(yùn)行。當(dāng)線程池被用來(lái)實(shí)現(xiàn)涉及許多交互對(duì)象的模擬,被模擬的對(duì)象可以相互發(fā)送查詢,這些查詢接下來(lái)作為排隊(duì)的任務(wù)執(zhí)行,查詢對(duì)象又同步等待著響應(yīng)時(shí),會(huì)發(fā)生這種情況。 資源不足 線程池的一個(gè)優(yōu)點(diǎn)在于:相對(duì)于其它替代調(diào)度機(jī)制(有些我們已經(jīng)討論過(guò))而言,它們通常執(zhí)行得很好。但只有恰當(dāng)?shù)卣{(diào)整了線程池大小時(shí)才是這樣的。線程消耗包括內(nèi)存和其它系統(tǒng)資源在內(nèi)的大量資源。除了 Thread 對(duì)象所需的內(nèi)存之外,每個(gè)線程都需要兩個(gè)可能很大的執(zhí)行調(diào)用堆棧。除此以外,JVM 可能會(huì)為每個(gè)Java 線程創(chuàng)建一個(gè)本機(jī)線程,這些
9、本機(jī)線程將消耗額外的系統(tǒng)資源。最后,雖然線程之間切換的調(diào)度開(kāi)銷很小,但如果有很多線程,環(huán)境切換也可能嚴(yán)重地影響程序的性能。 如果線程池太大,那么被那些線程消耗的資源可能嚴(yán)重地影響系統(tǒng)性能。在線程之間進(jìn)行切換將會(huì)浪費(fèi)時(shí)間,而且使用超出比您實(shí)際需要的線程可能會(huì)引起資源匱乏問(wèn)題,因?yàn)槌鼐€程正在消耗一些資源,而這些資源可能會(huì)被其它任務(wù)更有效地利用。除了線程自身所使用的資源以外,服務(wù)請(qǐng)求時(shí)所做的工作可能需要其它資源,例如 JDBC 連接、套接字或文件。這些也都是有限資源,有太多的并發(fā)請(qǐng)求也可能引起失效,例如不能分配 JDBC 連接。 并發(fā)錯(cuò)誤 線程池和其它排隊(duì)機(jī)制依靠使用 wait() 和 notify
10、() 方法,這兩個(gè)方法都難于使用。如果編碼不正確,那么可能丟失通知,導(dǎo)致線程保持空閑狀態(tài),盡管隊(duì)列中有工作要處理。使用這些方法時(shí),必須格外小心;即便是專家也可能在它們上面出錯(cuò)。而最好使用現(xiàn)有的、已經(jīng)知道能工作的實(shí)現(xiàn),例如在下面的無(wú)須編寫(xiě)您自己的池中討論的 util.concurrent 包。 線程泄漏 各種類型的線程池中一個(gè)嚴(yán)重的風(fēng)險(xiǎn)是線程泄漏,當(dāng)從池中除去一個(gè)線程以執(zhí)行一項(xiàng)任務(wù),而在任務(wù)完成后該線程卻沒(méi)有返回池時(shí),會(huì)發(fā)生這種情況。發(fā)生線程泄漏的一種情形出現(xiàn)在任務(wù)拋出一個(gè) RuntimeException 或一個(gè) Error 時(shí)。如果池類沒(méi)有捕捉到它們,那么線程只會(huì)退出而線程池的大小將會(huì)永久減
11、少一個(gè)。當(dāng)這種情況發(fā)生的次數(shù)足夠多時(shí),線程池最終就為空,而且系統(tǒng)將停止,因?yàn)闆](méi)有可用的線程來(lái)處理任務(wù)。 有些任務(wù)可能會(huì)永遠(yuǎn)等待某些資源或來(lái)自用戶的輸入,而這些資源又不能保證變得可用,用戶可能也已經(jīng)回家了,諸如此類的任務(wù)會(huì)永久停止,而這些停止的任務(wù)也會(huì)引起和線程泄漏同樣的問(wèn)題。如果某個(gè)線程被這樣一個(gè)任務(wù)永久地消耗著,那么它實(shí)際上就被從池除去了。對(duì)于這樣的任務(wù),應(yīng)該要么只給予它們自己的線程,要么只讓它們等待有限的時(shí)間。 請(qǐng)求過(guò)載 僅僅是請(qǐng)求就壓垮了服務(wù)器,這種情況是可能的。在這種情形下,我們可能不想將每個(gè)到來(lái)的請(qǐng)求都排隊(duì)到我們的工作隊(duì)列,因?yàn)榕旁陉?duì)列中等待執(zhí)行的任務(wù)可能會(huì)消耗太多的系統(tǒng)資源并引起資
12、源缺乏。在這種情形下決定如何做取決于您自 己;在某些情況下,您可以簡(jiǎn)單地拋棄請(qǐng)求,依靠更高級(jí)別的協(xié)議稍后重試請(qǐng)求,您也可以用一個(gè)指出服務(wù)器暫時(shí)很忙的響應(yīng)來(lái)拒絕請(qǐng)求。 有效使用線程池的準(zhǔn)則 只要您遵循幾條簡(jiǎn)單的準(zhǔn)則,線程池可以成為構(gòu)建服務(wù)器應(yīng)用程序的極其有效的方法: ?不要對(duì)那些同步等待其它任務(wù)結(jié)果的任務(wù)排隊(duì)。這可能會(huì)導(dǎo)致上面所描述的那種形式的死鎖,在那種死鎖中,所有線程都被一些任務(wù)所占用,這些任務(wù)依次等待排隊(duì)任務(wù)的結(jié)果,而這些任務(wù)又無(wú)法執(zhí)行,因?yàn)樗械木€程 都很忙。 ?在為時(shí)間可能很長(zhǎng)的操作使用合用的線程時(shí)要小心。如果程序必須等待諸如 I/O 完成這樣的某個(gè)資源,那么請(qǐng)指定最長(zhǎng)的等待時(shí)間,以及
13、隨后是 失效還是將任務(wù)重新排隊(duì)以便稍后執(zhí)行。這樣做保證了:通過(guò)將某個(gè)線程釋放給某個(gè)可能成功完成的任務(wù),從而將最終取得某些進(jìn)展。 ?理解任務(wù)。要有效地調(diào)整線程池大小,您需要理解正在排隊(duì)的任務(wù)以及它們正在做什么。它們是 CPU 限制的(CPU-bound)嗎?它們是 I/O 限制 的(I/O-bound)嗎?您的答案將影響您如何調(diào)整應(yīng)用程序。如果您有不 同的任務(wù)類,這些類有著截然不同的特征,那么為不同任務(wù)類設(shè)置多個(gè)工 作隊(duì)列可能會(huì)有意義,這樣可以相應(yīng)地調(diào)整每個(gè)池。 調(diào)整池的大小 調(diào)整線程池的大小基本上就是避免兩類錯(cuò)誤:線程太少或線程太多。幸運(yùn)的是,對(duì)于大多數(shù)應(yīng)用程序來(lái)說(shuō),太多和太少之間的余地相當(dāng)寬
14、。 請(qǐng)回憶:在應(yīng)用程序中使用線程有兩個(gè)主要優(yōu)點(diǎn),盡管在等待諸如 I/O 的慢操作,但允許繼續(xù)進(jìn)行處理,并且可以利用多處理器。在運(yùn)行于具有 N 個(gè)處理器機(jī)器上的計(jì)算限制的應(yīng)用程序中,在線程數(shù)目接近 N 時(shí)添加額外的線程可能會(huì)改善總處理能力,而在線程數(shù)目超過(guò) N 時(shí)添加額外的線程將不起作用。事實(shí)上,太多的線程甚至?xí)档托阅?,因?yàn)樗鼤?huì)導(dǎo)致額外的環(huán)境切換開(kāi)銷。 線程池的最佳大小取決于可用處理器的數(shù)目以及工作隊(duì)列中的任務(wù)的性質(zhì)。若在一個(gè)具有 N 個(gè)處理器的系統(tǒng)上只有一個(gè)工作隊(duì)列,其中全部是計(jì)算性質(zhì)的任務(wù),在線程池具有 N 或 N+1 個(gè)線程時(shí)一般會(huì)獲得最大的 CPU 利用率。 對(duì)于那些可能需要等待 I/
15、O 完成的任務(wù)(例如,從套接字讀取 HTTP 請(qǐng)求的任務(wù)),需要讓池的大小超過(guò)可用處理器的數(shù)目,因?yàn)椴⒉皇撬芯€程都一直在工作。通過(guò)使用概要分析,您可以估計(jì)某個(gè)典型請(qǐng)求的等待時(shí)間(WT)與服務(wù)時(shí)間(ST)之間的比例。如果我們將這一比例稱之為 WT/ST,那么對(duì)于一個(gè)具有 N 個(gè)處理器的系統(tǒng),需要設(shè)置大約 N*(1+WT/ST) 個(gè)線程來(lái)保持處理器得到充分利用。 處理器利用率不是調(diào)整線程池大小過(guò)程中的唯一考慮事項(xiàng)。隨著線程池的增長(zhǎng),您可能會(huì)碰到調(diào)度程序、可用內(nèi)存方面的限制,或者其它系統(tǒng)資源方面的限制, 該文章里有個(gè)例子,簡(jiǎn)單的描述了線程池的內(nèi)部實(shí)現(xiàn),建議根據(jù)里面的例子來(lái)了解JAVA 線程池的原理
16、。同時(shí),里面還詳細(xì)描述了使用線程池存在的優(yōu)點(diǎn)和弊端,大家可以研究下,我覺(jué)得是篇非常好的文章。 JDK自帶線程池總類介紹介紹: 1、newFixedThreadPool創(chuàng)建一個(gè)指定工作線程數(shù)量的線程池。每當(dāng)提交一個(gè)任務(wù)就創(chuàng)建一個(gè)工作線程,如果工作線程數(shù)量達(dá)到線程池初始 的最大數(shù),則將提交的任務(wù)存入到池隊(duì)列中。 2、newCachedThreadPool創(chuàng)建一個(gè)可緩存的線程池。這種類型的線程池特點(diǎn)是: 1).工作線程的創(chuàng)建數(shù)量幾乎沒(méi)有限制(其實(shí)也有限制的,數(shù)目為Interger. MAX_VALUE), 這樣可靈活的往線程池中添加線程。 2).如果長(zhǎng)時(shí)間沒(méi)有往線程池中提交任務(wù),即如果工作線程空閑了
17、指定的時(shí)間(默認(rèn)為1分鐘),則該工作線程將自動(dòng)終止。終止后,如果你又提交了新的任務(wù),則線程池重新創(chuàng)建一個(gè)工作線程。 3、newSingleThreadExecutor創(chuàng)建一個(gè)單線程化的Executor,即只創(chuàng)建唯一的工線程來(lái)執(zhí)行任務(wù),如果這個(gè)線程異常結(jié)束,會(huì)有另一個(gè)取代它,保證順序執(zhí)行(我覺(jué)得這點(diǎn)是它的特色)。單工作線程最大的特點(diǎn)是可保證順序地執(zhí)行各個(gè)任務(wù),并且在任意給定的時(shí)間不會(huì)有多個(gè)線程是活動(dòng)的。 4、newScheduleThreadPool創(chuàng)建一個(gè)定長(zhǎng)的線程池,而且支持定時(shí)的以及周期性的任務(wù)執(zhí)行,類似于Timer。(這種線程池原理暫還沒(méi)完全了解透徹) 總結(jié):一.FixedThreadPool是一個(gè)典型且優(yōu)秀的線程池,它具有線程池提高程序效率和節(jié)省創(chuàng)建線程時(shí)所耗的開(kāi)銷的優(yōu)點(diǎn)。但是,在線程池 空閑時(shí),即線程池中沒(méi)
溫馨提示
- 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 電子會(huì)議參與情況統(tǒng)計(jì)表
- 四川省達(dá)州市渠縣中學(xué)2025屆高三下學(xué)期二??荚嚨乩碓囶}(含答案)
- 汽車維修技術(shù)發(fā)動(dòng)機(jī)原理與故障診斷試題
- 在公司年會(huì)上的致辭報(bào)告
- 《光的三原色原理及其應(yīng)用:初中物理教學(xué)教案》
- 物流行業(yè)貨物運(yùn)輸延誤免責(zé)協(xié)議書(shū)
- 運(yùn)營(yíng)商相關(guān)知識(shí)培訓(xùn)課件
- 心理學(xué)基礎(chǔ)與應(yīng)用測(cè)試卷
- 大數(shù)據(jù)在零售業(yè)的應(yīng)用案例分析
- 精煤產(chǎn)品購(gòu)銷合同
- 戶外廣告制作安裝合同模板
- 廠房改公寓出租合同范例
- 污水處理廠SBR工藝的設(shè)計(jì)說(shuō)明
- 城市軌道交通行車組織 課件 項(xiàng)目二任務(wù)六 車站行車組織作業(yè)
- 2025年北方聯(lián)合電力有限責(zé)任公司招聘筆試參考題庫(kù)含答案解析
- 2025年八省聯(lián)考數(shù)學(xué)試題(原卷版)
- 高教社馬工程倫理學(xué)(第二版)教學(xué)課件02
- 《榜樣9》觀后感心得體會(huì)二
- 2024年滁州職業(yè)技術(shù)學(xué)院?jiǎn)握新殬I(yè)適應(yīng)性測(cè)試題庫(kù)帶答案
- 小學(xué)生播音主持課課件
- 二年級(jí)下冊(cè)道法大單元全冊(cè)教案
評(píng)論
0/150
提交評(píng)論