c# - 在 ASP.NET 中使用线程是否有任何不明显的危险？

Question

这是 this programmers question 的同级问题.

简而言之，我们正在考虑将一些依赖用户请求的工作“适本地”推到后台。链接的问题给了我很多关于我们应该走服务路线的想法，但并没有真正提供任何令人信服的论据来说明为什么我们应该这样做。

我承认，对我来说，做道德等价物的能力

WorkQueue.Push(delegate(object context) { ... });

真的很吸引人，所以如果它只是有点困难(而不是本质上不可行)，我倾向于采用后台线程方法。

所以，我知道的后台线程问题(在 AppPool 的上下文中):

• 由于 AppPool 被回收，他们随时可能死亡
  • 解决方案:跟踪任务何时执行，以便在需要新线程时重新运行*
• ThreadPool用于响应传入的 HTTP 查询，因此使用它会使 IIS 饿死
  • 解决方案:构建我们自己的线程池，同时限制线程数。

我的问题是，我错过了什么？ASP.NET 中的后台线程还有什么问题？

_{* 问题中的任务已经可以安全地重新运行，所以这不是问题。
ǂ 假设我们没有做任何真正愚蠢的事情，比如在后台线程中抛出异常。}

Answer 1

我不会在您的 IIS AppDomain 中为 StackOverflow 启动线程。我没有任何确凿的证据来支持我要说的话，但是使用 IIS 10 年，我知道当它是唯一的游戏时，它的效果最好。

还有一个替代方案，我知道这会是一个 take off on my answer在程序员线程上。但据我了解，您已经有了一个解决方案，可以通过搭载用户请求的工作来工作。为什么不使用该代码，而是仅在调用特殊的内部 API 时启动它。然后使用 Task Scheduler 调用 CURL 命令，该命令每 30 秒左右调用一次该 API 以启动任务。这样您就可以让 IIS 处理线程，而您的代码正在处理它已经很容易完成的事情。