在ASP.NET中线程时,我应该注意什么?

首先,您是在谈论异步ASP.NET吗?或者使用线程工具/旋转自己的线程?

如果你 不是 谈到异步ASP.NET,要回答的主要问题是:您将在其他线程中做什么工作,该工作是特定于请求/响应周期的,还是更关注于后台处理全局任务?

编辑

如果你需要处理 并行操作 (一个比 多线程 imo)对于给定的请求/响应周期,则使用ASP.NET的异步功能。它们提供了对IIS对并发性的支持的抽象,允许服务器在当前请求等待工作完成时处理其他请求。

对于全局任务的后台处理,我根本不使用ASP.NET。您应该假设IIS将在随机时间点回收您的应用程序池。您也不应该假定IIS将按任何计划运行您的AppPool。任何重要的后台处理都应该在IIS之外完成,无论是作为计划任务还是作为Windows服务。我通常采用的方法是拥有一个Windows服务和一个共享的工作队列,网站可以在其中发布工作项。队列可以是数据库表、可靠的基于消息的队列(msmq等)、文件系统上的文件等。

由于IIS接收到的每个HTTP请求都是单独处理的,不管怎样,在它自己的线程上,您应该拥有的唯一问题是,如果从单个HTTP请求的范围内启动一些长时间运行的进程。在这种情况下,我将把这些代码放入一个单独的引用依赖程序集中,像中间层组件一样进行编码,根本不依赖或耦合到ASP.NET模型,并且单独处理程序集中出现的任何并发问题,而不必担心ASP.NET模型…

JeffRichter在Wintelect有一个叫做PowerThreading的库。如果您正在.NET上开发应用程序,它将非常有用。= & gt; Power Threading Library

在各种活动中在线查看他的演示文稿。

通常,我们鼓励您使用.NET中的线程池,因为它有许多好处,可以代表您管理事务……,但是 不是 在ASP.NET。

由于ASP.NET已经是多线程的,因此它使用线程池来服务映射到ASP.NET ISAPI筛选器的请求,并且由于线程池的大小是固定的,因此使用它,基本上就是将为处理请求而预留的线程带走。

在小流量、低流量的网站中,这不是一个问题,但在大流量、高流量的网站中,您最终会争夺和消费ASP.NET进程所依赖的线程。

如果您想使用线程,可以做一些类似于….

   Thread thread = new Thread(threadStarter);
   thread.IsBackground = true;
   thread.Start(); 

但有一个警告: 确保 IsBackground 设置为 true 因为如果线程不在前台,它可能会阻止IIS工作进程回收或重新启动。

最直接想到的是,为什么要在ASP.NET中“实现线程”。

你需要时刻注意ASP.NET 是 多线程,因为许多请求可以在各自的线程中被模拟地处理。因此,例如,静态字段的使用需要考虑线程。

然而,很少有人希望自己在代码中创建一个新的线程。

就用户界面中线程的常见WinForms问题而言,这些问题在ASP.NET中不存在。没有需要担心的基于窗口的消息泵。

可以在ASP.NET中创建异步页。这些将执行到某一点的所有步骤。例如,这些步骤将包括异步获取数据。当所有异步任务完成后,页面生命周期的其余部分将执行。同时,一个工作线程没有被绑定,等待数据库I/O完成。

在这个模型中,当请求、页面实例和所有控件仍然存在时,所有额外的线程都在执行。启动自己的线程时必须小心,在线程执行时,可能已经释放了请求、页面实例和控件。

同样,像往常一样,要确保多个线程实际上会提高性能。通常,额外的线程会使情况更糟。

gotchas与任何多线程应用程序中的gotchas几乎相同。

处理请求所涉及的类(page、controls、httpContext.current,…)是特定于该请求的,因此不需要任何特殊处理。

同样,对于您实例化为这些类中的局部变量或字段的任何类,以及对会话的访问。

但是,和往常一样,您需要同步对共享资源的访问,例如:

• 静态(c)/共享(vb.net)引用。
• 独生子女
• 外部资源,如文件系统 …等。。。

我在ASP.NET应用程序中经常看到线程错误,例如,多个并发请求在不同步的情况下使用单个实例,从而导致用户A看到用户B的数据。