为什么使用多线程
1.使用户界面能够随时相应用户输入
当某个应用程序在进行大量运算时候，为了保证应用程序能够随时相应客户的输入，这个时候我们往往需要让大量运算和相应用户输入这两个行为在不同的线程中进行。
2.效率原因
应用程序经常需要等待一些资源，如等待网络资源，等待io资源，等待用户输入等等。这种情况下使用多线程可以避免CPU长时间处于闲置状态。
用户态，内核态
线程内的资源有两种运行态，即用户态和内核态。某些运算可以在堆栈上进行，这种情况线程是在用户态运行的，某些需要高权限运行的指令，或者某些优先级很高的指令需要在操作系统内核中进行，这个时候线程会运行在内核态。出于安全原因，用户态和内核态的资源是不能够互相访问的，因此在用户态和内核态的切换过程中，我们需要进行相关上下文以及变量的复制，这意味的用户态和内核态的切换是以一定的时间消耗为代价的。
由于CPU是以时间片为单位进行线程的切换的，由于CPU的运算速度远大于内存的读写速度，因此CPU和内存之间通常有两级缓存，不同的线程的上下文访问的数据往往是不同的，这样线程的切换需要经常频繁的切换CPU缓存的内容，也需要更新线程的调度信息，这些都是需要花费一定的时间的，因此合理的使用多线程，来避免CPU不停的进行上下文切换。
System.Thread介绍
创建一个线程
创建每一个线程的时候，CLR都需要进行一系列的操作，如初始化线程的本地资源，为线程分配用户模式和内核模式下相应的堆栈，加载相应的托管，非托管资源等。
最简单常用的创建线程的方式是使用ThreadStart来创建线程，相关代码如下：
ThreadStart只需要一个委托即可，如果你善于使用匿名方法，也可以用匿名方法来代替委托，使用匿名方法的另一个好处是可以通过匿名方法的闭包特性来为新的线程传递参数。
虽然使用匿名方法的闭包特性可以很方便的为线程传递参数，但是也往往会带来一些不容易发现的问题，如下面的程序，由于i变量的共享，在运行的时候输出会有问题：
正确的写法应该是这样的：
线程异常的捕获
如果线程中可能需要捕获异常，那么我们不能这样做：
而是这样做：
System.Thread线程的成员
System.Threading.Thread帮助我们实现了一些线程的基本操作，如：
| 属性名称 | 说明 |
| CurrentContext | 获取线程正在其中执行的当前上下文。 |
| CurrentThread | 获取当前正在运行的线程。 |
| ExecutionContext | 获取一个 ExecutionContext 对象，该对象包含有关当前线程的各种上下文的信息。 |
| IsAlive | 获取一个值，该值指示当前线程的执行状态。 |
| IsBackground | 获取或设置一个值，该值指示某个线程是否为后台线程。 |
| IsThreadPoolThread | 获取一个值，该值指示线程是否属于托管线程池。 |
| ManagedThreadId | 获取当前托管线程的唯一标识符。 |
| Name | 获取或设置线程的名称。 |
| Priority | 获取或设置一个值，该值指示线程的调度优先级。 |
| ThreadState | 获取一个值，该值包含当前线程的状态。 |
| 方法名称 | 说明 |
| Abort() | 终止本线程。 |
| GetDomain() | 返回当前线程正在其中运行的当前域。 |
| GetDomainId() | 返回当前线程正在其中运行的当前域Id。 |
| Interrupt() | 中断处于 WaitSleepJoin 线程状态的线程。 |
| Join() | 已重载。阻塞调用线程，直到某个线程终止时为止。 |
| Resume() | 继续运行已挂起的线程。 |
| Start() | 执行本线程。 |
| Suspend() | 挂起当前线程，如果当前线程已属于挂起状态则此不起作用 |
| Sleep() | 把正在运行的线程挂起一段时间。 |
前台线程vs后台线程
这里我们单独提一下前台线程和后台线程。在CLR中，线程分为前台线程和后台线程，当所有前台的线程执行完之后，CLR会强制结束所有正在运行的后台线程，并且不会出现任何异常。
因此你应该使用前台线程来做一些必须完成的任务，比如把流从内存中写到磁盘上。后台线程可以做一些不那么重要的事情。一旦线程对象的生命周期开始，你就不能修改IsBackground值。
由于线程是非常昂贵的资源，我们经常需要控制允许多少线程同时运行，如何控制线程的生命周期，如何管理线程，这里我们引入了线程池的概念。
.NET 中的多线程 线程池
由于线程的创建，销毁都是需要耗费大量资源和时间的，开发者应该非常节约的使用线程资源。最好的办法是使用线程池，线程池能够避免当前进行中大量的线程导致操作系统不停的进行线程切换，当线程数量到达了我们设置的上限，线程会自动排队等待，当线程资源可用时，队列中的线程任务会依次执行，如果没有排队等候的资源，线程会变为闲置状态。
使用ThreadPool来访问线程池
这种做法可以让我们不用那么复杂的去实现创建，重用线程的逻辑，但是也有一些限制，比如由他内置的方法，我们不知道什么时候线程池里面的任务会结束，也不能获取线程的返回值。为了解决这些问题，微软引入了一个新的概念。
使用Task来访问线程池
引入了Task之后，你可以用如下实现来替代ThreadPool
这些实现都是等价的。Task本身实现了很多ThreadPool不能做的事情。
使用Task来获得线程的返回值
使用Task来等待线程结束
更多Task同步编程的使用，请参见(还没写，先给自己挖个坑O(∩_∩)O)。
异步委托
ThreadPool.QueueUserWorkItem没有提供一种简单的机制来获取线程的返回值。异步委托解决了这个问题，支持了传入一系列的参数。此外，异步委托中没有处理的异常会很方便的在调用线程的重新抛出(在调用EndInvoke的时候)，因此不需要显示的处理。
通过异步委托来执行任务主要分一下几步：
初始化并声明一个你想要执行的委托
在委托上调用BeginInvoke，把返回值保存为IAsyncResult中
调用BeginInvoke不会阻塞当前线程，因此你可以在调用完之后执行其他你想要同步的操作
当你需要获取委托的返回值时，调用EndInvoke方法，把IAsyncResult传入EndInvoke中
阻塞的方式执行异步委托
EndInvoke主要做3件事： 1. 等待异步委托完成 2. 接收返回值 3. 把异步线程中未处理的异常在当前线程中重新抛出。
非阻塞的方式执行异步委托
你也可以在调用BeginInvoke的时候指定一个回调方法，这个方法会在异步委托结束的时候自动调用。这样异步委托就像是一个后台线程一样自动执行，不需要主线程等待。只需要在BeginInvoke的时候做一些额外的操作即可实现这种操作。
关于线程池
Jeffery在C# via CLR
Chapter27中针对线程池的使用给出了一些建议。目前我们允许开发者来指定一个线程池的最大线程数。但是事实证明，我们往往不应该为一个线程池指定线程的上限，否则可能会出现程序死锁或者饿死的状态。比如你可能设置了1000个线程，但是某一时刻正好有第1001个线程需要等待所有线程结束才能执行，这种情况如果你限制了线程池线程的个数，就会出现死锁。从开发的另一个角度说，你也不应该限制一个进程使用多少资源，比如一个进程可以使用多少内存，使用多少带宽.因此虽然目前你可以通过GetMaxThreads，
SetMaxThreads，GetMinThreads，SetMinThreads
，GetAvailableThreads来进行线程个数的限制，但是他仍然不建议大家这样做。这些限制可能会让你的程序运行的更慢。