线程作用及开销
早期计算机一次只能运行一个程序，长时间执行程序容易出现计算机“瘫痪”的问题，如果程序进入死循环则只能重启系统。即使计算机不崩溃，也难免让用户崩溃。为了解决这个问题，操作系统设计者设计出了进程的概念，使得每个应用程序运行在一个虚拟的内存空间中。进程中又包含多个线程，CPU则根据操作系统调度执行每个进程中的线程任务。通过线程这种对CPU的虚拟化管理方式，操作系统形成了多任务执行的机制。但与一切虚拟化机制一样，线程会产生空间和时间的开销。这其中的开销包括：
1、线程内核对象。该数据结构中包含线程上下文。Windows在x86架构CPU上为每个线程内核对象分配的空间大约为700字节，x64和IA64架构CPU分别为大约1240字节和2500字节。
2、线程环境块。占用一个内存页，包含线程的异常处理链首。当线程进入try块时，在链首插入一个节点，在线程对出退出try块时，删除该节点。另外线程环境块中还包括一些其他的本地储蓄数据。
3、用户模式栈。用户存储传给方法的局部变量和实参；还包含一个地址，指出当方法返回时，线程应该从什么地方开始接着执行。默认情况下每个线程的用户模式栈分配1MB内存。
4、内核模式栈。记录用户程序调用内核模式函数时函数的实参。32位系统分配12KB内存，64位系统则分配24KB。
5、DLL线程连接和线程分离通知。进程中每创建和终止一个线程时，都会调用进程中加载的所有DLL的DllMain方法。
6、上下文切换。对单CPU计算机来说，操作系统每次只将一个线程分配给CPU执行，执行完后将线程上下文数据记录下来保存在线程内核对象结构中；然后装载另一个线程的上下文，将CPU执行控制交给此线程，如果该线程有另一个进程拥有，那么在装载该线程之前，Windows还必须使得CPU能够处理该虚拟地址空间。Windows操作系统为各个线程每次分配大概30毫秒的执行时间，称为“时间片”。上下文切换是净开销，不会换来任何在存储空间或者性能上的收益。但是能向用户提供一个健壮的能灵活相应的操作系统。
空间开销测试
测试代码：
复制代码 代码如下:
static void Main(string[] args)
{
ListThread> threadList = new ListThread>();
for (int i = 0; i 1000; i++)
{
Thread thread = new Thread(
new ParameterizedThreadStart(o => { Console.WriteLine("第{0}线程", o); Thread.Sleep(100000); })
);
threadList.Add(thread);
}
Console.ReadLine();
for (int i = 0; i threadList.Count; i++)
{
threadList[i].Start(i);
}
Console.ReadLine();
}
pslist的观测结果结果：
程序开始运行时
所有线程Start以后
1000个线程Start以后虚拟物理内存占用量增加了31MB,而虚拟内存增加了1000MB之多。
线程池
由于专用线程（实例化Thread类所创建的线程）存在的巨大内存和性能开销，CRL被设计出支持线程池技术，为应用程序提供线程管理。每个CLR独立维护一个自己的线程池，CLR在线程池中只建立必要的线程供给应用程序使用，在应用程序把多个任务分配给线程池后，CLR将任务轮流分配给线程池中线程来执行，当任务执行完毕后，线程池中的线程并不会回收，而是等待分配新的任务。这就能有效的减少线程的数量，并且减少了线程创建时的性能开销（线程池相关的内容笔者正在整理之中，后续会陆续发布）。另外，对于Thread类有一个实例属性IsBackground指示线程是前台还是后台运行，前台线程指线程所在进程关闭时，进程需要等待线程执行完成才能关闭，后台进程指当进程关闭时，线程立即停止执行，不会等待执行完成既退出运行。该属性默认值为True，即专用线程默认为前台线程。
进程、AppDomain和线程
这里涉及到进程，AppDomain和线程，我觉得有必要把这三个概念放一起做一个大体的比对。
1、进程是操作系统为应用程序虚拟的执行地址空间，应用程序中的所有数据都装载在相互独立的进程中运行。
2、AppDomain是.NET托管应用装载的内部相互隔离的托管执行空间。如：IIS进程中所有的Web应用都运行在独立的AppDomain中。
3、线程是应用程序内部虚拟化的CPU执行单元，操作系统对内存中所有应用程序进程中的线程进行调度，交给CPU进行执行。
进程是一个虚拟的地址空间，操作系统不会对其进行调度而是调度执行其中包含的线程。CLR在AppDomain内部也有自己的运行线程，AppDomain中的线程由CLR维护，但最终CLR仍需将AppDomain中的线程映射为应用程序进程中的线程，交给操作系统进行调度。并且AppDomain中的线程不一定与操作系统线程完全一一对应。
下图是大体描述进程、AppDomain和线程的关系，以及操作系统对线程的调度。详细内容本文不做进一步说明。
线程优先级
线程调度根据线程优先级进行，Windows将系统内的线程分为0至31，共32个等级，优先级为31的线程是最高优先级线程，最先得到执行权限。例如，一个优先级为8的线程正在执行，而此刻操作系统确认一个优先级为31的线程已经做好了执行准备，那么操作系统会立刻挂起正在执行的线程，把CPU的执行权限交给优先级为31的线程，即使优先级为8的线程还没有执行完一个完整的时间片，优先级为31的线程将获得一个完整的时间片，如果该线程执行完后操作系统发现还有优先级为31的线程准备执行，那么CPU执行权限将分给这个线程，前面优先级为8的线程始终得不到执行，这种情况称为饥饿。
如果开发人员没有合理的设置自己程序内的线程优先级，就可能会造成其他应用程序很难得到执行，甚至影响计算机响应速度。所以Windows又设计了一个进程优先级类来控制各个进程中的线程优先级的关系，进程优先级是一个虚拟的概念，因为操作系统不会对进程进行调度，这个概念只是为了控制进程中线程优先级的范围。进程优先级有6个级别（详见下表），根据进程优先级类，应用程序对内部线程设置相对优先级，会得到一个操作系统调度的线程优先级值。这样，使线程优先级能得到有效控制。
|
线程相对
优先级 |
进程优先级类 |
|
Idle |
Below Normal |
Normal |
Above Normal |
High |
Real-Time |
|
Time-critical |
15 |
15 |
15 |
15 |
15 |
31 |
|
Highest |
6 |
8 |
10 |
12 |
15 |
26 |
|
Above normal |
5 |
7 |
9 |
11 |
14 |
25 |
|
Normal |
4 |
6 |
8 |
10 |
13 |
24 |
|
Below normal |
3 |
5 |
7 |
9 |
12 |
23 |
|
Lowest |
2 |
4 |
6 |
8 |
11 |
22 |
|
Idle |
1 |
1 |
1 |
1 |
1 |
16 |
|
|
