线程池（ThreadPool）

时间 2019-11-17

标签线程 threadpool 繁體版

原文原文链接

线程池概述

由系统维护的容纳线程的容器，由CLR控制的全部AppDomain共享。线程池可用于执行任务、发送工做项、处理异步 I/O、表明其余线程等待以及处理计时器。html

线程池与线程

性能：每开启一个新的线程都要消耗内存空间及资源（默认状况下大约1 MB的内存），同时多线程状况下操做系统必须调度可运行的线程并执行上下文切换，因此太多的线程还对性能不利。而线程池其目的是为了减小开启新线程消耗的资源（使用线程池中的空闲线程，没必要再开启新线程，以及统一管理线程（线程池中的线程执行完毕后，回归到线程池内，等待新任务））。程序员

时间：不管什么时候启动一个线程，都须要时间(几百毫秒)，用于建立新的局部变量堆，线程池预先建立了一组可回收线程，所以能够缩短过载时间。web

线程池缺点：线程池的性能损耗优于线程（经过共享和回收线程的方式实现），可是：算法

1.线程池不支持线程的取消、完成、失败通知等交互性操做。数据库

2.线程池不支持线程执行的前后次序排序。编程

3.不能设置池化线程（线程池内的线程）的Name，会增长代码调试难度。windows

4.池化线程一般都是后台线程，优先级为ThreadPriority.Normal。设计模式

5.池化线程阻塞会影响性能（阻塞会使CLR错误地认为它占用了大量CPU。CLR可以检测或补偿（往池中注入更多线程），可是这可能使线程池受到后续超负荷的印象。Task解决了这个问题）。数组

6.线程池使用的是全局队列，全局队列中的线程依旧会存在竞争共享资源的状况，从而影响性能（Task解决了这个问题方案是使用本地队列）。缓存

线程池工做原理

CLR初始化时，线程池中是没有线程的。在内部，线程池维护了一个操做请求队列。应用程序执行一个异步操做时，会将一个记录项追加到线程池的队列中。线程池的代码从这个队列中读取记录将这个记录项派发给一个线程池线程。若是线程池没有线程，就建立一个新线程。当线程池线程完成工做后，线程不会被销毁，相反线程会返回线程池，在那里进入空闲状态，等待响应另外一个请求，因为线程不销毁自身，因此再也不产生额外的性能损耗。

程序向线程池发送多条请求，线程池尝试只用这一个线程来服务全部请求，当请求速度超过线程池线程处理任务速度，就会建立额外线程，因此线程池没必要建立大量线程。

若是中止向线程池发送任务，池中大量空闲线程将在一段时间后本身醒来终止本身以释放资源(CLR不一样版本对这个事件定义不一)。

工做者线程&I/O线程

线程池容许线程在多个CPU内核上调度任务，使多个线程能并发工做，从而高效率的使用系统资源，提高程序的吞吐性。

CLR线程池分为工做者线程与I/O线程两种:

工做者线程(workerThreads)：负责管理CLR内部对象的运做，提供”运算能力“，因此一般用于计算密集（compute-bound）性操做。

I/O线程(completionPortThreads)：主要用于与外部系统交换信息（如读取一个文件）和分发IOCP中的回调。

注意：线程池会预先缓存一些工做者线程由于建立新线程的代价比较昂贵。

IO完成端口（IOCP）

IO完成端口（IOCP、I/O completion port）：IOCP是一个异步I/O的API（能够看做一个消息队列），提供了处理多个异步I/O请求的线程模型，它能够高效地将I/O事件通知给应用程序。IOCP由CLR内部维护，当异步IO请求完成时，设备驱动就会生成一个I/O请求包（IRP、I/O Request Packet），并排队（先入先出）放入完成端口。以后会由I/O线程提取完成IRP并调用以前的委托。

I/O线程&IOCP&IRP:

当执行I/O操做时（同步I/O操做 and 异步I/O操做)，都会调用Windows的API方法将当前的线程从用户态转变成内核态，同时生成并初始化一个I/O请求包，请求包中包含一个文件句柄，一个偏移量和一个Byte[]数组。I/O操做向内核传递请求包，根据这个请求包，windows内核确认这个I/O操做对应的是哪一个硬件设备。这些I/O操做会进入设备本身的处理队列中，该队列由这个设备的驱动程序维护。

若是是同步I/O操做，那么在硬件设备操做I/O的时候，发出I/O请求的线程因为”等待“（无人任务处理）被Windows变成睡眠状态，当硬件设备完成操做后，再唤醒这个线程。因此性能不高，若是请求数不少，那么休眠的线程数也不少，浪费大量资源。

若是是异步I/O操做（在.Net中，异步的I/O操做都是以Beginxxx形式开始，内部实现为ThreadPool.BindHandle，须要传入一个委托，该委托会随着IRP一路传递到设备的驱动程序），该方法在Windows把I/O请求包发送到设备的处理队列后就会返回。同时，CLR会分配一个可用的线程用于继续执行接下来的任务，当任务完成后，经过IOCP提醒CLR它工做已经完成，当接收到通知后将该委托再放到CLR线程池队列中由I\O线程进行回调。

因此：大多数状况下，开发人员使用工做者线程，I/O线程由CLR调用（开发者并不会直接使用）。

基础线程池&工做者线程（ThreadPool）

.NET中使用线程池用到ThreadPool类，ThreadPool是一个静态类，定义于System.Threading命名空间,自.NET 1.1起引入。

调用方法QueueUserWorkItem能够将一个异步的计算限制操做放到线程池的队列中，这个方法向线程池的队列添加一个工做项以及可选的状态数据。
工做项：由callBack参数标识的一个方法，该方法由线程池线程调用。可向方法传递一个state实参（多于一个参数则须要封装为实体类）。

1  public static bool QueueUserWorkItem(WaitCallback callBack);
2  public static bool QueueUserWorkItem(WaitCallback callBack, object state);

下面是经过QueueUserWorkItem启动工做者线程的示例：

 1     class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             //方式一
 6             {
 7                 ThreadPool.QueueUserWorkItem(n => Test("Test-ok"));
 8             }
 9             //方式二
10             {
11                 WaitCallback waitCallback = new WaitCallback(Test);
12                 ThreadPool.QueueUserWorkItem(n => waitCallback("WaitCallback"));//二者效果相同 ThreadPool.QueueUserWorkItem(waitCallback,"Test-ok"); 13             }
14             //方式三
15             {
16                 ParameterizedThreadStart parameterizedThreadStart = new ParameterizedThreadStart(Test);
17                 ThreadPool.QueueUserWorkItem(n => parameterizedThreadStart("ParameterizedThreadStart"));
18             }
19             //方式四
20             {
21                 TimerCallback timerCallback = new TimerCallback(Test);
22                 ThreadPool.QueueUserWorkItem(n => timerCallback("TimerCallback"));
23             }
24             //方式五
25             {
26                 Action<object> action = Test;
27                 ThreadPool.QueueUserWorkItem(n => Test("Action"));
28             }
29             //方式六
30             ThreadPool.QueueUserWorkItem((o) =>
31             {
32                 var msg = "lambda";
33                 Console.WriteLine("执行方法:{0}", msg);
34             });
35             
36             ......
37 
38             Console.ReadKey();
39         }
40         static void Test(object o)
41         {
42             Console.WriteLine("执行方法:{0}", o);
43         }
44         /*
45          * 做者：Jonins
46          * 出处：http://www.cnblogs.com/jonins/
47          */
48     }

执行结果以下：

以上是使用线程池的几种写法，WaitCallback本质上是一个参数为Object类型无返回值的委托

1  public delegate void WaitCallback(object state);

因此符合要求的类型均可以如上述示例代码做为参数进行传递。

线程池经常使用方法

ThreadPool经常使用的几个方法以下：

方法	说明
QueueUserWorkItem	启动线程池里的一个线程（工做者线程）
GetMinThreads	检索线程池在新请求预测中可以按需建立的线程的最小数量。
GetMaxThreads	最多可用线程数，全部大于此数目的请求将保持排队状态，直到线程池线程由空闲。
GetAvailableThreads	剩余空闲线程数。
SetMaxThreads	设置线程池中的最大线程数（请求数超过此值则进入队列）。
SetMinThreads	设置线程池最少须要保留的线程数。

示例代码：

 1         static void Main(string[] args)
 2         {
 3             //声明变量 （工做者线程计数  Io完成端口计数）
 4             int workerThreadsCount, completionPortThreadsCount;
 5             {
 6                 ThreadPool.GetMinThreads(out workerThreadsCount, out completionPortThreadsCount);
 7                 Console.WriteLine("最小工做线程数：{0}，最小IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
 8             }
 9             {
10                 ThreadPool.GetMaxThreads(out workerThreadsCount, out completionPortThreadsCount);
11                 Console.WriteLine("最大工做线程数：{0}，最大IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
12             }
13             ThreadPool.QueueUserWorkItem((o) => {
14                 Console.WriteLine("占用1个池化线程");
15             });
16             {
17                 ThreadPool.GetAvailableThreads(out workerThreadsCount, out completionPortThreadsCount);
18                 Console.WriteLine("剩余工做线程数：{0}，剩余IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
19             }
20             Console.ReadKey();
21         }

执行的结果：

注意：

1.线程有内存开销，因此线程池内的线程过多而没有彻底利用是对内存的一种浪费，因此须要对线程池限制最小线程数量。

2.线程池最大线程数是线程池最多可建立线程数，实际状况是线程池内的线程数是按需建立。

I/O线程

I\O线程是.NET专为访问外部资源所引入的一种线程，访问外部资源时为了防止主线程长期处于阻塞状态，.NET为多个I/O操做创建了异步方法。例如：

FileStream：BeginRead、BeginWrite。调用BeginRead/BeginWrite时会发起一个异步操做，可是只有在建立FileStream时传入FileOptions.Asynchronous参数才能获取真正的IOCP支持，不然BeginXXX方法将会使用默认定义在Stream基类上的实现。Stream基类中BeginXXX方法会使用委托的BeginInvoke方法来发起异步调用——这会使用一个额外的线程来执行任务（并不受IOCP支持，可能额外增长性能损耗）。

DNS：BeginGetHostByName、BeginResolve。

Socket：BeginAccept、BeginConnect、BeginReceive等等。

WebRequest：BeginGetRequestStream、BeginGetResponse。

SqlCommand：BeginExecuteReader、BeginExecuteNonQuery等等。这多是开发一个Web应用时最经常使用的异步操做了。若是须要在执行数据库操做时获得IOCP支持，那么须要在链接字符串中标记Asynchronous Processing为true（默认为false），不然在调用BeginXXX操做时就会抛出异常。

WebServcie：例如.NET 2.0或WCF生成的Web Service Proxy中的BeginXXX方法、WCF中ClientBase<TChannel>的InvokeAsync方法。

这些异步方法的使用方式都比较相似，都是以Beginxxx开始（内部实现为ThreadPool.BindHandle），以Endxxx结束。

注意：

1.对于APM而言必须使用Endxxx结束异步，不然可能会形成资源泄露。

2.委托的BeginInvoke方法并不能得到IOCP支持。

3.IOCP不占用线程。

下面是使用WebRequest的一个示例调用异步API占用I/O线程：

 1     class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             int workerThreadsCount, completionPortThreadsCount;
 6             ThreadPool.GetAvailableThreads(out workerThreadsCount, out completionPortThreadsCount);
 7             Console.WriteLine("剩余工做线程数：{0}，剩余IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
 8             //调用WebRequest类的异步API占用IO线程
 9             {
10                 WebRequest webRequest = HttpWebRequest.Create("http://www.cnblogs.com/jonins");
11                 webRequest.BeginGetResponse(result =>
12                 {
13                     Thread.Sleep(2000);
14                     Console.WriteLine(Thread.CurrentThread.ManagedThreadId + ":执行最终响应的回调");
15                     WebResponse webResponse = webRequest.EndGetResponse(result);
16                 }, null);
17             }
18             Thread.Sleep(1000);
19             ThreadPool.GetAvailableThreads(out workerThreadsCount, out completionPortThreadsCount);
20             Console.WriteLine("剩余工做线程数：{0}，剩余IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
21             Console.ReadKey();
22         }
23     }

执行结果以下：

有关I/O线程的内容点到此为止，感受更可能是I/O操做、文件等方面的知识点跟线程池瓜葛很少，想了解更多戳：这里

执行上下文

每一个线程都关联了一个执行上下文数据结构，执行上下文（execution context）包括：

1.安全设置（压缩栈、Thread的Principal属性、winodws身份）。

2.宿主设置（System.Threading.HostExecutionContextManager）。

3.逻辑调用上下文数据（System.Runtime.Remoting.Messaging.CallContext的LogicalGetData和LogicalSetData方法）。

线程执行它的代码时，一些操做会受到线程执行上下文限制，尤为是安全设置的影响。

当主线程使用辅助线程执行任务时，前者的执行上下文“流向”（复制到）辅助线程，这确保了辅助线程执行的任何操做使用的是相同的安全设置和宿主设置。

默认状况下，CLR自动形成初始化线程的执行上下文“流向”任何辅助线程。但这会对性能形成影响。执行上下包含的大量信息采集并复制到辅助线程要耗费时间，若是辅助线程又采用了更多的辅助线程还必须建立和初始化更多的执行上下文数据结构。

System.Threading命名空间的ExecutionContext类，它容许控制线程执行上下文的流动：

 1     class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             //将一些数据放到主函数线程的逻辑调用上下文中
 6             CallContext.LogicalSetData("Action", "Jonins");
 7             //初始化要由另外一个线程作的一些事情，线程池线程能访问逻辑上下文数据
 8             ThreadPool.QueueUserWorkItem(state => Console.WriteLine("辅助线程A:" + Thread.CurrentThread.ManagedThreadId + ";Action={0}", CallContext.LogicalGetData("Action")));
 9             //如今阻止主线程执行上下文流动
10             ExecutionContext.SuppressFlow();
11             //初始化要由另外一个线程作的一些事情，线程池线程能访问逻辑上下文数据
12             ThreadPool.QueueUserWorkItem(state => Console.WriteLine("辅助线程B:" + Thread.CurrentThread.ManagedThreadId + ";Action={0}", CallContext.LogicalGetData("Action")));
13             //恢复主线程的执行上下文流动，以免使用更多的线程池线程
14             ExecutionContext.RestoreFlow();
15             Console.ReadKey();
16         }
17     }

结果以下：

ExecutionContext类阻止上下文流动以提高程序的性能，对于服务器应用程序，性能的提高可能很是显著。可是客户端应用程序的性能提高不了多少。另外，因为SuppressFlow方法用[SecurityCritical]特性标记，因此某些客户端如Silverlight中是没法调用的。

注意：

1.辅助线程在不须要或者不访问上下文信息时，应阻止执行上下文的流动。

2.执行上下文流动的相关知识，在使用Task对象以及发起异步I/O操做时，一样有用。

三种异步模式（扫盲）&BackgroundWorker

1.APM&EAP&TAP

.NET支持三种异步编程模式分别为APM、EAP和TAP：

1.基于事件的异步编程设计模式 （EAP，Event-based Asynchronous Pattern）

EAP的编程模式的代码命名有如下特色：

1.有一个或多个名为 “[XXX]Async” 的方法。这些方法可能会建立同步版本的镜像，这些同步版本会在当前线程上执行相同的操做。
2.该类还可能有一个 “[XXX]Completed” 事件，监听异步方法的结果。
3.它可能会有一个 “[XXX]AsyncCancel”（或只是 CancelAsync）方法，用于取消正在进行的异步操做。

2.异步编程模型（APM，Asynchronous Programming Model）

APM的编程模式的代码命名有如下特色：

1.使用 IAsyncResult 设计模式的异步操做是经过名为[BeginXXX] 和 [EndXXX] 的两个方法来实现的，这两个方法分别开始和结束异步操做操做名称。例如，FileStream 类提供 BeginRead 和 EndRead 方法来从文件异步读取字节。

2.在调用 [BeginXXX] 后，应用程序能够继续在调用线程上执行指令，同时异步操做在另外一个线程上执行。每次调用 [BeginXXX] 时，应用程序还应调用 [EndXXX] 来获取操做的结果。

3.基于任务的编程模型（TAP，Task-based Asynchronous Pattern）

基于 System.Threading.Tasks 命名空间的 Task 和 Task<TResult>，用于表示任意异步操做。 TAP以后再讨论。关于三种异步操做详细说明请戳：这里

2.BackgroundWorker

BackgroundWorker本质上是使用线程池内工做者线程，不过这个类已经多余了（了解便可）。在BackgroundWorker的DoWork属性追加自定义方法，经过RunWorkerAsync将自定义方法追加进池化线程内处理。

DoWork本质上是一个事件（event）。委托类型限制为无返回值且参数有两个分别为Object和DoWorkEventArgs类型。

1 public event DoWorkEventHandler DoWork;
2 
3 public delegate void DoWorkEventHandler(object sender, DoWorkEventArgs e);

示例以下：

 1     class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             int workerThreadsCount, completionPortThreadsCount;
 6             ThreadPool.GetAvailableThreads(out workerThreadsCount, out completionPortThreadsCount);
 7             Console.WriteLine("剩余工做线程数：{0}，剩余IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
 8             {
 9                 BackgroundWorker backgroundWorker = new BackgroundWorker();
10                 backgroundWorker.DoWork += DoWork;
11                 backgroundWorker.RunWorkerAsync();
12             }
13             Thread.Sleep(1000);
14             ThreadPool.GetAvailableThreads(out workerThreadsCount, out completionPortThreadsCount);
15             Console.WriteLine("剩余工做线程数：{0}，剩余IO线程数{1}", workerThreadsCount, completionPortThreadsCount);
16             Console.ReadKey();
17         }
18         private static void DoWork(object sender, DoWorkEventArgs e)
19         {
20             Thread.Sleep(2000);
21             Console.WriteLine("demo-ok");
22         }
23     }

内部占用线程内线程，结果以下：

结语

程序员使用线程池更多的是使用线程池内的工做者线程进行逻辑编码。

相对于单独操做线程（Thread），线程池（ThreadPool）可以保证计算密集做业的临时过载不会引发CPU超负荷（激活的线程数量多于CPU内核数量，系统必须按时间片执行线程调度）。

超负荷会影响性能，由于划分时间片须要大量的上下文切换开销，而且使CPU缓存失效，而这些是处理器实现高效的必要调度。

CLR可以将任务进行排序，而且控制任务启动数量，从而避免线程池超负荷。CLR首先运行与硬件内核数量同样多的并发任务，而后经过登山算法调整并发数量，保证程序切合最优性能曲线。

参考文献

CLR via C#（第4版） Jeffrey Richter

C#高级编程（第10版） C# 6 & .NET Core 1.0 Christian Nagel

果壳中的C# C#5.0权威指南 Joseph Albahari

http://www.cnblogs.com/dctit/

http://www.cnblogs.com/kissdodog/

http://www.cnblogs.com/JeffreyZhao/

...