剛剛研究了一下線程池，如果有不足之處，請大家不吝賜教，大家共同學習、共同交流。
在什麼情況下使用Java線程池？
1.單個任務處理的時間比較短
2.將需處理的任務的數量大
使用線程池的好處:
1.減少在創建和銷毀線程上所花的時間以及系統資源的開銷
2.如不使用線程池，有可能造成系統創建大量線程而導致消耗完系統內存以及”過度切換”。
線程池工作原理：
為什麼要用線程池？
諸如 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() 時請格外小心。