為什麼要用線程池？
諸如 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. 具有線程池的工作隊列
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
}
}
}
}
}
您可能已經注意到了清單 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 ，而不用從頭 開始編寫。如果您要自己創建線程來處理生存期很短的任務，那麼您絕對應該考 慮使用線程池來替代。
