2

这不是终止系统进程，而是杀死“我自己”。我有几个并行的线程，由于不同的原因，它们可能会挂起。

当线程花费太长时间时，我已经创建了一个看门狗：

TimerCallback timerDelegate = new TimerCallback(CheckProcessStatus);
System.Threading.Timer watchDogTimer = new Timer(timerDelegate, new ProcessHealth(plog), 1000 * 60, 1000 * 60);
try
   {
   // lots of code here
   } finally
   {
      watchDogTimer.Dispose();
   }

看门狗：

public void CheckProcessStatus(Object timerState) {
    ProcessHealth ph = (ProcessHealth)timerState;
    System.writeLine(string.Format("process runs for {0} minutes!", ph.WaitingTime);
    if (ph.WaitingTime>60) {
      // KILL THE PROCESS
    }
}

当“这里有很多代码”花费太长时间时，无论线程处于什么状态，我都想终止线程。（在“终止进程”处）。

最好的方法是什么？

Thread.CurrentThread.Interrupt()

或者

Thread.CurrentThread.Abort()?

还是有更好的方法？（我不能使用像布尔“停止”变量这样的“简单”机制，因为“这里有很多代码”非常动态地通过反射等调用其他类。

这还有效吗？还是我只是杀死看门狗线程，而不是要监视的线程？

4

2 回答 2

3

当线程处于未知状态时中止线程是不可取的。比如说，线程当前正在执行一个静态构造函数。静态 ctor 将被中止并且不再运行（因为出错的静态 ctor 不再运行）。您已经有效地破坏了 AppDomain 中的全局状态，而无法恢复。

还有很多其他的危害。那只是不飞。

有两个生产就绪选择中止线程：

  1. 合作（结合 Thread.MemoryBarrier 设置事件或布尔标志）
  2. 不要中止线程，而是整个 AppDomain 或进程。线程级粒度太小。您需要删除与该线程相关的所有状态，doo。

我想强调的是，你不能以任何其他方式完成这项工作。如果您坚持不合作地中止线程，您将在生产中遇到最奇怪的错误。

于 2012-06-01T13:08:04.183 回答
3

Thread.Abort尝试通过注入带外（异步）异常来终止目标线程。这是不安全的，因为异常会在执行序列中不可预测的点注入。由于对数据结构的写入中断，这可能（并且经常会）导致应用程序域中的某种类型的损坏。

Thread.Interrupt导致 BCL 中的大多数阻塞调用（如Thread.Sleep、WaitHandle.WaitOne等）立即救助。与中止线程不同，中断线程可以完全安全，因为异常是在执行序列中可预测的点注入的。狡猾的程序员可以确保这些点被认为是“安全点”。

因此，如果“这里有很多代码”会响应，Thread.Interrupt那么这可能是一种可以接受的使用方法。但是，我想引导您更多地采用合作取消模式。基本上，这意味着您的代码必须定期轮询取消请求。TPL 已经有一个框架可以通过CancellationToken. ManualResetEvent但是，您可以使用一个或一个简单的 volatile bool 变量轻松完成同样的事情。

现在，如果“这里有很多代码”不在您的控制之下，或者如果协作取消模式不起作用（可能是因为您使用了有问题的 3rd 方库），那么您几乎别无选择，只能启动一个完全独立的运行有风险的代码的过程。使用 WCF 与进程通信，如果它没有响应，那么您可以在不破坏主进程的情况下杀死它。这是很多工作，但它可能是你唯一的选择。

于 2012-06-01T14:28:55.597 回答