Task.Run与ThreadPool.QueueUserWorkItem

Question

不是主题专家我想了解更多.NET中可用的异步世界。 Task.Run和ThreadPool.QueueUserWorkItem都允许在池线程上调度工作，但有什么区别，或者如果你愿意，两者的优缺点是什么？ 以下是我的专业列表。不知道它是否完整或甚至是正确的。

ThreadPool.QueueUserWorkItem优点：

• 提供的CancellationToken等待任务完成的
• 可能性的可能性：
  • 传递参数

  Task.Run优点的可能性

• 可能性值返回到调用代码

Answer 1

ThreadPool.QueueUserWorkItem的只是做同样的工作作为Task.Run的老的实现（介绍.NET 1.1）（介绍了.NET 4.5）。

Microsoft试图避免在.NET中破坏向后兼容性。 为.NET 1.1编写的东西可以编译并在.NET 4.5中运行（通常）不做任何更改。 重大更改通常来自编译器更改，而非框架更改，如the variable declared in a foreach used inside a lambada behaving differently in C# 5 and newer。

当您有Task.Run时，没有真正的理由使用ThreadPool.QueueUserWorkItem。具有讽刺意味的是，事情实际上已经完全围绕着HostingEnvironment.QueueBackgroundWorkItem(...)。 它允许您在ASP.NET环境中的后台线程上运行某些内容，并通知网络服务器关闭AppDomain后台工作（在长时间不活动期间可能频繁发生）。

Answer 2

ThreadPool.QueueUserWorkItem和Task.Run之间的一个区别我最近意识到的是他们处理异常的方式。

如果在ThreadPool.QueueUserWorkItem内部发生未被注册的异常，而不是由全局异常处理程序处理，则会使父线程崩溃。另一方面，Task.Run线程的异常例外将不会传播，直到您await或Task.Wait。