5

我有一个ThreadPool.QueueUserWorkItem在几个地方使用的代码库。我认为从使用切换ThreadPool.QueueUserWorkItem到使用Task.Factory.StartNewwithTaskScheduler.Default作为调度程序是一个好主意。

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

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

所有日志记录操作都是在 ThreadPool 中启动的

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)

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

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

4

0 回答 0