ThreadPoolExecutor機制詳解

在什麼情況下使用線程池？

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() 來通知等待線程新的工作已經到達了。該工作隊列通常被實現成具有相關監視器對象的某種鏈表。

調整池的大小

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

請回憶：在應用程序中使用線程有兩個主要優點，儘管在等待諸如 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 中的一些實用程序。

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

java.util.concurrent 
類 ThreadPoolExecutor

java.lang.Object
  java.util.concurrent.AbstractExecutorService
      java.util.concurrent.ThreadPoolExecutor

所有已實現的接口：

Executor, ExecutorService

一個 ExecutorService，它使用可能的幾個池線程之一執行每個提交的任務

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler)

一個任務通過 execute(Runnable)方法被添加到線程池，任務就是一個 Runnable類型的對象，任務的執行方法就是Runnable類型對象的run()方法。 

BlockingQueue 用於傳輸和保持提交的任務。可以使用此隊列與池大小進行交互：

• 如果運行的線程少於 corePoolSize，即使線程池中有空閒的線程， Executor 也始終首選添加新的線程，而不進行排隊。
• 如果運行的線程等於或多於 corePoolSize而小於 maximumPoolSize，則 Executor 始終首選將請求加入隊列，而不添加新的線程。
• 如果無法將請求加入隊列，則創建新的線程，除非創建此線程超出 maximumPoolSize，在這種情況下，任務將被RejectedExecutionHandler拒絕。
• 另外，當池子的線程數大於corePoolSize的時候，多餘的線程會等待keepAliveTime長的時間，如果無請求可處理就自行銷燬
  

當 Executor 已經關閉，並且 Executor 將有限邊界用於最大線程和工作隊列容量，且已經飽和時，在方法 execute(java.lang.Runnable) 中提交的新任務將被拒絕。在以上兩種情況下，execute 方法都將調用其RejectedExecutionHandler 的RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) 方法。

構造方法摘要

ThreadPoolExecutor.AbortPolicy() 
          創建一個 AbortPolicy。

 

方法摘要
void	rejectedExecution(Runnable r, ThreadPoolExecutor e)            總是拋出 RejectedExecutionException。