我可以在 ASP.NET MVC 中安全地生成线程吗？答案

【问题标题】：Can I safely spawn threads in ASP.NET MVC?我可以在 ASP.NET MVC 中安全地生成线程吗？
【发布时间】：2010-10-26 12:03:24
【问题描述】：

我有一个计划任务需要通过浏览页面来启动，我的虚拟主机不允许我使用 Windows 调度程序。

此任务执行的一项工作是从一堆其他网站获取一些数据，因为网络请求可能很慢，我已将任务设置为使用线程。

从 mvc 操作运行此任务似乎会导致整个网络服务器变得古怪，使其拒绝加载更多页面。

从网络应用程序中使用线程是不是很糟糕？有没有办法让我安全地做到这一点？有哪些线程限制？我真的只需要知道更多信息吗？

编辑：子问题

如果我使用线程池中的线程（由 ASP.NET 运行时使用（感谢 Anton），我可以限制它可以使用的线程数吗？什么是 ASP.NET线程池大小限制？

有一个单独的站点会更好吗？也许是一个包含单独 ASP.NET 应用程序的虚拟文件夹？那会阻止我限制线程池吗？

【问题讨论】：

【解决方案1】：

在处理传入请求时，ASP.NET 运行时从容量有限的 .NET ThreadPool 获取线程。因此，如果您使用该线程池中的线程，这可能会损害您的应用程序的可扩展性。

解决这个问题的方法是生成一个通常的Thread，但是当你的 AppPool 被回收时，这些可以被杀死。

【讨论】：

我想你刚刚解决了我的问题。因为我是从命令行运行它，所以我正在更改线程池大小。这似乎是导致它倒下的原因。然后是子问题：我可以限制它使用的线程池中的线程数吗？
对不起，写得不好。我的任务曾经被封装在一个控制台应用程序中，供我按需手动执行。它运行没有问题，当我从网站执行它时才开始引起问题。当你提到线程池大小时，你激发了我的记忆。
好吧，如果是控制台应用程序，它会在单独的进程中执行。由于 ThreadPools 是每个进程的，所以理论上这个应用程序不应该影响您网站的 ThreadPool。罪魁祸首可能在别处。
是的，这就是为什么到目前为止它还不是问题。当我将进程从控制台应用程序移动到 MVC 控制器操作时，这些问题就开始了。

【解决方案2】：

如果它主动引起问题，我会感到惊讶，只要这些线程不尝试回复请求/响应（现在可能已经消失）。你看到什么症状？你能定义“古怪”吗？

我经常使用线程进行日志记录等，没有问题。

为了最大程度地减少影响，您可以使用生产者/消费者模式，这样您就只有一个（或几个）工作线程，为许多 ASP.NET MVC 请求/响应线程提供服务。

【讨论】：

'Wacky' 我的意思是它完成了我的任务的处理（这应该已经结束了我所有产生的线程，因为我等待它们结束/超时），并返回 View()，但浏览器永远不会完成接收页面，并且对站点任何其他页面的任何后续请求都会挂起。

【解决方案3】：

我认为这取决于它是如何完成的。对于 ASP.NET 下的线程，我不是很能胜任，但我认为您最终可能会使用原本用于服务来自客户端的请求的线程。

【讨论】：