绝大多数情况下,我们都应该使用CLR线程池,而不是直接操作Thread,本章节介绍直接操作线程池的ThreadPool,但实际开发中也很少直接使用它。
一、CLR和线程池
1.1 CLR的主要工作
CLR(Common Language Runtime),公共语言运行时,是管理应用程序执行的运行时环境,类似Java的JVM虚拟机。之所以叫公共语言,是因为它支持多种语言编译为CLR执行的字节码,尽管绝大多数情况下都是使用C#。它的工作主要包括:
- 托管应用程序代码
- 加载和管理程序集
- 内存分配和垃圾回收
- 类型安全和代码验证
- 异常处理
- 调试诊断工具集
- 代码执行,包括JIT编译(将中间字节码编译为本地机器码)和跨语言互操作
- 安全管理,使用CAS策略和授权机制,限制代码可执行的操作权限
- AppDomain, 比进程更轻量的隔离方式 ,有自己的安全策略、配置文件和垃圾回收,现在较少使用了
- 线程管理,底层使用Windows操作系统进行管理和调度,但CLR提供了线程管理的API
1.2 应用程序和CLR实例是一对一关系吗?
正常情况下,每个应用程序都托管在一个CLR实例中,但由于.NET的技术发展历史,存在一些不一样的情况:
- 早期的AspNet应用,托管在IIS中。IIS维护着一个应用线程池,只有一个CLR实例。CLR创建多个AppDomain,每个应用都在相互隔离的AppDomain中运行。所以,这些应用共享着一个CLR实例。但是,现在更加鼓励直接使用进程。
- 现代的AspNetCore应用,无论是使用Kestrel独立运行,还是用IIS作为反向代理,或是在容器中运行,每个AspNetCore应用都拥有独立的进程和CLR实例,已不再依赖于AppDomain。
- 桌面应用和控制台应用, 应用程序启动时,CLR会创建一个默认的AppDomain。应用程序的所有代码和资源都会加载到这个默认的AppDomain中,一个应用对应一个CLR实例。
1.3 CLR和线程池
创建和销毁线程的开销很大,太多的线程不但浪费资源,也会影响GC性能,所在CLR管理着一个线程池。如果CLR实例中有AppDomain,则所有AppDomain共享这个线程池。如果一个进程加载了多个CLR,则每个CLR都有一个线程池。
CLR初始化时,线程池中还没有线程。线程池维护着一个操作请求队列,当应用程序执行一个异步操作时,会将这个异步任务追加到队列中。线程池从队列中取出任务,并派发给一个线程池中的线程。如果线程池中没有线程,会自动创建一个新线程,这和创建线程的开销没有什么大的区别。重要在于,这个线程完成任务后,并不会销毁,而是返回线程池,进入空闲状态,等待响应另外一个请求。如果异步请求非常多,线程池会自动扩充线程数量,以适应繁忙的请求;当请求减少时,就会有比较多的线程空闲下来并进入休眠状态,休眠时间超过一个阀值,线程会自己醒来,并干掉自己,以释放资源。
正常情况下,CLR会根据CPU的核数,快速创建初始数量的线程,以充分利用多核CPU的性能,这通常也是线程池的最小线程数。System.Threading.ThreadPool类提供了几个静态方法,可以获取和设置线程池的最小和最大数量:GetMaxThreads、SetMaxThreads、GetMinThreads、SetMinThreads。但强列建议不要去设置,处理这些问题,CLR比我们更聪明。
1.4 线程池的调度原理
CLR线程池的调度工作原理,如下所示:
- 主线程将线程池异步任务(使用ThreadPool、Task、Timer等创建的异步任务),放入到CLR线程池的全局队列中。工作者线程(以下称之为异步线程)按先入先出的规则,从全局队列中取出异步任务,这时可能出现多个异步线程同时取同一个任务的情况,为以保障多个线程不会取到同一个任务,所有线程都要先竞争这个任务的线程同步锁。锁定后,其它线程就不会再竞争这个任务。
- 当异步线程取出任务后,会放入属于自己的本地队列中,再按后入先出的规则取出任务进行处理。由于本地队列只属于自己,所以此时不需要同步锁。
- 如果异步线程发现它的本地队列空了,会尝试从另一个异步线程的本地队列的尾部中“偷”一个任务,此时会请求获取这个任务的线程同步锁。
- 当所有本地队列都空了,就会尝试从全局队列中取任务,如果也空了,就会进入睡眠状态。如果睡眠太长时间,会自己醒来,并销毁自身,GC会在适当时候回收线程使用的资源。
注意:CLR线程池,不仅只有工作者线程,还有I/O线程,将在I/O异步操作章节详述
二、使用ThreadPool
2.1 使用ThreadPool创建(线程池)线程
//以下分别使用传入方法和传入Lambda的方式,创建线程
//使用QueueUserWorkItem()方法创建,结合上节原理,"Queue"很贴切
public class Program
{
static void Main()
{
var ct = Thread.CurrentThread;
Console.WriteLine($"{ct.ManagedThreadId}:主线程开始");
//方式1:传入方法
ThreadPool.QueueUserWorkItem(NoParamWorker);
//方式2:传入Lambda
//ThreadPool.QueueUserWorkItem((state)=>{...},实参),state为形参
ThreadPool.QueueUserWorkItem((state) =>
{
var ct = Thread.CurrentThread;
Console.WriteLine($"{ct.ManagedThreadId}:Worker拿到参数{state}");
},5);
}
static void NoParamWorker(object state)
{
var ct = Thread.CurrentThread;
Console.WriteLine($"{ct.ManagedThreadId}:Worker执行不传参的任务");
}
}
/*输出
1:主线程开始
6:Worker线程执行不传参的任务
7:Worker线程拿到参数5
*/
2.2 使用CancellationTokenSource终止线程
上节我们使用共享变量来终止线程,这节使用终止线程的专用对象CancellationTokenSource,两者原理和用法相似。直白的说,就是向线程传入一个信号令牌(Token),可以在线程外部发送终止信号(Cancel),线程收到终止信号后(Token.IsCancellationRequested),由自己来终止线程。外部直接终止线程是危险的操作,之前可以用的Abort(),现在已经不能使用。只能传入信号,由线程自己终止自己,这样可以安全的释放内存。
//1、在异步线程中循环输出数字,然后在主线程中终止异步线程==========
public class Program
{
static void Main()
{
//创建Token信号令牌源,一个源可以关联多个令牌
var cts = new CancellationTokenSource();
//创建线程,并传入Token信号令牌
ThreadPool.QueueUserWorkItem((state) => CountWorker(cts.Token, 10000) );
Console.WriteLine("输入Enter,终止异步操作");
Console.ReadLine();
//发送终止信息
cts.Cancel();
Console.ReadLine();
}
static void CountWorker(CancellationToken token, int num)
{
var ct = Thread.CurrentThread;
Console.WriteLine($"{ct.ManagedThreadId}:Worker线程开始执行任务");
for (int i = 0; i < num; i++)
{
if (!token.IsCancellationRequested) //判断是否收到外部的终止信号
{
Console.WriteLine(i);
Thread.Sleep(200);//模拟耗时等待
}
else
{
Console.WriteLine("任务被终止了");
break;//退出循环
}
}
}
}
//2、CancellationTokenSource的其它API================================
//2.1 注册异步线程终止后的回调,可以注册多个
var cts = new CancellationTokenSource();
cts.Token.Register(() => { Console.WriteLine("终止回调1"); });
cts.Token.Register(() => { Console.WriteLine("终止回调2"); });
//2.2 调用上例的CountWorker,不更改方法签名的情况下,屏蔽外部的终止信息
//此时外部调用【cts.Cancel();】,将无法终止线程
ThreadPool.QueueUserWorkItem((state)=>CountWorker(cts.Token.None, 10000));
//2.3 关联多个cts,略
//CancellationTokenSource.CreateLindedTokenSource(cts1.Token,cts2.Token)
2.3 多线程的执行上下文
执行上下文,文字上理解是一个比较抽象的概念。但是,在数据层面,它本质是一个包含着多层嵌套的复杂对象,记录着当前环境的一些信息, 在程序流转时,各个环节都可以读取或设置这个对象。如果做.NET后端,最熟悉的上下文,应该就是HttpContext。
执行上下文,一般包括安全设置、宿主信息、上下文数据等,具体内容根据不同运行环境会有差异。当CLR初始化时,会为主线程创建执行上下文,默认情况下,当一个线程(主线程)使用另外一个线程(辅线程)时,前者的执行上下文会流向(复制)辅线程。如果在辅助线程里再开辅助线程,也是遵循这样的规律。
绝大多数情况下,按默认方式传递是最优的,但这种流向还是会消耗一些性能。如果想极致提升性能,而辅助线程又用不到执行上下文,可以手动阻止上下文流动。
大概知道咋回事就行了,例子就不举了。
三、后记
我们很少直接使用ThreadPool,因为它有一些限制,比如你无法知道异步任务什么时候完成,也无法让异步操作返回值。而System.Threading.Tasks命名空间下的类型,能够解决这些技术问题,它建立在ThreadPool基础之上,仍然是使用CLR线程池。
*这是一个系列文章,将全面介绍多线程、用户态协程和单线程事件循环机制,建议收藏、点赞哦!
*你在并发编程过程中碰到了哪些难题?欢迎评论区交流~~~
我是functionMC > function MyClass(){…}
C#/TS/鸿蒙/AI等技术问题,以及如何写Bug、防脱发、送外卖等高深问题,都可以私信提问哦!