一些基础概念
线程（Thread）是操作系统能够进行运算调度的最小单位。它是进程中的实际运作单位，一个进程中可以启动多个线程，每个线程可以并行执行不同的任务。严格意义上来说，同一时间可以并行运行的线程数取决于 CPU 的核数。
根据线程运行模式，可以把线程分为前台线程、后台线程和守护（Daemon）线程：
-
前台线程：主程序必须等待线程执行完毕后才可退出程序。C# 中的 Thread 默认为前台线程，也可以设置为后台线程。
-
后台线程：主程序执行完毕立即跟随退出，不管线程是否执行完毕。C# 的 ThreadPool 管理的线程默认为后台线程。
-
守护线程：守护线程拥有自动结束自己生命周期的特点，它通常被用来执行一些后台任务。
每次开启一个新的线程都要消耗一定的内存，即使线程什么也不做，也会至少消耗 1M 左右的内存。
多线程并行（Parallelism）和并发（Concurrency）的区别：
- 并行：同一时刻有多条指令在多个处理器上同时执行，无论从宏观还是微观上都是同时发生的。
- 并发：是指在同一时间段内，宏观上看多个指令看起来是同时执行，微观上看是多个指令进程在快速的切换执行，同一时刻可能只有一条指令被执行。
PS：以上概念来源 Google 的多个搜索结果，稍加整理。
Thread、ThreadPool 和 Task
对 C# 开发者来说，不可不理解清楚 Thread、ThreadPool 和 Task 这三个概念。这也是面试频率很高的话题，在 StackOverflow 可以找到有很多不错的回答，我总结整理了一下。
Thread
Thread 是一个实际的操作系统级别的线程（OS 线程），有自己的栈和内核资源。Thread 允许最高程度的控制，你可以 Abort、Suspend 或 Resume 一个线程，你还可以监听它的状态，设置它的堆栈大小和 Culture 等属性。Thread 的开销成本很高，你的每一个线程都会为它的堆栈消耗相对较多的内存，并且在线程之间的处理器上下文切换时会增加额外的 CPU 开销。
ThreadPool
ThreadPool（线程池）是一堆线程的包装器，由 CLR 维护。你对线程池中的线程没有任何控制权，你甚至无法知道线程池什么时候开始执行你提交的任务，你只能控制线程池的大小。简单来说，线程池调用线程的机制是，它首先调用已创建的空闲线程来执行你的任务，如果当前没有空闲线程，可能会创建新线程，也可能会等待。
使用 ThreadPool 可以避免创建太多线程的开销。但是，如果你向 ThreadPool 提交了太多长时间运行的任务，它可能会被填满，这时你提交的后面的任务可能最终会等待前面的长时间运行的任务执行完成。此外，线程池没有提供任何方法来检测一个工作任务何时完成（不像 Thread.Join()），也没有方法来获取结果。因此，ThreadPool 最好用于调用者不需要结果的短时操作。
Task
Task 是 TPL（Task Parallel Library）提供一个类，它在 Thread 和 TheadPool 之间提供了两全其美的解决方案。和 ThreadPool 一样，Task 并不创建自己的OS 线程。相反，Task 是由 TaskScheduler 调度器执行的，默认的调度器只是在 ThreadPool 上运行。
与 ThreadPool 不同的是，Task 还允许你知道它完成的时间，并获取返回一个结果。你可以在现有的 Task 上调用 ContinueWith()，使它在任务完成后运行更多的代码（如果它已经完成，就会立即运行回调）。
你也可以通过调用 Wait() 来同步等待一个任务的完成（或者，通过获取它的 Result 属性）。与 Thread.Join() 一样，这将阻塞调用线程，直到任务完成。通常不建议同步等待任务执行完成，它使调用线程无法进行任何其他工作。如果当前线程要等待其它线程任务执行完成，建议使用 async/await 异步等待，这样当前线程可以空闲出来去处理其它任务，比如在 await Task.Delay() 时，并不占用线程资源。
由于任务仍然在 ThreadPool 上运行，因此不应该将其用于长时任务的执行，因为它们会填满线程池并阻塞新的工作任务。相反，Task 提供了一个 LongRunning 选项，它将告诉 TaskScheduler 启用一个新的线程，而不是在 ThreadPool 上运行。
所有较新的上层多线程 API，包括 Parallel.ForEach()、PLINQ、async/await 等，都是建立在 Task 上的。
Thread 和 Task 简单示例
下面通过一个简单示例演示 Thread 和 Task 的使用，注意他们是如何创建、传参、执行和等待执行完成的。
static void Main(string[] args)
{
// 创建两个新的 Thread
var thread1 = new Thread(new ThreadStart(() => PerformAction("Thread", 1)));
var thread2 = new Thread(new ThreadStart(() => PerformAction("Thread", 2)));
// 开始执行线程任务
thread1.Start();
thread2.Start();
// 等待两个线程执行完成
thread1.Join();
thread2.Join();
Console.WriteLine("Theads done!");
Console.WriteLine("===我是分隔线===");
// 创建两个新的 Task
var task1 = Task.Run(() => PerformAction("Task", 1));
var task2 = Task.Run(() => PerformAction("Task", 2));
// 执行并等待两个 Task 执行完成
Task.WaitAll(new[] { task1, task2 });
Console.WriteLine("Tasks done!");
Console.ReadKey();
}
static void PerformAction(string threadOrTask, int id)
{
var rnd = new Random(id);
for (int i = 0; i < 5; i++)
{
Console.WriteLine($"{threadOrTask}: {id}: {i}", id, i);
Thread.Sleep(rnd.Next(0, 1000));
}
}
运行效果：
注意到，相比之下 Task 比 Thread 好用得多，加上前文 Task 和 Thread 的对比，对我们编码的指导意义是：大多数情况我们应该使用 Task，而不要直接使用 Thread，除非你明确知道你需要一个独立的线程来执行一个长耗时的任务。
避免多线程同时读写共享数据
在实际开发中，难免会遇到多线程读写共享数据的需求。比如在某个业务处理时，先获取共享数据（比如是一个计数），再利用共享数据进行某些计算和业务处理，最后把共享数据修改为一个新的值。由于是多个线程同时操作，某个线程取得共享数据后，紧接着共享数据可能又被其它线程修改了，那么这个线程取得的数据就是错误的旧数据。我们来看一个具体代码示例：
static int count { get; set; }
static void Main(string[] args)
{
for (int i = 1; i <= 2; i++)
{
var thread = new Thread(ThreadMethod);
thread.Start(i);
Thread.Sleep(500);
}
}
static void ThreadMethod(object threadNo)
{
while (true)
{
var temp = count;
Console.WriteLine("线程 " + threadNo + " 读取计数");
Thread.Sleep(1000); // 模拟耗时工作
count = temp + 1;
Console.WriteLine("线程 " + threadNo + " 已将计数增加至: " + count);
Thread.Sleep(1000);
}
}
示例中开启了两个独立的线程开始工作并计数，假使当 ThreadMethod 被执行第 4 次的时候（即此刻 count 值应为 4），count 值的变化过程应该是：1、2、3、4，而实际运行时计数的的变化却是：1、1、2、2...。也就是说，除了第一次，后面每次，两个线程读取到的计数都是旧的错误数据，这个错误数据我们把它叫作脏数据。
因此，对共享数据进行读写时，应视其为独占资源，进行排它访问，避免同时读写。在一个线程对其进行读写时，其它线程必须等待。避免同时读写共享数据最简单的方法就是加锁。
修改一下示例，对 count 加锁：
static int count { get; set; }
static readonly object key = new object();
static void Main(string[] args)
{
...
}
static void ThreadMethod(object threadNumber)
{
while (true)
{
lock(key)
{
var temp = count;
...
count = temp + 1;
...
}
Thread.Sleep(1000);
}
}
这样就保证了同时只能有一个线程对共享数据进行读写，避免出现脏数据。
死锁的发生
上面为了解决多线程同时读写共享数据问题，引入了锁。但如果同一个线程需要在一个任务内占用多个独占资源，这又会带来新的问题：死锁。简单来说，当线程在请求独占资源得不到满足而等待时，又不释放已占有资源，就会出现死锁。死锁就是多个线程同时彼此循环等待，都等着另一方释放其占有的资源给自己用，你等我，我待你，你我永远都处在彼此等待的状态，陷入僵局。下面用示例演示死锁是如何发生的：
class Program
{
static void Main(string[] args)
{
var workers = new Workers();
workers.StartThreads();
var output = workers.GetResult();
Console.WriteLine(output);
}
}
class Workers
{
Thread thread1, thread2;
object resourceA = new object();
object resourceB = new object();
string output;
public void StartThreads()
{
thread1 = new Thread(Thread1DoWork);
thread2 = new Thread(Thread2DoWork);
thread1.Start();
thread2.Start();
}
public string GetResult()
{
thread1.Join();
thread2.Join();
return output;
}
public void Thread1DoWork()
{
lock (resourceA)
{
Thread.Sleep(100);
lock (resourceB)
{
output += "T1#";
}
}
}
public void Thread2DoWork()
{
lock (resourceB)
{
Thread.Sleep(100);
lock (resourceA)
{
output += "T2#";
}
}
}
}
示例运行后永远没有输出结果，发生了死锁。线程 1 工作时锁定了资源 A，期间需要锁定使用资源 B；但此时资源 B 被线程 2 独占，恰巧资线程 2 此时又在待资源 A 被释放；而资源 A 又被线程 1 占用......，如此，双方陷入了永远的循环等待中。
死锁的避免
针对以上出现死锁的情况，要避免死锁，可以使用 Monitor.TryEnter(obj, timeout) 方法来检查某个对象是否被占用。这个方法尝试获取指定对象的独占权限，如果 timeout 时间内依然不能获得该对象的访问权，则主动“屈服”，调用 Thread.Yield() 方法把该线程已占用的其它资源交还给 CUP，这样其它等待该资源的线程就可以继续执行了。即，线程在请求独占资源得不到满足时，主动作出让步，避免造成死锁。
把上面示例代码的 Workers 类的 Thread1DoWork 方法使用 Monitor.TryEnter 修改一下：
// ...（省略相同代码）
public void Thread1DoWork()
{
bool mustDoWork = true;
while (mustDoWork)
{
lock (resourceA)
{
Thread.Sleep(100);
if (Monitor.TryEnter(resourceB, 0))
{
output += "T1#";
mustDoWork = false;
Monitor.Exit(resourceB);
}
}
if (mustDoWork) Thread.Yield();
}
}
public void Thread2DoWork()
{
lock (resourceB)
{
Thread.Sleep(100);
lock (resourceA)
{
output += "T2#";
}
}
}
再次运行示例，程序正常输出 T2#T1# 并正常结束，解决了死锁问题。
注意，这个解决方法依赖于线程 2 对其所需的独占资源的固执占有和线程 1 愿意“屈服”作出让步，让线程 2 总是优先执行。同时注意，线程 1 在锁定 resourceA 后，由于争夺不到 resourceB，作出了让步，把已占有的 resourceA 释放掉后，就必须等线程 2 使用完 resourceA 重新锁定 resourceA 再重做工作。
正因为线程 2 总是优先，所以，如果线程 2 占用 resourceA 或 resourceB 的频率非常高（比如外面再嵌套一个类似 while(true) 的循环 ），那么就可能导致线程 1 一直无法获得所需要的资源，这种现象叫线程饥饿，是由高优先级线程吞噬低优先级线程 CPU 执行时间的原因造成的。线程饥饿除了这种的原因，还有可能是线程在等待一个本身也处于永久等待完成的任务。
我们可以继续开个脑洞，上面示例中，如果线程 2 也愿意让步，会出现什么情况呢？
活锁的发生和避免
我们把上面示例改造一下，使线程 2 也愿意让步：
public void Thread1DoWork()
{
bool mustDoWork = true;
Thread.Sleep(100);
while (mustDoWork)
{
lock (resourceA)
{
Console.WriteLine("T1 重做");
Thread.Sleep(1000);
if (Monitor.TryEnter(resourceB, 0))
{
output += "T1#";
mustDoWork = false;
Monitor.Exit(resourceB);
}
}
if (mustDoWork) Thread.Yield();
}
}
public void Thread2DoWork()
{
bool mustDoWork = true;
Thread.Sleep(100);
while (mustDoWork)
{
lock (resourceB)
{
Console.WriteLine("T2 重做");
Thread.Sleep(1100);
if (Monitor.TryEnter(resourceA, 0))
{
output += "T2#";
mustDoWork = false;
Monitor.Exit(resourceB);
}
}
if (mustDoWork) Thread.Yield();
}
}
注意，为了使我要演示的效果更明显，我把两个线程的 Thread.Sleep 时间拉开了一点点。运行后的效果如下：
通过观察运行效果，我们发现线程 1 和线程 2 一直在相互让步，然后不断重新开始。两个线程都无法进入 Monitor.TryEnter 代码块，虽然都在运行，但却没有真正地干活。
我们把这种线程一直处于运行状态但其任务却一直无法进展的现象称为活锁。活锁和死锁的区别在于，处于活锁的线程是运行状态，而处于死锁的线程表现为等待；活锁有可能自行解开，死锁则不能。
要避免活锁，就要合理预估各线程对独占资源的占用时间，并合理安排任务调用时间间隔，要格外小心。现实中，这种业务场景很少见。示例中这种复杂的资源占用逻辑，很容易把人搞蒙，而且极不容易维护。推荐的做法是使用信号量机制代替锁，这是另外一个话题，后面单独写文章讲。
总结
我们应该避免多线程同时读写共享数据，避免的方式，最简单的就是加锁，把共享数据作为独占资源来进行排它使用。
多个线程在一次任务中需要对多个独占资源加锁时，就可能因相互循环等待而出现死锁。要避免死锁，就至少得有一个线程作出让步。即，在发现自己需要的资源得不到满足时，就要主动释放已占有的资源，以让别的线程可以顺利执行完成。
大部分情况安排一个线程让步便可避免死锁，但在复杂业务中可能会有多个线程互相让步的情况造成活锁。为了避免活锁，需要合理安排线程任务调用的时间间隔，而这会使得业务代码变得非常复杂。更好的做法是放弃使用锁，而换成使用信号量机制来实现对资源的独占访问。
本篇内容很基础，整理了 C# 线程编程有关的重要概念，简单演示了 Thread 和 Task 的使用。Thread 和 Task 是高频面试话题，尤其是 Thread 和 Task 的区别，Thread 更底层，Task 更抽象，回答好这类面试题的关键点在 ThreadPool。
下一篇将继续讲解关于线程的话题，敬请期待！
作者：精致码农