在 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 处理线程，而您的代码正在处理它已经很容易完成的事情。

Answer 2

我个人遇到的一个危险是 CallContext。我们使用 CallContext 设置用户身份数据，因为在我们的 Web 应用程序和基于 .NET Remoting 的应用程序服务（旨在使用 CallContext 存储呼叫特定数据）之间共享相同的代码 - 所以我们没有使用HttpContext。

我们注意到，有时，新请求会在 CallContext 中以非空身份结束。换句话说，ASP .NET 不会在请求之间清除存储在 CallContext 中的数据......因此，如果未经身份验证的用户选择了一个仍然具有包含经过验证的用户身份信息的 CallContext 的线程，则他们可能会进入应用程序。

Answer 3

让我告诉你一个不明显的危险:)

我使用线程将一些 RSS 提要更新到我的数据库中，用于我使用 GoDaddy 托管的网站。线程工作正常（如果它们被终止，由于我在某些网页中建立了一些检查，它们会自动重新启动）。

它运行良好，我很高兴，直到 GoDaddy（当时我的主机）首先开始杀死线程，然后完全阻止它们。所以我的应用就死了！

如果这不是不明显的，那是什么？

Answer 4

其中一个原因可能是您将架构过度复杂化而没有任何好处。

您的程序编写成本更高，维护成本更高，并且更有可能出现错误。