Task和Thread有什么区别？
今天我正在挖掘TPL并找到了一个新的Task.Now我只是想知道task和Thread之间的差异是什么，哪个更好？
任务和线程之间的差异是什么？
假设您正在经营一家图书传递公司。 你有四辆车和四个司机。 汽车是一个线程，一个驱动程序是一个处理器，一个书籍交付是一项任务。 您面临的问题是如何有效地安排驾驶员和汽车，以便尽快完成任务。
事情变得奇怪的是当汽车（线程）多于驱动程序（处理器）时。 然后发生的事情就是驾驶员停放一辆汽车（暂停线程）并进入另一辆汽车（开关环境）的行程中途，驾驶一辆车执行任务一段时间，然后最终回到第一辆汽车。 显然，这并不像一辆车停在一辆车里那么高效。
基于任务的并行性的想法是将工作分解为可以在将来产生结果的 小任务，然后有效地分配与处理器一样多的线程，这样您就不会浪费时间上下文切换。 在实践中，它通常不能很好地解决，但这就是想法。
哪一个更好，任务还是线程？
这个问题无法回答，因为它没有任何意义。 哪个更好，是一本交付给客户的书，还是一辆提供给它的汽车？ 汽车是一种可以用来送书的设备; 这两件事并不是你能明智地描述为比另一件更“好”或“更差”的东西。 这就像问“哪个更好，一个洞或一个钻头？”
“任务”是一项将在未来的某个时刻执行并完成的工作。
“线程”是指某事被执行的方式。
通常，当您创建一个Task时，默认情况下（即：使用Task.Factory.StartNew ）， Task将在某个时刻获得Scheduled以在ThreadPool线程上运行。 但是，并非总是如此。
实现这种分离的好处是，您允许框架（或者您自己，如果使用自定义TaskScheduler ）来控制工作如何映射到可用线程。 通常，您将拥有比线程更多的工作项 – 您可能需要处理一百万个项目，但系统中只有8个核心。 在这种情况下，使用固定数量的线程并使每个线程处理多个工作项更有效。 通过将“任务”与“线程”分开，您将打破这种工作==线程的耦合。
一般来说，我建议使用Task而不是创建自己的线程。 这是一个更好，更强大，更灵活的模型，可用于开发，特别是因为它允许您以非常干净的方式处理exception，允许生成诸如continuation之类的好东西等。
以下是一些差异：
- 默认情况下，
Task使用线程池，而直接使用Thread则需要创建新线程。 -
Task将处理exception和结果，因此更容易使用它。 -
Task可以在使用线程时支持取消，您必须自己实现它。
任务是指您想要执行的操作或工作。
线程可以是工作的执行者或工作者执行者之一。
根据MSDN参考文档 ：
任务并行库（TPL）是.NET Framework版本4中System.Threading和System.Threading.Tasks名称空间中的一组公共类型和API .TPL的目的是通过简化过程使开发人员更高效向应用程序添加并行性和并发性。 TPL动态地扩展并发度，以最有效地使用所有可用的处理器。 此外，TPL处理工作的分区，ThreadPool上的线程调度，取消支持，状态管理和其他低级细节。 通过使用TPL，您可以最大限度地提高代码的性能，同时专注于您的程序旨在完成的工作。
因此，似乎Task是编码异步操作的首选方法，因为框架会处理大部分工作。 但另一方面， Thread仍可用于现有代码以及您明确要分配和管理OS线程的情况。