我们有一些长期运行的业务流程，这些流程是通过在WS 2008 R2上以IIS（集成模式）运行的WCF服务启动的。这些业务流程通常涉及与SQL Server后端的大量交互。我们创建了一个自定义任务队列实现，通过初始服务调用将请求排队，然后根据优先级执行。此执行可能需要很长时间才能完成（极端20-30分钟）。然后，客户端可以向服务器查询其自己的后台任务的进度。
在我们当前的实现中，任务在一个单独的线程上触发，而不是从ThreadPool执行。这是因为reading recommendations未使用ThreadPool运行长时间运行的任务，以防止使ASP.NET请求无法提供服务。我们通过对可以同时执行的后台任务的数量设置上限来控制生成的线程数。这样我们就可以尝试控制CPU上的负载并防止过多的线程上下文切换。虽然所有这一切都在发生，但我们当然仍然需要为该应用程序提供正常的“在线”请求。
在阅读Thomas Marquardt的this post后，我担心我们没有使用ThreadPool，因为我们无法获得内置调优启发式的好处。我们已经通过挂钩ApplicationEnd事件并取消长时间运行的任务来解决关闭问题。所以我的问题是，我们应该切换到使用ThreadPool吗？这些线程被长时间捆绑了怎么办？如果我正确理解Thomas，他说这无关紧要，因为ThreadPool会调整自己以创建更多请求以服务于正常的在线操作？我也通过this StackOverflow question阅读了相同的理由，但我仍然不确定前进的方向。
答案 0 :(得分：1)
这不完全是您所要求的 - 但为什么不在一个单独的进程（比如说windows服务）中一起执行长时间运行的任务 - 无论如何构建优先级队列并且客户端将在一段时间内查询结果后来。我会采用这种方法，前端WCF服务将请求排队并响应状态更新查询，而后台服务将继续提供请求。这甚至允许工人进程回收等，而不用担心终止当前正在执行的任务。我看到的唯一问题是流程外通信的开销，但与任务所花费的时间（因为它们长时间运行）相比，它应该是微不足道的。
答案 1 :(得分：1)
我的建议是避免使用ThreadPool，因为我确实存在您提供的链接中建议的线程饥饿问题。
我们的产品允许用户启动对执行一系列报价的Web服务的调用。这可能是一个长达40分钟的长时间运行过程，报价过程是CPU密集型的，因此，我们使用四核服务器上的线程池来获得最大的CPU使用率。
但是，由于ASP.NET看起来好像它使用线程池来处理请求，因此我们遇到了一个问题，即由于池中缺少可用线程，用户提交的任何新作业永远不会开始，直到第一个作业完成。为了解决这个问题，我一直在使用我在网上找到的一个名为ThreadPoolThrottle的课程。这已经解决了一些问题，但随着系统使用的增加，我们遇到了同样的问题。
我现在正在考虑VinayC建议在程序中运行引号以防止我的asp.net应用程序中出现线程饥饿。