c# Thread、ThreadPool、Task区别

        已经好几天没坚持写文章了，每天都谴责一下自己，然后沉沉睡去，即将患上懒癌的人。

        今天在完成公司的一个项目过程中，需要用到异步编程，突然想起来，前段时间的面试，也考了这方面内容，当时回答的不知道怎么说，就是很粗浅，因为没有细细的研究过这几个异步编程的对象，昨天花费了半天时间对这几个对象进行了研究，看了多个文章，总结了一下前人的技术结晶：

基础概念

        根据我这段时间对异步编程的了解，以及之前的一点点技术积累，我觉得想要熟知异步编程，需要了解一下基本概念：

线程

        线程（Thread）是操作系统能够进行运算调度的最小单位。它是进程中的实际运作单位，一个进程中可以启动多个线程，每个线程可以并行执行不同的任务。严格意义上来说，同一时间可以并行运行的线程数取决于 CPU 的核数。

        根据线程运行模式，可以把线程分为前台线程、后台线程和守护（Daemon）线程

        每次开启一个新的线程都要消耗一定的内存，即使线程什么也不做，也会至少消耗 1M 左右的内存。

前台线程

        主程序必须等待线程执行完毕后才可退出程序。C# 中的 Thread 默认为前台线程，也可以设置为后台线程。

后台线程

        主程序执行完毕立即跟随退出，不管线程是否执行完毕。C# 的 ThreadPool 管理的线程默认为后台线程。

并行

        同一时刻有多条指令在多个处理器上同时执行，无论从宏观还是微观上都是同时发生的。

并发

        是指在同一时间段内，宏观上看多个指令看起来是同时执行，微观上看是多个指令进程在快速的切换执行，同一时刻可能只有一条指令被执行。

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 上的。