CLR線程池的作用是什么

本篇文章為大家展示了CLR線程池的作用是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

線程池的作用

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

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

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

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

當然，它們的原理和目的是類似的。相信上面這段文字也已經(jīng)講清了“線程池”的作用：因為創(chuàng)建一個線程的代價較高，因此我們使用線程池設(shè)法復用線程。就是這么簡單。

CLR線程池的作用

在.NET中，CLR線程和操作系統(tǒng)線程對應(yīng)，您可以簡單地認為.NET中的Thread對象便封裝了一個操作系統(tǒng)線程，并附帶一些托管環(huán)境下所需要的數(shù)據(jù)（如GC Handle）1。而CLR線程池便是存放這些CLR線程的對象池。

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

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

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

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

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

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

但是，還有一種情況也值得考慮。例如，對于一個比較繁忙的Web應(yīng)用程序來說，一打開便會涌入大量的連接。由于線程的創(chuàng)建速度有限，因此可以執(zhí)行的請求數(shù)量也只能慢慢增加。對于這種您預(yù)料到會產(chǎn)生大量線程，而且忙碌狀況會持續(xù)一段時間的情況，限制線程的創(chuàng)建速度反而會帶來損傷效率。這時，您就可以手動設(shè)置CLR線程池的最小線程數(shù)量。如果此時CLR線程池中擁有的線程數(shù)量較少，那么系統(tǒng)就會立即創(chuàng)建一定數(shù)量的線程來達到這個最小值。設(shè)置和獲取CLR線程池最小線程數(shù)量的接口為：

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

這兩個接口的作用和使用方式應(yīng)該足夠明顯了（不理解的話可以查閱MSDN），其中workerThreads參數(shù)便是CLR線程池的最小線程數(shù)，而completionPortThreads涉及到我們下次要討論IO線程池，在此就不多作展開了。除了設(shè)置和讀取CLR最小線程數(shù)的方法之外，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);  }

值得注意的是，無論是設(shè)置還是獲取到的這些數(shù)值，都與處理器數(shù)量沒有任何關(guān)系了。也就是說，在一臺2 * 2CPU的機器上運行一個普通的.NET應(yīng)用程序時：

調(diào)用GetMaxThreads方法將獲得1000，表示CLR線程池***容量為1000（250 * 4），而不是250。

調(diào)用SetMinThreads并傳入100，表示CLR線程池所擁有的最小線程數(shù)量為100，而不是400（100 * 4）。

對于CLR線程池的作用的簡單描述就暫時先到這里了。如果您還有什么疑問請?zhí)岢觯視右匝a充。

注1：嚴格說來，Thread對象和系統(tǒng)線程對應(yīng)關(guān)系還有些細節(jié)上的考慮。例如，Thread對象只有當真正Start了之后，CLR才會創(chuàng)建一個操作系統(tǒng)線程與它綁定。

注2：ExecutionContext是個很重要且很有用的對象，例如，WinForms或WPF的異步任務(wù)中操作界面元素拋出異常該怎么辦呢？

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

注4：可惜的是，對于processModel節(jié)點的數(shù)據(jù)，ASP.NET只會讀取machine.config中的全局配置信息，這意味著我們不能使用web.config為不同應(yīng)用程序配置不同的參數(shù)。如果我們要實現(xiàn)應(yīng)用程序級別的配置，那么必須使用ThreadPool類中提供的API進行設(shè)置，這點稍后便會提到。

注5：對于這點，您不妨來做一個算術(shù)題：線程池內(nèi)一下子涌入了500個任務(wù)，每個任務(wù)阻塞或暫停5秒，每個線程占用1MB內(nèi)存，假設(shè)線程池目前為空，且有著足夠的容量，此外線程創(chuàng)建速度也足夠快，那么在限制及不限制線程創(chuàng)建速度的情況下，完成這些任務(wù)需要多少時間和內(nèi)存空間？

上述內(nèi)容就是CLR線程池的作用是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。