在什麼情況下使用線程池?
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 中的實現使用的是 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 的慢操作,但允許繼續進行處理,並且可以利用多處理器。在運行於具有 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 ,而不用從頭開始編寫。如果您要自己創建線程來處理生存期很短的任務,那麼您絕對應該考慮使用線程池來替代。 |
該文章裏有個例子,簡單的描述了線程池的內部實現,建議根據裏面的例子來了解JAVA 線程池的原理。同時,裏面還詳細描述了使用線程池存在的優點和弊端,大家可以研究下,我覺得是篇非常好的文章。
JDK自帶線程池總類介紹介紹:
Java裏面線程池的頂級接口是Executor,但是嚴格意義上講Executor並不是一個線程池,而只是一個執行線程的工具。真正的線程池接口是ExecutorService。下面這張圖完整描述了線程池的類體系結構。
標記一下比較重要的類:
ExecutorService: | 真正的線程池接口。 |
ScheduledExecutorService | 能和Timer/TimerTask類似,解決那些需要任務重複執行的問題。 |
ThreadPoolExecutor | ExecutorService的默認實現。 |
ScheduledThreadPoolExecutor | 繼承ThreadPoolExecutor的ScheduledExecutorService接口實現,週期性任務調度的類實現。 |
1、newFixedThreadPool創建一個指定工作線程數量的線程池。每當提交一個任務就創建一個工作線程,如果工作線程數量達到線程池初始的最大數,則將提交的任務存入到池隊列中。
2、newCachedThreadPool創建一個可緩存的線程池。這種類型的線程池特點是:
1).工作線程的創建數量幾乎沒有限制(其實也有限制的,數目爲Interger. MAX_VALUE), 這樣可靈活的往線程池中添加線程。
2).如果長時間沒有往線程池中提交任務,即如果工作線程空閒了指定的時間(默認爲1分鐘),則該工作線程將自動終止。終止後,如果你又提交了新的任務,則線程池重新創建一個工作線程。
3、newSingleThreadExecutor創建一個單線程化的Executor,即只創建唯一的工作者線程來執行任務,如果這個線程異常結束,會有另一個取代它,保證順序執行(我覺得這點是它的特色)。單工作線程最大的特點是可保證順序地執行各個任務,並且在任意給定的時間不會有多個線程是活動的 。
4、newScheduleThreadPool創建一個定長的線程池,而且支持定時的以及週期性的任務執行,類似於Timer。(這種線程池原理暫還沒完全瞭解透徹)
總結: 一.FixedThreadPool是一個典型且優秀的線程池,它具有線程池提高程序效率和節省創建線程時所耗的開銷的優點。但是,在線程池空閒時,即線程池中沒有可運行任務時,它不會釋放工作線程,還會佔用一定的系統資源。
二.CachedThreadPool的特點就是在線程池空閒時,即線程池中沒有可運行任務時,它會釋放工作線程,從而釋放工作線程所佔用的資源。但是,但當出現新任務時,又要創建一新的工作線程,又要一定的系統開銷。並且,在使用CachedThreadPool時,一定要注意控制任務的數量,否則,由於大量線程同時運行,很有會造成系統癱瘓。
三.就是向各位請教一下,請問各位使用過SingleThreadExecutor嗎?它一般使用在哪些地方?
剛研究了一下線程池,以上爲個人學習過程以及觀點