一個系統中的執行緒相對於其所要處理的任務而言，是一種非常有限的資源。執行緒不僅在執行任務時需要消耗CPU時間和記憶體等資源，執行緒物件（Thread例項）本身以及執行緒所需的呼叫棧（Call Stack）也佔用記憶體，並且Java中建立一個執行緒往往意味著JVM會建立相應的依賴於宿主機作業系統的本地執行緒（Native Thread）。因此，為每個任務建立一個執行緒，通常是一種奢侈而不現實的事情。常見的做法是複用一定數量的執行緒，執行不斷產生的任務。
Thread Pool模式的核心思想是使用佇列等待處理的任務進行快取，並複用一定數量的工作者執行緒去取佇列中的任務進行執行。

類圖

好處：

• 減少執行緒建立的開銷，提高響應性。//事先建立一部分執行緒。
• 封裝了工作者執行緒生命週期管理。
• 減少銷燬執行緒的開銷

ThreadPoolExecutor 工作佇列的選擇：

• 有界佇列：限定執行緒池中待執行任務的數量。需要限定執行緒池最大大小為一個合理有限值。有界工作佇列加上有限數量的工作者執行緒可能導致死鎖。有界佇列適合任務之間相互獨立的情況。
• 無界佇列：工作佇列本身不限制執行緒池中等待執行的任務的數量，任務數取決於任務本身對資源的使用情況。無界佇列可能導致系統的不穩定。
• 直接交接佇列（SynchronousQueue）：實際上不使用快取空間。需要限定執行緒池最大大小為一個合理有限值
  。

執行緒池大小調校：太大消耗資源，並增加上下文切換。太小無法充分利用CPU資源，吞吐率過低。合理的大小取決於任務的特性、系統資源狀況以及任務所使用的稀缺資源狀況等因素。
系統資源主要考慮CPU個數和JVM堆記憶體的大小。