C# ThreadPool.QueueUserWorkItem和Task.Factory.StartNew之间的性能差异

我在几个地方使用

ThreadPool.QueueUserWorkItem

建立了一个代码库。我认为从使用

ThreadPool.QueueUserWorkItem

切换到使用

Task.Factory.StartNew

和

TaskScheduler.Default

作为调度器是个好主意

升级后，我看到应用程序的执行时间达到了天价。它作为一个在线跨国应用程序，接收请求并通常在40到500毫秒之间响应，这是可以接受的。切换到Tasks方式后，我看到许多事务需要从4000ms到38000ms才能响应，这是不可接受的

流程相当复杂。它涉及到传入事务的同步循环，它实际上执行简单的验证并插入到数据库中。之后，一些并行操作被激发，主循环继续到下一个传入事务。并行操作主要是日志记录和数据的db密集型质量检查

所有日志记录操作都是在线程池中启动的

ThreadPool.QueueUserWorkItem(/*logging action*/)

质量检查行动由以下人员启动：

Task.Factory.StartNew(/*qc action*/,
     TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness)

应用更改后 日志记录操作已切换到

Task.Factory.StartNew(/*logging action*/,
     CancellationToken.None,
     TaskCreationOptions.None,
     TaskScheduler.Default)

Task.Factory.StartNew(/*qc action*/,
     CancellationToken.None,
     TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness,
     TaskScheduler.Default)

质量检查动作被切换到

Task.Factory.StartNew(/*logging action*/,
     CancellationToken.None,
     TaskCreationOptions.None,
     TaskScheduler.Default)

Task.Factory.StartNew(/*qc action*/,
     CancellationToken.None,
     TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness,
     TaskScheduler.Default)

在ThreadPoolScheduler（TaskScheduler.Default）上使用Task.Factory.StartNew执行时，日志记录操作是否可能会暂停质量检查操作，但在使用QueueUserWorkItem直接在ThreadPool上执行时，它们不会

---

质量检查操作中的

TaskCreationOptions.PreferFairity

标志是否可能使质量检查等待日志记录操作，即使在其启动中未设置此标志？

性能差异不重要（且可以忽略）。遇到的任何差异都可能是由代码的其余部分引起的。最大的区别在于，直接使用线程池可以防止您编写异步操作、使用任何类型的缓冲等。您可能应该看看ActionBlockPS。看来有人错过了上次.NET会议，我们在会上讨论了这个话题。任务也使用线程池。4-38秒的延迟可能是由文件上的锁引起的。最后，不再支持或需要.NET 4.0，因为唯一需要它的操作系统（XP）也不受支持。事实上，考虑到所有支付和大多数其他web服务提供商都需要TLS1.1，.NET 4.5.2是最低要求requirement@PanagiotisKanavos请注意，如果使用

TaskCreationOptions.LongRunning

，则当前实现将为任务创建一个新线程，而不是使用线程池线程。