從此圖中我們會發現 .NET 與C# 的每個版本發布都是有一個“主題”。即：C#1.0托管代碼→C#2.0泛型→C#3.0LINQ→C#4.0動態語言→C#5.0異步編程。現在我為最新版本的“異步編程”主題寫系列分享，期待你的查看及點評。
開始《異步編程：使用線程池管理線程》
示例程序：異步編程：使用線程池管理線程.rar
如今的應用程序越來越復雜，我們常常需要使用《異步編程：線程概述及使用》中提到的多線程技術來提高應用程序的響應速度。這時我們頻繁的創建和銷毀線程來讓應用程序快速響應操作，這頻繁的創建和銷毀無疑會降低應用程序性能，我們可以引入緩存機制解決這個問題，此緩存機制需要解決如：緩存的大小問題、排隊執行任務、調度空閑線程、按需創建新線程及銷毀多余空閑線程……如今微軟已經為我們提供了現成的緩存機制：線程池
線程池原自於對象池，在詳細解說明線程池前讓我們先來了解下何為對象池。
對象池
在系統設計中，我們嘗嘗會使用到“池”的概念。Eg：數據庫連接池，socket連接池，線程池，組件隊列。“池”可以節省對象重復創建和初始化所耗費的時間。對那些被系統頻繁請求和使用的對象，使用此機制可以提高系統運行性能。
“池”是一種“以空間換時間”的做法，我們在內存中保存一系列整裝待命的對象，供人隨時差遣。與系統效率相比，這些對象所占用的內存空間太微不足道了。
流程圖：
對於對象池的清理通常設計兩種方式：
1) 手動清理，即主動調用清理的方法。
2) 自動清理，即通過System.Threading.Timer來實現定時清理。
關鍵實現代碼：
public sealed class ObjectPool<T> where T : ICacheObjectProxy<T>
{
// 最大容量
private Int32 m_maxPoolCount = 30;
// 最小容量
private Int32 m_minPoolCount = 5;
// 已存容量
private Int32 m_currentCount;
// 空閑+被用 對象列表
private Hashtable m_listObjects;
// 最大空閑時間
private int maxIdleTime = 120;
// 定時清理對象池對象
private Timer timer = null;
/// <summary>
/// 創建對象池
/// </summary>
/// <param name="maxPoolCount">最小容量</param>
/// <param name="minPoolCount">最大容量</param>
/// <param name="create_params">待創建的實際對象的參數</param>
public ObjectPool(Int32 maxPoolCount, Int32 minPoolCount, Object[] create_params){ }
/// <summary>
/// 獲取一個對象實例
/// </summary>
/// <returns>返回內部實際對象，若返回null則線程池已滿</returns>
public T GetOne(){ }
/// <summary>
/// 釋放該對象池
/// </summary>
public void Dispose(){ }
/// <summary>
/// 將對象池中指定的對象重置並設置為空閑狀態
/// </summary>
public void ReturnOne(T obj){ }
/// <summary>
/// 手動清理對象池
/// </summary>
public void ManualReleaseObject(){ }
/// <summary>
/// 自動清理對象池（對大於 最小容量 的空閑對象進行釋放）
/// </summary>
private void AutoReleaseObject(Object obj){ }
}
通過對“對象池”的一個大體認識能幫我們更快理解線程池。
線程池ThreadPool類詳解
ThreadPool靜態類，為應用程序提供一個由系統管理的輔助線程池，從而使您可以集中精力於應用程序任務而不是線程管理。每個進程都有一個線程池,一個Process中只能有一個實例，它在各個應用程序域（AppDomain）是共享的。
在內部，線程池將自己的線程划分工作者線程(輔助線程)和I/O線程。前者用於執行普通的操作，后者專用於異步IO，比如文件和網絡請求，注意，分類並不說明兩種線程本身有差別，內部依然是一樣的。
public static class ThreadPool
{
// 將操作系統句柄綁定到System.Threading.ThreadPool。
public static bool BindHandle(SafeHandle osHandle);
// 檢索由ThreadPool.GetMaxThreads(Int32,Int32)方法返回的最大線程池線程數和當前活動線程數之間的差值。
public static void GetAvailableThreads(out int workerThreads
, out int completionPortThreads);
// 設置和檢索可以同時處於活動狀態的線程池請求的數目。
// 所有大於此數目的請求將保持排隊狀態，直到線程池線程變為可用。
public static bool SetMaxThreads(int workerThreads, int completionPortThreads);
public static void GetMaxThreads(out int workerThreads, out int completionPortThreads);
// 設置和檢索線程池在新請求預測中維護的空閑線程數。
public static bool SetMinThreads(int workerThreads, int completionPortThreads);
public static void GetMinThreads(out int workerThreads, out int completionPortThreads);
// 將方法排入隊列以便執行，並指定包含該方法所用數據的對象。此方法在有線程池線程變得可用時執行。
public static bool QueueUserWorkItem(WaitCallback callBack, object state);
// 將重疊的 I/O 操作排隊以便執行。如果成功地將此操作排隊到 I/O 完成端口，則為 true；否則為 false。
// 參數overlapped:要排隊的System.Threading.NativeOverlapped結構。
public static bool UnsafeQueueNativeOverlapped(NativeOverlapped* overlapped);
// 將指定的委托排隊到線程池，但不會將調用堆棧傳播到工作者線程。
public static bool UnsafeQueueUserWorkItem(WaitCallback callBack, object state);
// 注冊一個等待Threading.WaitHandle的委托，並指定一個 32 位有符號整數來表示超時值（以毫秒為單位）。
// executeOnlyOnce如果為 true，表示在調用了委托后，線程將不再在waitObject參數上等待；
// 如果為 false，表示每次完成等待操作后都重置計時器，直到注銷等待。
public static RegisteredWaitHandle RegisterWaitForSingleObject(
WaitHandle waitObject
, WaitOrTimerCallback callBack, object state,
Int millisecondsTimeOutInterval, bool executeOnlyOnce);
public static RegisteredWaitHandle UnsafeRegisterWaitForSingleObject(
WaitHandle waitObject
, WaitOrTimerCallback callBack
, object state
, int millisecondsTimeOutInterval
, bool executeOnlyOnce);
……
}
1. 線程池線程數
1) 使用GetMaxThreads()和SetMaxThreads()獲取和設置最大線程數
可排隊到線程池的操作數僅受內存的限制；而線程池限制進程中可以同時處於活動狀態的線程數（默認情況下，限制每個 CPU 可以使用 25 個工作者線程和 1,000 個 I/O 線程(根據機器CPU個數和.net framework版本的不同，這些數據可能會有變化)），所有大於此數目的請求將保持排隊狀態，直到線程池線程變為可用。
不建議更改線程池中的最大線程數：
a) 將線程池大小設置得太大，可能會造成更頻繁的執行上下文切換及加劇資源的爭用情況。
b) 其實FileStream的異步讀寫,異步發送接受Web請求,System.Threading.Timer定時器,甚至使用delegate的beginInvoke都會默認調用 ThreadPool,也就是說不僅你的代碼可能使用到線程池,框架內部也可能使用到。
c) 一個應用程序池是一個獨立的進程,擁有一個線程池,應用程序池中可以有多個WebApplication,每個運行在一個單獨的AppDomain中,這些WebApplication公用一個線程池。
2) 使用GetMinThreads()和SetMinThreads()獲取和設置最小空閑線程數
為避免向線程分配不必要的堆棧空間，線程池按照一定的時間間隔創建新的空閑線程（該間隔為半秒）。所以如果最小空閑線程數設置的過小，在短期內執行大量任務會因為創建新空閑線程的內置延遲導致性能瓶頸。最小空閑線程數默認值等於機器上的CPU核數，並且不建議更改最小空閑線程數。
在啟動線程池時，線程池具有一個內置延遲，用於啟用最小空閑線程數，以提高應用程序的吞吐量。
在線程池運行中，對於執行完任務的線程池線程，不會立即銷毀，而是返回到線程池，線程池會維護最小的空閑線程數(即使應用程序所有線程都是空閑狀態)，以便隊列任務可以立即啟動。超過此最小數目的空閑線程一段時間沒事做后會自己醒來終止自己，以節省系統資源。
3) 靜態方法GetAvailableThreads()
通過靜態方法GetAvailableThreads()返回的線程池線程的最大數目和當前活動數目之間的差值，即獲取線程池中當前可用的線程數目
4) 兩個參數
方法GetMaxThreads()、SetMaxThreads()、GetMinThreads()、SetMinThreads()、GetAvailableThreads()鈞包含兩個參數。參數workerThreads指工作者線程；參數completionPortThreads指異步 I/O 線程。
2. 排隊工作項
通過調用 ThreadPool.QueueUserWorkItem 並傳遞 WaitCallback 委托來使用線程池。也可以通過使用 ThreadPool.RegisterWaitForSingleObject 並傳遞 WaitHandle（在向其發出信號或超時時，它將引發對由 WaitOrTimerCallback 委托包裝的方法的調用）來將與等待操作相關的工作項排隊到線程池中。若要取消等待操作（即不再執行WaitOrTimerCallback委托），可調用RegisterWaitForSingleObject()方法返回的RegisteredWaitHandle的 Unregister 方法。
如果您知道調用方的堆棧與在排隊任務執行期間執行的所有安全檢查不相關，則還可以使用不安全的方法 ThreadPool.UnsafeQueueUserWorkItem 和 ThreadPool.UnsafeRegisterWaitForSingleObject。QueueUserWorkItem 和 RegisterWaitForSingleObject 都會捕獲調用方的堆棧，此堆棧將在線程池線程開始執行任務時合並到線程池線程的堆棧中。如果需要進行安全檢查，則必須檢查整個堆棧，但它還具有一定的性能開銷。使用“不安全的”方法調用並不會提供絕對的安全，但它會提供更好的性能。
3. 在一個內核構造可用時調用一個方法
讓一個線程不確定地等待一個內核對象進入可用狀態，這對線程的內存資源來說是一種浪費。ThreadPool.RegisterWaitForSingleObject()為我們提供了一種方式：在一個內核對象變得可用的時候調用一個方法。
使用需注意：
1) WaitOrTimerCallback委托參數，該委托接受一個名為timeOut的Boolean參數。如果 WaitHandle 在指定時間內沒有收到信號（即，超時），則為 true，否則為 false。回調方法可以根據timeOut的值來針對性地采取措施。
2) 名為executeOnlyOnce的Boolean參數。傳true則表示線程池線程只執行回調方法一次；若傳false則表示內核對象每次收到信號，線程池線程都會執行回調方法。等待一個AutoResetEvent對象時，這個功能尤其有用。
3) RegisterWaitForSingleObject()方法返回一個RegisteredWaitHandle對象的引用。這個對象標識了線程池正在它上面等待的內核對象。我們可以調用它的Unregister(WaitHandle waitObject)方法取消由RegisterWaitForSingleObject()注冊的等待操作(即WaitOrTimerCallback委托不再執行)。Unregister(WaitHandle waitObject)的WaitHandle參數表示成功取消注冊的等待操作后線程池會向此對象發出信號(set())，若不想收到此通知可以傳遞null。
示例：
private static void Example_RegisterWaitForSingleObject()
{
// 加endWaitHandle的原因：如果執行過快退出方法會導致一些東西被釋放，造成排隊的任務不能執行，原因還在研究
AutoResetEvent endWaitHandle = new AutoResetEvent(false);
AutoResetEvent notificWaitHandle = new AutoResetEvent(false);
AutoResetEvent waitHandle = new AutoResetEvent(false);
RegisteredWaitHandle registeredWaitHandle = ThreadPool.RegisterWaitForSingleObject(
waitHandle,
(Object state, bool timedOut) =>
{
if (timedOut)
Console.WriteLine("RegisterWaitForSingleObject因超時而執行");
else
Console.WriteLine("RegisterWaitForSingleObject收到WaitHandle信號");
},
null, TimeSpan.FromSeconds(2), true
);
// 取消等待操作（即不再執行WaitOrTimerCallback委托）
registeredWaitHandle.Unregister(notificWaitHandle);
// 通知
ThreadPool.RegisterWaitForSingleObject(
notificWaitHandle,
(Object state, bool timedOut) =>
{
if (timedOut)
Console.WriteLine("第一個RegisterWaitForSingleObject沒有調用Unregister()");
else
Console.WriteLine("第一個RegisterWaitForSingleObject調用了Unregister()");
endWaitHandle.Set();
},
null, TimeSpan.FromSeconds(4), true
);
endWaitHandle.WaitOne();
}
上一小節中說到：線程池最大線程數設置過大可能會造成Windows頻繁執行上下文切換，降低程序性能。對於大多數園友不會滿意這樣的回答，我和你一樣也喜歡“知其然，再知其所以然”。
1. 上下文切換中的“上下文”是什么？
.NET中上下文太多，我最后得出的結論是：上下文切換中的上下文專指“執行上下文”。
執行上下文包括：安全上下文、同步上下文(System.Threading.SynchronizationContext)、邏輯調用上下文(System.Runtime.Messaging.CallContext)。即：安全設置（壓縮棧、Thread的Principal屬性和Windows身份）、宿主設置（System.Threading.HostExcecutingContextManager）以及邏輯調用上下文數據(System.Runtime.Messaging.CallContext的LogicalSetData()和LogicalGetData()方法)。
2. 何時執行“上下文切換”？
當一個“時間片”結束時，如果Windows決定再次調度同一個線程，那么Windows不會執行上下文切換。如果Windows調度了一個不同的線程，這時Windows執行線程上下文切換。
3. “上下文切換”造成的性能影響
當Windows上下文切換到另一個線程時，CPU將執行一個不同的線程，而之前線程的代碼和數據還在CPU的高速緩存中，（高速緩存使CPU不必經常訪問RAM，RAM的速度比CPU高速緩存慢得多），當Windows上下文切換到一個新線程時，這個新線程極有可能要執行不同的代碼並訪問不同的數據，這些代碼和數據不在CPU的高速緩存中。因此，CPU必須訪問RAM來填充它的高速緩存，以恢復高速執行狀態。但是，在其“時間片”執行完后，一次新的線程上下文切換又發生了。
上下文切換所產生的開銷不會換來任何內存和性能上的收益。執行上下文所需的時間取決於CPU架構和速度（即“時間片”的分配）。而填充CPU緩存所需的時間取決於系統運行的應用程序、CPU、緩存的大小以及其他各種因素。所以，無法為每一次線程上下文切換的時間開銷給出一個確定的值，甚至無法給出一個估計的值。唯一確定的是，如果要構建高性能的應用程序和組件，就應該盡可能避免線程上下文切換。
除此之外，執行垃圾回收時，CLR必須掛起(暫停)所有線程，遍歷它們的棧來查找根以便對堆中的對象進行標記，再次遍歷它們的棧(有的對象在壓縮期間發生了移動，所以要更新它們的根)，再恢復所有線程。所以，減少線程的數量也會顯著提升垃圾回收器的性能。每次使用一個調試器並遇到一個斷點，Windows都會掛起正在調試的應用程序中的所有線程，並在單步執行或運行應用程序時恢復所有線程。因此，你用的線程越多，調試體驗也就越差。
4. 監視Windows上下文切換工具
Windows實際記錄了每個線程被上下文切換到的次數。可以使用像Microsoft Spy++這樣的工具查看這個數據。這個工具是Visual Studio附帶的一個小工具(vs按安裝路徑\Visual Studio 2012\Common7\Tools)，如圖
5. 執行上下文類詳解
在《異步編程：線程概述及使用》中我提到了Thread的兩個上下文，即：
1) CurrentContext 獲取線程正在其中執行的當前上下文。主要用於線程內部存儲數據。
2) ExecutionContext 獲取一個System.Threading.ExecutionContext對象，該對象包含有關當前線程的各種上下文的信息。主要用於線程間數據共享。
其中獲取到的System.Threading.ExecutionContext就是本小節要說的“執行上下文”。
public sealed class ExecutionContext : IDisposable, ISerializable
{
public void Dispose();
public void GetObjectData(SerializationInfo info, StreamingContext context);
// 此方法對於將執行上下文從一個線程傳播到另一個線程非常有用。
public ExecutionContext CreateCopy();
// 從當前線程捕獲執行上下文的一個副本。
public static ExecutionContext Capture();
// 在當前線程上的指定執行上下文中運行某個方法。
public static void Run(ExecutionContext executionContext, ContextCallback callback, object state);
// 取消執行上下文在異步線程之間的流動。
public static AsyncFlowControl SuppressFlow();
public static bool IsFlowSuppressed();
// RestoreFlow 撤消以前的 SuppressFlow 方法調用的影響。
// 此方法由 SuppressFlow 方法返回的 AsyncFlowControl 結構的 Undo 方法調用。
// 應使用 Undo 方法（而不是 RestoreFlow 方法）恢復執行上下文的流動。
public static void RestoreFlow();
}
ExecutionContext 類提供的功能讓用戶代碼可以在用戶定義的異步點之間捕獲和傳輸此上下文。公共語言運行時(CLR)確保在托管進程內運行時定義的異步點之間一致地傳輸 ExecutionContext。
每當一個線程(初始線程)使用另一個線程(輔助線程)執行任務時，CLR會將前者的執行上下文流向（復制到）輔助線程（注意這個自動流向是單方向的）。這就確保了輔助線程執行的任何操作使用的是相同的安全設置和宿主設置。還確保了初始線程的邏輯調用上下文可以在輔助線程中使用。
但執行上下文的復制會造成一定的性能影響。因為執行上下文中包含大量信息，而收集所有這些信息，再把它們復制到輔助線程，要耗費不少時間。如果輔助線程又采用了更多地輔助線程，還必須創建和初始化更多的執行上下文數據結構。
所以，為了提升應用程序性能，我們可以阻止執行上下文的流動。當然這只有在輔助線程不需要或者不訪問上下文信息的時候才能進行阻止。
下面給出一個示例為了演示：
1) 在線程間共享邏輯調用上下文數據（CallContext）。
2) 為了提升性能，阻止\恢復執行上下文的流動。
3) 在當前線程上的指定執行上下文中運行某個方法。
private static void Example_ExecutionContext()
{
CallContext.LogicalSetData("Name", "小紅");
Console.WriteLine("主線程中Name為：{0}", CallContext.LogicalGetData("Name"));
// 1) 在線程間共享邏輯調用上下文數據（CallContext）。
Console.WriteLine("1)在線程間共享邏輯調用上下文數據（CallContext）。");
ThreadPool.QueueUserWorkItem((Object obj)
=> Console.WriteLine("ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
Thread.Sleep(500);
Console.WriteLine();
// 2) 為了提升性能，取消\恢復執行上下文的流動。
ThreadPool.UnsafeQueueUserWorkItem((Object obj)
=> Console.WriteLine("ThreadPool線程使用Unsafe異步執行方法來取消執行上下文的流動。Name為：\"{0}\""
, CallContext.LogicalGetData("Name")), null);
Console.WriteLine("2)為了提升性能，取消/恢復執行上下文的流動。");
AsyncFlowControl flowControl = ExecutionContext.SuppressFlow();
ThreadPool.QueueUserWorkItem((Object obj)
=> Console.WriteLine("(取消ExecutionContext流動)ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
Thread.Sleep(500);
// 恢復不推薦使用ExecutionContext.RestoreFlow()
flowControl.Undo();
ThreadPool.QueueUserWorkItem((Object obj)
=> Console.WriteLine("(恢復ExecutionContext流動)ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
Thread.Sleep(500);
Console.WriteLine();
// 3) 在當前線程上的指定執行上下文中運行某個方法。(通過獲取調用上下文數據驗證)
Console.WriteLine("3)在當前線程上的指定執行上下文中運行某個方法。(通過獲取調用上下文數據驗證)");
ExecutionContext curExecutionContext = ExecutionContext.Capture();
ExecutionContext.SuppressFlow();
ThreadPool.QueueUserWorkItem(
(Object obj) =>
{
ExecutionContext innerExecutionContext = obj as ExecutionContext;
ExecutionContext.Run(innerExecutionContext, (Object state)
=> Console.WriteLine("ThreadPool線程中Name為：\"{0}\""
, CallContext.LogicalGetData("Name")), null);
}
, curExecutionContext
);
}
結果如圖：
注意：
1) 示例中“在當前線程上的指定執行上下文中運行某個方法”：代碼中必須使用ExecutionContext.Capture()獲取當前執行上下文的一個副本。
a) 若直接使用Thread.CurrentThread.ExecutionContext則會報“無法應用以下上下文: 跨 AppDomains 封送的上下文、不是通過捕獲操作獲取的上下文或已作為 Set 調用的參數的上下文。”錯誤。
b) 若使用Thread.CurrentThread.ExecutionContext.CreateCopy()會報“只能復制新近捕獲(ExecutionContext.Capture())的上下文”。
2) 取消執行上下文流動除了使用ExecutionContext.SuppressFlow()方式外。還可以通過使用ThreadPool的UnsafeQueueUserWorkItem 和 UnsafeRegisterWaitForSingleObject來執行委托方法。原因是不安全的線程池操作不會傳輸壓縮堆棧。每當壓縮堆棧流動時，托管的主體、同步、區域設置和用戶上下文也隨之流動。
線程池線程中的異常
線程池線程中未處理的異常將終止進程。以下為此規則的三種例外情況：
1. 由於調用了 Abort，線程池線程中將引發ThreadAbortException。
2. 由於正在卸載應用程序域，線程池線程中將引發AppDomainUnloadedException。
3. 公共語言運行庫或宿主進程將終止線程。
何時不使用線程池線程
現在大家都已經知道線程池為我們提供了方便的異步API及托管的線程管理。那么是不是任何時候都應該使用線程池線程呢？當然不是，我們還是需要“因地制宜”的，在以下幾種情況下，適合於創建並管理自己的線程而不是使用線程池線程：
1. 需要前台線程。(線程池線程“始終”是后台線程)
2. 需要使線程具有特定的優先級。(線程池線程都是默認優先級，“不建議”進行修改)
3. 任務會長時間占用線程。由於線程池具有最大線程數限制，因此大量占用線程池線程可能會阻止任務啟動。
4. 需要將線程放入單線程單元(STA)。(所有ThreadPool線程“始終”是多線程單元(MTA)中)
5. 需要具有與線程關聯的穩定標識，或使某一線程專用於某一任務。
本博文介紹線程池以及其基礎對象池，ThreadPool類的使用及注意事項，如何排隊工作項到線程池，執行上下文及線程上下文傳遞問題……
線程池雖然為我們提供了異步操作的便利，但是它不支持對線程池中單個線程的復雜控制致使我們有些情況下會直接使用Thread。並且它對“等待”操作、“取消”操作、“延續”任務等操作比較繁瑣，可能迫使你從新造輪子。微軟也想到了，所以在.NET4.0的時候加入了“並行任務”並在.NET4.5中對其進行改進，想了解“並行任務”的園友可以先看看《（譯）關於Async與Await的FAQ》。
本節到此結束，感謝大家的觀賞。贊的話還請多推薦啊 (*^_^*)
參考資料：《CLR via C#(第三版)》