線程池是一個重要的概念。不過我發現，關于這個話題的讨論似乎還缺少了點什麼。作為資料的補充，以及今後文章所需要的引用，我在這裡再完整而又簡單地談一下有關線程池，還有.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記憶體，假設線程池目前為空，且有着足夠的容量，此外線程建立速度也足夠快，那麼在限制及不限制線程建立速度的情況下，完成這些任務需要多少時間和記憶體空間？
轉載：http://www.cnblogs.com/JeffreyZhao/archive/2009/07/22/thread-pool-1-the-goal-and-the-clr-thread-pool.html