在ASP.Net应用程序中，用户单击网页上的一个按钮，然后通过事件处理程序在服务器上实例化一个对象，并对该对象调用一个方法.
我不知道的是，即使用户会话过期，IIS是否允许我的线程继续运行. 想象一下，用户激发事件，我们在服务器上实例化对象，并在新线程中激发方法.用户对"您的请求已提交"消息感到满意，并关闭浏览器.最终，此用户会话将在IIS上超时，但线程可能仍在运行，正在进行工作.IIS会允许线程继续运行，还是会在用户会话到期后终止该线程并释放该对象？
编辑:从答案和 comments 中，我了解到最好的方法是将长期运行的处理移到IIS之外.除此之外，这还涉及appdomain回收问题.在实践中，我需要在有限的时间内启动版本1，并且必须在现有框架内工作，因此我希望避免使用服务层，因此希望在IIS中启动线程.实际上，这里的"长时间运行"只需要几分钟，网站上的并发性很低，所以应该没问题.但是，下一个版本肯定需要拆分为单独的服务层.
你可以实现你想要的，但这通常是个坏主意.几个ASP.NET博客和CMS引擎采用这种方法，因为它们希望可以安装在共享主机系统上，而不是依赖需要安装的windows服务.通常，它们会在全局启动一个长期运行的线程.尽快启动应用程序，并让线程进程将任务排队.
除了减少IIS/ASP可用的资源.NET来处理请求，当AppDomain被回收时，你也会遇到线程被终止的问题，然后你必须处理任务在运行中的持久性，以及在AppDomain恢复时重新开始工作.
请记住，在许多情况下，AppDomain会以默认时间间隔自动回收，如果您更新了web，也会自动回收.配置等等.
如果你可以随时处理线程被终止的持久性和事务性方面，那么你可以通过让一些外部进程在某个时间间隔在你的站点上发出请求来绕过AppDomain回收——这样，如果站点被回收，你就可以保证它在X分钟内自动重新启动.
同样，这通常是个坏主意.
编辑:以下是这种技术的一些实际应用示例:
Community Server: Using Windows Services vs. Background Thread to Run Code at Scheduled Intervals
编辑(来自遥远的future )-这些天我会用Hangfire.