什麼情況下會用到執行緒池呢？？？？？
1. 單個任務處理的時間比較短
2. 將需處理的任務的數量大
使用執行緒池的好處
1.減少在建立和銷燬執行緒上所花的時間以及系統資源的開銷
2.如不使用執行緒池，有可能造成系統建立大量執行緒而導致消耗完系統記憶體以及”過度切換”。
為什麼使用執行緒池
摘自 IBM Bluemix
諸如 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