关于多线程：ASP.NET中的BackgroundWorker线程

BackgroundWorker thread in ASP.NET

是否可以在以下情况下使用ASP.NET 2.0中的BackGroundWorker线程，以便浏览器端的用户不必等待很长时间？

情境

浏览器请求一个页面，例如SendEmails.aspx

SendEmails.aspx页创建一个BackgroundWorker线程，并为该线程提供足够的上下文来创建和发送电子邮件。

浏览器从ComposeAndSendEmails.aspx接收响应，说正在发送电子邮件。

同时，后台线程参与了创建和发送电子邮件的过程，这可能需要花费大量时间才能完成。

我主要关心的是在ASP.NET workerprocess线程池线程已久的情况下，保持BackgroundWorker线程运行，尝试发送50条电子邮件。

如果您不想使用AJAX库，或者电子邮件处理时间真的很长，并且会使标准的AJAX请求超时，则可以使用.net 1.1天内的"老方法" AsynchronousPostBack方法。

本质上，您要做的是让您的提交按钮以异步状态开始电子邮件处理，同时将用户带到中间页面。这样做的好处是您可以根据需要刷新中间页面，而不必担心达到标准超时。

当您的后台进程完成时，它将在数据库/应用程序变量/任何内容中放置一个"完成"标志。当您的中间页面刷新自身时，它将检测到此标志并自动将用户重定向到"完成"页面。

同样，AJAX可以解决所有这些问题，但是如果由于某种原因您必须在网络上进行非常密集或及时的处理，则此解决方案将为您服务。我在这里找到了不错的教程，并且还有更多的教程。

当我们在与第三方应用程序接口的" Web Check-in"类型应用程序上工作时，我必须使用这样的过程，并且它们的导入API太慢了。

编辑：嘎！诅咒你古兹拉和你类似神的打字能力8 ^ D。

您不应该从ASP.NET页进行任何线程化。当工作进程循环时，任何长时间运行的线程都有被杀死的危险。您无法预测何时会发生这种情况。 Windows服务需要处理所有长时间运行的进程。例如，您可以通过在MSMQ中放置一条消息来启动这些过程。

1	ThreadPool.QueueUserWorkItem(delegateThatSendsEmails)

或在System.Net.Mail.SmtpServer上使用SendAsync方法。

您希望将发送电子邮件的代码放在另一个线程上，因为这将立即返回用户，并且将进行处理(无论花费多长时间)。

5年后，但是问题还是一样……如果您想从应用程序中执行即忘操作，而忘记了与ASP.NET应用程序中的后台作业处理相关的所有困难，则可以使用http://hangfire.io。

它不会在回收过程中丢失您的作业，因为它使用持久性存储来保留有关后台作业的信息。
它会自动重试由于短暂异常(SMTP服务器连接错误)而被中止或失败的后台作业。
它使您可以通过集成的Web界面轻松调试后台作业。
安装/配置/使用HangFire非常容易。

还有一个使用ASP.NET MVC在后台发送邮件的教程，用于将HangFire与邮政一起使用。

如果要在ASP页中使用多头处理，则可以使用以下简单的线程模型：

1
2
3
4
5
6
7
8

{
System.Threading.Thread _thread = new Thread(new ThreadStart(Activity_DoWork));
_thred.Start();
}
Activity_DoWork()
{
/*Do some things...
}

此方法是正确使用ASP页。当BackgroundWorker完成时，带有BackgroundWorker的ASP页将不会启动。

在这种情况下，您需要使用ASP.NET 2.0中添加的异步页面功能。

Asynchronous pages offer a neat
solution to the problems caused by
I/O-bound requests. Page processing
begins on a thread-pool thread, but
that thread is returned to the thread
pool once an asynchronous I/O
operation begins in response to a
signal from ASP.NET. When the
operation completes, ASP.NET grabs
another thread from the thread pool
and finishes processing the request.
Scalability increases because
thread-pool threads are used more
efficiently. Threads that would
otherwise be stuck waiting for I/O to
complete can now be used to service
other requests. The direct
beneficiaries are requests that don't
perform lengthy I/O operations and can
therefore get in and out of the
pipeline quickly. Long waits to get
into the pipeline have a
disproportionately negative impact on
the performance of such requests.