程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> 關於C# >> 淺談線程池:線程池的作用及CLR線程池

淺談線程池:線程池的作用及CLR線程池

編輯:關於C#
 

線程池是一個重要的概念。不過我發現,關於這個話題的討論似乎還缺少了點什麼。作為資料的補充,以及今後文章所需要的引用,我在這裡再完整而又簡單地談一下有關線程池,還有.NET中各種線程池的基礎。更詳細的內容就不多作展開了,有機會我們再詳細討論這方面的細節。這次,還是一個“概述”性質的,希望可以說明白這方面問題的一些概念。

線程池的作用

  其實“線程池”就是用來存放“線程”的對象池。

  在程序中,如果某個創建某種對象所需要的代價太高,同時這個對象又可以反復使用,那麼我們往往就會准備一個容器,用來保存一批這樣的對象。於是乎,我們想要用這種對象時,就不需要每次去創建一個,而直接從容器中取出一個現成的對象就可以了。由於節省了創建對象的開銷,程序性能自然就上升了。這個容器就是“池”。很容易理解的是,因為有了對象池,因此在用完對象之後必須有一個“歸還”的動作,這樣便可以把對象放回池中,下次需要的時候就可以再次拿出來使用了。

  例如,我們在使用ADO.NET連接SQL Server時,.NET框架就會自動幫我們維護一個連接池,這就是因為重新創建一個連接的代價相對比較高昂,“復用”就顯得比較劃算了。不過有些朋友可能會說,我們明明是每次都創建一個SqlConnection對象,哪裡有“復用”啊?這是因為.NET框架中把“連接池”做透明了,對於程序員完全隱藏了這個概念。每次我們雖然創建的是新的SqlConnection對象,但是這個對象內部占用的“數據庫連接”還是會復用的。為什麼總是強調用完SqlConnection對象後要及時“關閉”(Dispose或Close)呢?其實這裡並沒有斷開數據庫連接,只是把這個連接放回了連接池。等到下次創建新的SqlConnection對象時,這個連接又可以拿出來用了。

  既然我們每次都是從池中獲取對象,那麼這些對象是由誰來創建,又是什麼時候創建的呢?這個就要根據不同情況由各對象池來自行實現了。例如,可以在創建對象池的時候指定池內對象數量,並且一下子全部創建好,當然您也可以在得到請求時,如果發現池中已經沒有剩余對象時創建。您也可以“事前”先准備一部分,“事中”根據需要再繼續補充。還可以做得“智能”一些,例如,根據實際情況添加或刪除一些對象,甚至對需求“走勢”進行“預測”,在空閒時便創建更多的對象以備“不時之需”。各中變化難以言盡。

  當然,它們的原理和目的是類似的。相信上面這段文字也已經講清了“線程池”的作用:因為創建一個線程的代價較高,因此我們使用線程池設法復用線程。就是這麼簡單。

CLR線程池

  在.NET中,CLR線程和操作系統線程對應,您可以簡單地認為.NET中的Thread對象便封裝了一個操作系統線程,並附帶一些托管環境下所需要的數據(如GC Handle)1。而CLR線程池便是存放這些CLR線程的對象池。

  我們在編寫程序的時候,可以使用ThreadPool類的兩個靜態方法:QueueUserWorkItem和UnsafeUserQueueWorkItem向CLR線程池中添加任務(一個WorkCallback委托對象),這兩個方法的區別,在於前者會收集調用方的ExecutionContext,也就是保留了的當前線程的執行信息(如認證或語言文化等),使任務最終會在“創建”時刻的環境中執行2——後者就不會。因此,如果比較兩個方法的絕對性能,Unsafe方法會略勝一籌。但是平時還是建議使用QueueUserWorkItem方法,因為保留執行上下文會避免很多麻煩事情,且這點性能損耗其實算不上什麼。

  CLR線程池在.NET框架中的作用很大,除了讓程序員使用之外,其他一些功能也會依賴CLR線程池。如ThreadPool.RegisterWaitForSingleObject方法,或是System.Threading.Timer組件——還有更重要可能也是更隱藏的:ASP.NET在得到一個請求後,也會將這個請求處理的任務交由CLR線程池去執行——請注意,它們最多只是添加任務而已,並不表示任務會立即執行。所有添加到CLR線程池的任務都會在合適的時候得以執行——可能馬上,也可能要稍等片刻,甚至更久。

  向CLR線程池添加任務時,任務會被臨時放到一個隊列中,並在合適的時候執行。那麼怎麼樣才算是“合適的時候”?簡單的概括說來,便是線程池內有空閒的線程,或線程池所管理的線程數量還沒有達到上限的時候。如果有空閒的線程,線程池就會立即讓它領取一個任務執行。如果是第二種情況,線程池便會創建新的Thread對象。由於讓操作系統管理太多線程反而會造成性能下降,因此CLR線程池會有一個上限。不同的托管環境會設置不同的上限。如在.NET 2.0 SP1之後,普通的Windows應用程序(如控制台或WinForm/WPF),會將其設置為“處理器數 * 250”。也就是說,如果您的機器為2個2核CPU,那麼CLR線程池的容量默認上限便是1000,也就是說,它最多可以管理1000個線程同時運行——很多情況下這已經是一個很可怕的數字了,如果您覺得這還不夠,那麼就應該考慮一下您的實現方式是否可以改進了。

  對於ASP.NET應用程序來說,CLR線程池容量代表了應用程序最多可以同時執行的請求數量。對於托管在IIS上的ASP.NET執行環境來說,這個值由全局配置決定。這個配置在machine.config文件中system.web/processModel節點中,為maxWorkerThreads屬性,它決定了為單個處理器分配的線程數。如果這個值為40,且機器上擁有4個處理器(2 * 2CPU),那麼這台機器目前的配置表示在同一時刻,ASP.NET可以同時處理160個請求。某些參考資料建議您將其修改為每處理器80-100個線程,這時您只要修改相應的屬性值就可以了。

  既然有最大值,也就相應有了最小值,它代表了CLR線程池“總是會保留”的最少線程數量。由於線程會占用資源,如在默認情況下,每個線程將獲得1MB大小的棧空間3。所以如果在系統中保留太多空閒線程對資源也是一種浪費。因此,CLR線程池在使用大量線程處理完大量任務之後,也會逐步地釋放線程,直至到達最小值。CLR線程池的最小線程數量確保了在任務數量較少的情況下,新來的任務可以立即執行,從而省去了創建新線程的時間。在普通應用程序中這個值為“處理器數 * 1”,而在ASP.NET應用程序中這個值配置在machine.config文件中system.web/processModel節點的minWorkerThreads屬性中4

  在某些時候可能會遇到這樣的情況:在一個瞬間忽然來大量任務,每個任務的執行時間說長不長說短不短,不過足以導致線程池快速分配數百個線程。如果這個峰值之後就一片平靜,那麼勢必造成大量空閒的線程,這種開銷對性能的損耗也非常明顯。因此,CLR線程池限制了線程的創建速度不超過每秒2個。這樣,即使在某個瞬時獲得了大量的任務,CLR線程池也可以使用相對較少的線程來完成所有工作5

  但是,還有一種情況也值得考慮。例如,對於一個比較繁忙的Web應用程序來說,一打開便會湧入大量的連接。由於線程的創建速度有限,因此可以執行的請求數量也只能慢慢增加。對於這種您預料到會產生大量線程,而且忙碌狀況會持續一段時間的情況,限制線程的創建速度反而會帶來損傷效率。這時,您就可以手動設置CLR線程池的最小線程數量。如果此時CLR線程池中擁有的線程數量較少,那麼系統就會立即創建一定數量的線程來達到這個最小值。設置和獲取CLR線程池最小線程數量的接口為:

public static class ThreadPool
{
    public static void GetMinThreads(out int workerThreads, out int completionPortThreads);
    public static bool SetMinThreads(int workerThreads, int completionPortThreads);
}

  這兩個接口的作用和使用方式應該足夠明顯了(不理解的話可以查閱MSDN),其中workerThreads參數便是CLR線程池的最小線程數,而completionPortThreads涉及到我們下次要討論IO線程池,在此就不多作展開了。除了設置和讀取CLR最小線程數的方法之外,ThreadPool還包含這些接口:

public static class ThreadPool
{
    public static void GetMaxThreads(out int workerThreads, out int completionPortThreads);
    public static bool SetMaxThreads(int workerThreads, int completionPortThreads);
    public static void GetAvailableThreads(out int workerThreads, out int completionPortThreads);
}

  值得注意的是,無論是設置還是獲取到的這些數值,都與處理器數量沒有任何關系了。也就是說,在一台2 * 2CPU的機器上運行一個普通的.NET應用程序時:

  • 調用GetMaxThreads方法將獲得1000,表示CLR線程池最大容量為1000(250 * 4),而不是250。
  • 調用SetMinThreads並傳入100,表示CLR線程池所擁有的最小線程數量為100,而不是400(100 * 4)。

  對於CLR線程池的簡單描述就暫時先到這裡了。如果您還有什麼疑問請提出,我會加以補充。

 

注1:嚴格說來,Thread對象和系統線程對應關系還有些細節上的考慮。例如,Thread對象只有當真正Start了之後,CLR才會創建一個操作系統線程與它綁定。

注2:ExecutionContext是個很重要且很有用的對象,例如,WinForms或WPF的異步任務中操作界面元素拋出異常該怎麼辦呢?

注3:使用Windows API或Thread類創建線程時可以指定它的棧空間大小,但是CLR線程池中的線程只能使用默認值——不過這個默認值也和托管環境有關,如普通應用程序默認為1MB,而ASP.NET為250KB,這意味著ASP.NET應用程序相對更容易產生Stack Overflow異常。

注4:可惜的是,對於processModel節點的數據,ASP.NET只會讀取machine.config中的全局配置信息,這意味著我們不能使用web.config為不同應用程序配置不同的參數。如果我們要實現應用程序級別的配置,那麼必須使用ThreadPool類中提供的API進行設置,這點稍後便會提到。

注5:對於這點,您不妨來做一個算術題:線程池內一下子湧入了500個任務,每個任務阻塞或暫停5秒,每個線程占用1MB內存,假設線程池目前為空,且有著足夠的容量,此外線程創建速度也足夠快,那麼在限制及不限制線程創建速度的情況下,完成這些任務需要多少時間和內存空間?

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved