我在 MVC3 应用程序中有几个长时间运行的线程，它们应该永远运行。
我遇到了一个问题，其中 ThreadAbortException 被其他代码(不是我的代码)调用，我需要从容恢复并重新启动线程。目前，我们唯一的办法是回收 appDomain 的工作进程，这远非理想。
以下是有关此代码工作原理的一些详细信息:
此 MVC3 应用程序存在单例服务类。它必须是单例，因为它缓存数据。该服务负责向数据库发出请求。第三方库用于实际的数据库连接代码。
在这个单例类中，我们使用称为“QueryRequestors”的类集合。这些类标识对数据库的请求的唯一 package+stored_procedure 名称，以便我们可以对这些调用进行排队。这就是 QueryRequestor 类的目的:确保对同一 package+stored_procedure 的调用(尽管它们可能具有无限不同的参数)排队，并且不会同时发生。这大大减轻了我们的数据库压力并提高了性能。
QueryRequestor 类使用内部 BlockingCollection 和内部 Task(线程)来监视其队列(阻塞集合)。当请求进入单例服务时，它通过 package+stored_procedure 名称找到正确的 QueryRequestor 类，并将查询交给该类。查询被放入队列中(阻塞收集)。 QueryRequestor 的任务看到队列中有一个请求并调用数据库(现在涉及第 3 方库)。当结果返回时，它们被缓存在单例服务中。任务继续处理请求，直到阻塞集合为空，然后等待。
一旦 QueryRequestor 创建并启动并运行，我们永远不希望它消亡。请求每隔几分钟就会收到此服务(24/7)。如果服务中的缓存有数据，我们就使用它。当数据过时时，下一个请求将排队(后续并发请求将继续使用缓存，因为它们知道有人(另一个线程)已经在发出排队请求，这是高效的)。
所以这里的问题是当 QueryRequestor 类中的任务遇到 ThreadAbortException 时该怎么办。理想情况下，我想从中恢复并重新启动线程。或者，至少，处理掉 QueryRequestor(就我而言，它现在处于“损坏”状态)并重新开始。因为如果服务中不存在，则与 package+stored_procedure 名称匹配的下一个请求将创建一个新的 QueryRequestor。
我怀疑该线程被第 3 方库杀死，但我不能确定。我所知道的是，我在任何地方都不会中止或尝试终止线程/任务。我希望它永远运行。但显然我们必须为这个异常准备好代码。当服务因为线程被中止而崩溃时，这是非常烦人的。
处理这个问题的最佳方法是什么？我们怎样才能优雅地处理这个问题？
最佳答案
您可以通过调用Thread.ResetAbort来停止重新抛出ThreadAbortException .
请注意，最常见的异常情况是重定向调用，取消线程中止可能会对请求代码的执行产生不良影响，否则这些代码将因终止线程而被忽略。与 MVC(您可以从 Controller 返回特殊的重定向结果)相比，这是 WinForms(其中代码和渲染的分离不太清晰)中的常见问题。
关于c# - ThreadAbortException之后如何恢复？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15665898/