国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

級(jí)別: 初級(jí)

Brian Goetz, 首席顧問(wèn), Quiotix Corp

2002 年 10 月 12 日

貼在我們多線程 Java 編程論壇上最常見(jiàn)的問(wèn)題之一是“怎樣創(chuàng)建線程池？”。幾乎在每個(gè)服務(wù)器應(yīng)用程序中都會(huì)出現(xiàn)線程池和工作隊(duì)列問(wèn)題。本文中，Brian Goetz 探討了線程池的動(dòng)機(jī)、一些基本實(shí)現(xiàn)和調(diào)優(yōu)技術(shù)以及一些要避免的常見(jiàn)危險(xiǎn)。

為什么要用線程池？

諸如 Web 服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器、文件服務(wù)器或郵件服務(wù)器之類的許多服務(wù)器應(yīng)用程序都面向處理來(lái)自某些遠(yuǎn)程來(lái)源的大量短小的任務(wù)。請(qǐng)求以某種方式到達(dá)服務(wù)器，這種方式可能是通過(guò)網(wǎng)絡(luò)協(xié)議（例如 HTTP、FTP 或 POP）、通過(guò) JMS 隊(duì)列或者可能通過(guò)輪詢數(shù)據(jù)庫(kù)。不管請(qǐng)求如何到達(dá)，服務(wù)器應(yīng)用程序中經(jīng)常出現(xiàn)的情況是：?jiǎn)蝹€(gè)任務(wù)處理的時(shí)間很短而請(qǐng)求的數(shù)目卻是巨大的。

構(gòu)建服務(wù)器應(yīng)用程序的一個(gè)過(guò)于簡(jiǎn)單的模型應(yīng)該是：每當(dāng)一個(gè)請(qǐng)求到達(dá)就創(chuàng)建一個(gè)新線程，然后在新線程中為請(qǐng)求服務(wù)。實(shí)際上，對(duì)于原型開(kāi)發(fā)這種方法工作得很好，但如果試圖部署以這種方式運(yùn)行的服務(wù)器應(yīng)用程序，那么這種方法的嚴(yán)重不足就很明顯。每個(gè)請(qǐng)求對(duì)應(yīng)一個(gè)線程（thread-per-request）方法的不足之一是：為每個(gè)請(qǐng)求創(chuàng)建一個(gè)新線程的開(kāi)銷很大；為每個(gè)請(qǐng)求創(chuàng)建新線程的服務(wù)器在創(chuàng)建和銷毀線程上花費(fèi)的時(shí)間和消耗的系統(tǒng)資源要比花在處理實(shí)際的用戶請(qǐng)求的時(shí)間和資源更多。

除了創(chuàng)建和銷毀線程的開(kāi)銷之外，活動(dòng)的線程也消耗系統(tǒng)資源。在一個(gè) JVM 里創(chuàng)建太多的線程可能會(huì)導(dǎo)致系統(tǒng)由于過(guò)度消耗內(nèi)存而用完內(nèi)存或“切換過(guò)度”。為了防止資源不足，服務(wù)器應(yīng)用程序需要一些辦法來(lái)限制任何給定時(shí)刻處理的請(qǐng)求數(shù)目。

線程池為線程生命周期開(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ù)目，也就是當(dāng)請(qǐng)求的數(shù)目超過(guò)某個(gè)閾值時(shí)，就強(qiáng)制其它任何新到的請(qǐng)求一直等待，直到獲得一個(gè)線程來(lái)處理為止，從而可以防止資源不足。

回頁(yè)首

線程池的替代方案

線程池遠(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 線程中執(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)性的措施。線程池提供了這些優(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)線程的原因之一常常是為了防止正在提交的線程被阻塞。完全堵住調(diào)用者，如在線程池的“明顯的”實(shí)現(xiàn)的情況，可以杜絕我們?cè)噲D解決的問(wèn)題的發(fā)生。

我們通常想要的是同一組固定的工作線程相結(jié)合的工作隊(duì)列，它使用 wait() 和 notify() 來(lái)通知等待線程新的工作已經(jīng)到達(dá)了。該工作隊(duì)列通常被實(shí)現(xiàn)成具有相關(guān)監(jiān)視器對(duì)象的某種鏈表。清單 1 顯示了簡(jiǎn)單的合用工作隊(duì)列的示例。盡管 Thread API 沒(méi)有對(duì)使用 Runnable 接口強(qiáng)加特殊要求，但使用 Runnable 對(duì)象隊(duì)列的這種模式是調(diào)度程序和工作隊(duì)列的公共約定。

                    public class WorkQueue                    {                    private final int nThreads;                    private final PoolWorker[] threads;                    private final LinkedList queue;                    public WorkQueue(int nThreads)                    {                    this.nThreads = nThreads;                    queue = new LinkedList();                    threads = new PoolWorker[nThreads];                    for (int i=0; i<nThreads; i++) {                    threads[i] = new PoolWorker();                    threads[i].start();                    }                    }                    public void execute(Runnable r) {                    synchronized(queue) {                    queue.addLast(r);                    queue.notify();                    }                    }                    private class PoolWorker extends Thread {                    public void run() {                    Runnable r;                    while (true) {                    synchronized(queue) {                    while (queue.isEmpty()) {                    try                    {                    queue.wait();                    }                    catch (InterruptedException ignored)                    {                    }                    }                    r = (Runnable) queue.removeFirst();                    }                    // If we don‘t 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ù)專家建議使用 notifyAll() 而不是 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)用程序容易遭受任何其它多線程應(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)，但線程池卻引入了另一種死鎖可能，在那種情況下，所有池線程都在執(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ī)線程，這些本機(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() 方法，這兩個(gè)方法都難于使用。如果編碼不正確，那么可能丟失通知，導(dǎo)致線程保持空閑狀態(tài)，盡管隊(duì)列中有工作要處理。使用這些方法時(shí)，必須格外小心；即便是專家也可能在它們上面出錯(cuò)。而最好使用現(xiàn)有的、已經(jīng)知道能工作的實(shí)現(xiàn)，例如在下面的 無(wú)須編寫您自己的池中討論的 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ì)永久減少一個(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)資源并引起資源缺乏。在這種情形下決定如何做取決于您自己；在某些情況下，您可以簡(jiǎn)單地拋棄請(qǐng)求，依靠更高級(jí)別的協(xié)議稍后重試請(qǐng)求，您也可以用一個(gè)指出服務(wù)器暫時(shí)很忙的響應(yīng)來(lái)拒絕請(qǐng)求。

回頁(yè)首

有效使用線程池的準(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í)間，以及隨后是失效還是將任務(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)寬。

請(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/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)資源方面的限制，例如套接字、打開(kāi)的文件句柄或數(shù)據(jù)庫(kù)連接等的數(shù)目。

無(wú)須編寫您自己的池

Doug Lea 編寫了一個(gè)優(yōu)秀的并發(fā)實(shí)用程序開(kāi)放源碼庫(kù) util.concurrent ，它包括互斥、信號(hào)量、諸如在并發(fā)訪問(wèn)下執(zhí)行得很好的隊(duì)列和散列表之類集合類以及幾個(gè)工作隊(duì)列實(shí)現(xiàn)。該包中的 PooledExecutor 類是一種有效的、廣泛使用的以工作隊(duì)列為基礎(chǔ)的線程池的正確實(shí)現(xiàn)。您無(wú)須嘗試編寫您自己的線程池，這樣做容易出錯(cuò)，相反您可以考慮使用 util.concurrent 中的一些實(shí)用程序。參閱 參考資料以獲取鏈接和更多信息。

util.concurrent 庫(kù)也激發(fā)了 JSR 166，JSR 166 是一個(gè) Java 社區(qū)過(guò)程（Java Community Process (JCP)）工作組，他們正在打算開(kāi)發(fā)一組包含在 java.util.concurrent 包下的 Java 類庫(kù)中的并發(fā)實(shí)用程序，這個(gè)包應(yīng)該用于 Java 開(kāi)發(fā)工具箱 1.5 發(fā)行版。

結(jié)束語(yǔ)

線程池是組織服務(wù)器應(yīng)用程序的有用工具。它在概念上十分簡(jiǎn)單，但在實(shí)現(xiàn)和使用一個(gè)池時(shí)，卻需要注意幾個(gè)問(wèn)題，例如死鎖、資源不足和 wait() 及 notify() 的復(fù)雜性。如果您發(fā)現(xiàn)您的應(yīng)用程序需要線程池，那么請(qǐng)考慮使用 util.concurrent 中的某個(gè) Executor 類，例如 PooledExecutor ，而不用從頭開(kāi)始編寫。如果您要自己創(chuàng)建線程來(lái)處理生存期很短的任務(wù)，那么您絕對(duì)應(yīng)該考慮使用線程池來(lái)替代。