諸如 Web 伺服器、資料庫伺服器、檔案伺服器或郵件伺服器之類的許多伺服器應用程式都面向處理來自某些遠端來源的大量短小的任務。請求以某種方式到達伺服器，這種方式可能是通過網路協議（例如 HTTP、FTP 或 POP）、通過 JMS 佇列或者可能通過輪詢資料庫。不管請求如何到達，伺服器應用程式中經常出現的情況是：單個任務處理的時間很短而請求的數目卻是巨大的。

構建伺服器應用程式的一個過於簡單的模型應該是：每當一個請求到達就建立一個新執行緒，然後在新執行緒中為請求服務。實際上，對於原型開發這種方法工作得很好，但如果試圖部署以這種方式執行的伺服器應用程式，那麼這種方法的嚴重不足就很明顯。每個請求對應一個執行緒（thread-per-request）方法的不足之一是：為每個請求建立一個新執行緒的開銷很大；為每個請求建立新執行緒的伺服器在建立和銷燬執行緒上花費的時間和消耗的系統資源要比花在處理實際的使用者請求的時間和資源更多。

除了建立和銷燬執行緒的開銷之外，活動的執行緒也消耗系統資源。在一個 JVM 裡建立太多的執行緒可能會導致系統由於過度消耗記憶體而用完記憶體或“切換過度”。為了防止資源不足，伺服器應用程式需要一些辦法來限制任何給定時刻處理的請求數目。

執行緒池為執行緒生命週期開銷問題和資源不足問題提供瞭解決方案。通過對多個任務重用執行緒，執行緒建立的開銷被分攤到了多個任務上。其好處是，因為在請求到達時執行緒已經存在，所以無意中也消除了執行緒建立所帶來的延遲。這樣，就可以立即為請求服務，使應用程式響應更快。而且，通過適當地調整執行緒池中的執行緒數目，也就是當請求的數目超過某個閾值時，就強制其它任何新到的請求一直等待，直到獲得一個執行緒來處理為止，從而可以防止資源不足。

回頁首

執行緒池遠不是伺服器應用程式內使用多執行緒的唯一方法。如同上面所提到的，有時，為每個新任務生成一個新執行緒是十分明智的。然而，如果任務建立過於頻繁而任務的平均處理時間過短，那麼為每個任務生成一個新執行緒將會導致效能問題。

另一個常見的執行緒模型是為某一型別的任務分配一個後臺執行緒與任務佇列。AWT 和 Swing 就使用這個模型，在這個模型中有一個 GUI 事件執行緒，導致使用者介面發生變化的所有工作都必須在該執行緒中執行。然而，由於只有一個 AWT 執行緒，因此要在 AWT 執行緒中執行任務可能要花費相當長時間才能完成，這是不可取的。因此，Swing 應用程式經常需要額外的工作執行緒，用於執行時間很長的、同 UI 有關的任務。

每個任務對應一個執行緒方法和單個後臺執行緒（single-background-thread）方法在某些情形下都工作得非常理想。每個任務一個執行緒方法在只有少量執行時間很長的任務時工作得十分好。而只要排程可預見性不是很重要，則單個後臺執行緒方法就工作得十分好，如低優先順序後臺任務就是這種情況。然而，大多數伺服器應用程式都是面向處理大量的短期任務或子任務，因此往往希望具有一種能夠以低開銷有效地處理這些任務的機制以及一些資源管理和定時可預見性的措施。執行緒池提供了這些優點。

回頁首

工作佇列

就執行緒池的實際實現方式而言，術語“執行緒池”有些使人誤解，因為執行緒池“明顯的”實現在大多數情形下並不一定產生我們希望的結果。術語“執行緒池”先於 Java 平臺出現，因此它可能是較少面向物件方法的產物。然而，該術語仍繼續廣泛應用著。

雖然我們可以輕易地實現一個執行緒池類，其中客戶機類等待一個可用執行緒、將任務傳遞給該執行緒以便執行、然後在任務完成時將執行緒歸還給池，但這種方法卻存在幾個潛在的負面影響。例如在池為空時，會發生什麼呢？試圖向池執行緒傳遞任務的呼叫者都會發現池為空，在呼叫者等待一個可用的池執行緒時，它的執行緒將阻塞。我們之所以要使用後臺執行緒的原因之一常常是為了防止正在提交的執行緒被阻塞。完全堵住呼叫者，如線上程池的“明顯的”實現的情況，可以杜絕我們試圖解決的問題的發生。

我們通常想要的是同一組固定的工作執行緒相結合的工作佇列，它使用 wait() 和 notify() 來通知等待執行緒新的工作已經到達了。該工作佇列通常被實現成具有相關監視器物件的某種連結串列。清單 1 顯示了簡單的合用工作佇列的示例。儘管 Thread API 沒有對使用 Runnable 介面強加特殊要求，但使用 Runnable 物件佇列的這種模式是排程程式和工作佇列的公共約定。

您可能已經注意到了清單 1 中的實現使用的是 notify() 而不是 notifyAll() 。大多數專家建議使用 notifyAll() 而不是 notify() ，而且理由很充分：使用 notify() 具有難以捉摸的風險，只有在某些特定條件下使用該方法才是合適的。另一方面，如果使用得當， notify() 具有比 notifyAll() 更可取的效能特徵；特別是， notify() 引起的環境切換要少得多，這一點在伺服器應用程式中是很重要的。

清單 1 中的示例工作佇列滿足了安全使用 notify() 的需求。因此，請繼續，在您的程式中使用它，但在其它情形下使用 notify() 時請格外小心。

回頁首

雖然執行緒池是構建多執行緒應用程式的強大機制，但使用它並不是沒有風險的。用執行緒池構建的應用程式容易遭受任何其它多執行緒應用程式容易遭受的所有併發風險，諸如同步錯誤和死鎖，它還容易遭受特定於執行緒池的少數其它風險，諸如與池有關的死鎖、資源不足和執行緒洩漏。

死鎖

任何多執行緒應用程式都有死鎖風險。當一組程序或執行緒中的每一個都在等待一個只有該組中另一個程序才能引起的事件時，我們就說這組程序或執行緒 死鎖了。死鎖的最簡單情形是：執行緒 A 持有物件 X 的獨佔鎖，並且在等待物件 Y 的鎖，而執行緒 B 持有物件 Y 的獨佔鎖，卻在等待物件 X 的鎖。除非有某種方法來打破對鎖的等待（Java 鎖定不支援這種方法），否則死鎖的執行緒將永遠等下去。

雖然任何多執行緒程式中都有死鎖的風險，但執行緒池卻引入了另一種死鎖可能，在那種情況下，所有池執行緒都在執行已阻塞的等待佇列中另一任務的執行結果的任務，但這一任務卻因為沒有未被佔用的執行緒而不能執行。當執行緒池被用來實現涉及許多互動物件的模擬，被模擬的物件可以相互發送查詢，這些查詢接下來作為排隊的任務執行，查詢物件又同步等待著響應時，會發生這種情況。

資源不足

執行緒池的一個優點在於：相對於其它替代排程機制（有些我們已經討論過）而言，它們通常執行得很好。但只有恰當地調整了執行緒池大小時才是這樣的。執行緒消耗包括記憶體和其它系統資源在內的大量資源。除了 Thread 物件所需的記憶體之外，每個執行緒都需要兩個可能很大的執行呼叫堆疊。除此以外，JVM 可能會為每個 Java 執行緒建立一個本機執行緒，這些本機執行緒將消耗額外的系統資源。最後，雖然執行緒之間切換的排程開銷很小，但如果有很多執行緒，環境切換也可能嚴重地影響程式的效能。

如果執行緒池太大，那麼被那些執行緒消耗的資源可能嚴重地影響系統性能。線上程之間進行切換將會浪費時間，而且使用超出比您實際需要的執行緒可能會引起資源匱乏問題，因為池執行緒正在消耗一些資源，而這些資源可能會被其它任務更有效地利用。除了執行緒自身所使用的資源以外，服務請求時所做的工作可能需要其它資源，例如 JDBC 連線、套接字或檔案。這些也都是有限資源，有太多的併發請求也可能引起失效，例如不能分配 JDBC 連線。

併發錯誤

執行緒池和其它排隊機制依靠使用 wait() 和 notify() 方法，這兩個方法都難於使用。如果編碼不正確，那麼可能丟失通知，導致執行緒保持空閒狀態，儘管佇列中有工作要處理。使用這些方法時，必須格外小心；即便是專家也可能在它們上面出錯。而最好使用現有的、已經知道能工作的實現，例如在下面的 無須編寫您自己的池中討論的 util.concurrent 包。

執行緒洩漏

各種型別的執行緒池中一個嚴重的風險是執行緒洩漏，當從池中除去一個執行緒以執行一項任務，而在任務完成後該執行緒卻沒有返回池時，會發生這種情況。發生執行緒洩漏的一種情形出現在任務丟擲一個 RuntimeException 或一個 Error 時。如果池類沒有捕捉到它們，那麼執行緒只會退出而執行緒池的大小將會永久減少一個。當這種情況發生的次數足夠多時，執行緒池最終就為空，而且系統將停止，因為沒有可用的執行緒來處理任務。

有些任務可能會永遠等待某些資源或來自使用者的輸入，而這些資源又不能保證變得可用，使用者可能也已經回家了，諸如此類的任務會永久停止，而這些停止的任務也會引起和執行緒洩漏同樣的問題。如果某個執行緒被這樣一個任務永久地消耗著，那麼它實際上就被從池除去了。對於這樣的任務，應該要麼只給予它們自己的執行緒，要麼只讓它們等待有限的時間。

請求過載

僅僅是請求就壓垮了伺服器，這種情況是可能的。在這種情形下，我們可能不想將每個到來的請求都排隊到我們的工作佇列，因為排在佇列中等待執行的任務可能會消耗太多的系統資源並引起資源缺乏。在這種情形下決定如何做取決於您自己；在某些情況下，您可以簡單地拋棄請求，依靠更高級別的協議稍後重試請求，您也可以用一個指出伺服器暫時很忙的響應來拒絕請求。

回頁首

只要您遵循幾條簡單的準則，執行緒池可以成為構建伺服器應用程式的極其有效的方法：

• 不要對那些同步等待其它任務結果的任務排隊。這可能會導致上面所描述的那種形式的死鎖，在那種死鎖中，所有執行緒都被一些任務所佔用，這些任務依次等待排隊任務的結果，而這些任務又無法執行，因為所有的執行緒都很忙。
• 在為時間可能很長的操作使用合用的執行緒時要小心。如果程式必須等待諸如 I/O 完成這樣的某個資源，那麼請指定最長的等待時間，以及隨後是失效還是將任務重新排隊以便稍後執行。這樣做保證了：通過將某個執行緒釋放給某個可能成功完成的任務，從而將最終取得 某些進展。
  
• 理解任務。要有效地調整執行緒池大小，您需要理解正在排隊的任務以及它們正在做什麼。它們是 CPU 限制的（CPU-bound）嗎？它們是 I/O 限制的（I/O-bound）嗎？您的答案將影響您如何調整應用程式。如果您有不同的任務類，這些類有著截然不同的特徵，那麼為不同任務類設定多個工作佇列可能會有意義，這樣可以相應地調整每個池。

回頁首

調整執行緒池的大小基本上就是避免兩類錯誤：執行緒太少或執行緒太多。幸運的是，對於大多數應用程式來說，太多和太少之間的餘地相當寬。

請回憶：在應用程式中使用執行緒有兩個主要優點，儘管在等待諸如 I/O 的慢操作，但允許繼續進行處理，並且可以利用多處理器。在運行於具有 N 個處理器機器上的計算限制的應用程式中，線上程數目接近 N 時新增額外的執行緒可能會改善總處理能力，而線上程數目超過 N 時新增額外的執行緒將不起作用。事實上，太多的執行緒甚至會降低效能，因為它會導致額外的環境切換開銷。

執行緒池的最佳大小取決於可用處理器的數目以及工作佇列中的任務的性質。若在一個具有 N 個處理器的系統上只有一個工作佇列，其中全部是計算性質的任務，線上程池具有 N 或 N+1 個執行緒時一般會獲得最大的 CPU 利用率。

對於那些可能需要等待 I/O 完成的任務（例如，從套接字讀取 HTTP 請求的任務），需要讓池的大小超過可用處理器的數目，因為並不是所有執行緒都一直在工作。通過使用概要分析，您可以估計某個典型請求的等待時間（WT）與服務時間（ST）之間的比例。如果我們將這一比例稱之為 WT/ST，那麼對於一個具有 N 個處理器的系統，需要設定大約 N*(1+WT/ST) 個執行緒來保持處理器得到充分利用。

處理器利用率不是調整執行緒池大小過程中的唯一考慮事項。隨著執行緒池的增長，您可能會碰到排程程式、可用記憶體方面的限制，或者其它系統資源方面的限制，例如套接字、開啟的檔案控制代碼或資料庫連線等的數目。

回頁首

Doug Lea 編寫了一個優秀的併發實用程式開放原始碼庫 util.concurrent ，它包括互斥、訊號量、諸如在併發訪問下執行得很好的佇列和散列表之類集合類以及幾個工作佇列實現。該包中的 PooledExecutor 類是一種有效的、廣泛使用的以工作佇列為基礎的執行緒池的正確實現。您無須嘗試編寫您自己的執行緒池，這樣做容易出錯，相反您可以考慮使用 util.concurrent 中的一些實用程式。參閱 參考資料以獲取連結和更多資訊。

util.concurrent 庫也激發了 JSR 166，JSR 166 是一個 Java 社群過程（Java Community Process (JCP)）工作組，他們正在打算開發一組包含在 java.util.concurrent 包下的 Java 類庫中的併發實用程式，這個包應該用於 Java 開發工具箱 1.5 發行版。

回頁首

結束語

執行緒池是組織伺服器應用程式的有用工具。它在概念上十分簡單，但在實現和使用一個池時，卻需要注意幾個問題，例如死鎖、資源不足和 wait() 及 notify() 的複雜性。如果您發現您的應用程式需要執行緒池，那麼請考慮使用 util.concurrent 中的某個 Executor 類，例如 PooledExecutor ，而不用從頭開始編寫。如果您要自己建立執行緒來處理生存期很短的任務，那麼您絕對應該考慮使用執行緒池來替代。