关于在 .NET 中干净地终止线程的问题

Question

我了解到 Thread.Abort() 从我读过的大量关于该主题的文章中是邪恶的，所以我目前正在删除我所有的中止，以便以更清洁的方式替换它；在比较了人们在 * 上的用户策略之后，然后在阅读了 MSDN 中的 "How to: Create and Terminate Threads (C# Programming Guide)" 之后，两者都声明了一种非常相同的方法——即使用volatile bool 方法检查策略，这很好，但我还有几个问题......

这里让我印象深刻的是，如果您没有一个简单的工作进程，它只是运行一个处理代码的循环，该怎么办？例如，对我来说，我的进程是一个后台文件上传进程，我实际上是循环遍历每个文件，所以这就是一些东西，我可以肯定我可以在顶部添加我的while (!_shouldStop)，它涵盖了我的每次循环迭代，但我有很多在下一次循环迭代之前发生的更多业务流程，我希望这个取消过程快速；不要告诉我我需要在我的整个工作函数中每隔 4-5 行将这些 while 循环洒下来吗？！

我真的希望有更好的方法，如果这实际上是正确的 [也是唯一的？] 方法，或者他们过去为实现我所追求的目标而使用的策略，请告诉我.

谢谢大家。

进一步阅读：All these SO responses 假设工作线程将循环。这让我感到不舒服。如果是线性但及时的后台操作呢？

Answer 1

不幸的是，在多线程中，您经常不得不为了清洁而牺牲“敏捷性”……如果您Interrupt 可以立即退出线程，但它不会很干净。所以不，您不必每隔 4-5 行检查一次_shouldStop，但如果您确实中断了线程，那么您应该处理异常并以干净的方式退出循环。

更新

即使它不是一个循环线程（即，它可能是一个执行一些长时间运行的异步操作或某种类型的输入操作块的线程），你可以Interrupt 它，但你仍然应该抓住ThreadInterruptedException并干净地退出线程。我认为您一直在阅读的示例非常合适。

更新 2.0

是的，我有一个示例...我将根据您引用的链接向您展示一个示例：

public class InterruptExample
{
    private Thread t;
    private volatile boolean alive;

    public InterruptExample()
    {
        alive = false;

        t = new Thread(()=>
        {
            try
            {
                while (alive)
                {
                    /* Do work. */
                }
            }
            catch (ThreadInterruptedException exception)
            {
                /* Clean up. */
            }
        });
        t.IsBackground = true;
    }

    public void Start()
    {
        alive = true;
        t.Start();
    }


    public void Kill(int timeout = 0)
    {
        // somebody tells you to stop the thread
        t.Interrupt();

        // Optionally you can block the caller
        // by making them wait until the thread exits.
        // If they leave the default timeout, 
        // then they will not wait at all
        t.Join(timeout);
    }
}

Answer 2

也许问题的一部分是你有这么长的方法/while循环。无论您是否遇到线程问题，都应该将其分解为更小的处理步骤。假设这些步骤是 Alpha()、Bravo()、Charlie() 和 Delta()。

然后你可以这样做：

    public void MyBigBackgroundTask()
    {
        Action[] tasks = new Action[] { Alpha, Bravo, Charlie, Delta };
        int workStepSize = 0;
        while (!_shouldStop)
        {
            tasks[workStepSize++]();
            workStepSize %= tasks.Length;
        };
    }

所以是的，它会无限循环，但会检查是否是在每个业务步骤之间停止的时间。

Answer 3

所有这些 SO 响应都假定工作线程将循环。这让我感到不舒服

没有很多方法可以让代码花费很长时间。循环是一个非常重要的编程结构。使代码在不循环的情况下花费很长时间需要大量 语句。数十万。

或者调用其他一些正在为您执行循环的代码。是的，很难让代码按需停止。那是行不通的。

Answer 4

您不必到处使用 while 循环。外部 while 循环只是检查它是否被告知停止，如果是，则不会进行另一次迭代......

如果您有一个直接的“去做某事并关闭”线程（其中没有循环），那么您只需检查线程内每个主要点之前或之后的 _shouldStop 布尔值。这样你就知道它应该继续还是退出。

例如：

public void DoWork() {

  RunSomeBigMethod();
  if (_shouldStop){ return; }
  RunSomeOtherBigMethod();
  if (_shouldStop){ return; }
  //....
}

---

Answer 5

如果取消是您正在构建的东西的要求，那么它应该像您的代码的其余部分一样受到尊重 - 这可能是您必须设计的东西。

让我们假设您的线程一直在做两件事之一。

1. CPU 绑定的东西
2. 等待内核

如果您在相关线程中受到 CPU 限制，那么您可能有一个很好的位置来插入纾困检查。如果您正在调用其他人的代码来执行一些长时间运行的 CPU 密集型任务，那么您可能需要修复外部代码，将其移出进程（中止线程是邪恶的，但中止进程是明确定义且安全的) 等。

如果您正在等待内核，那么可能有一个句柄（或 fd，或 mach 端口，...）参与等待。通常如果你破坏了相关的句柄，内核会立即返回一些失败代码。如果您在 .net/java/etc 中。您可能最终会遇到异常。在 C 语言中，您已经拥有处理系统调用失败的任何代码都会将错误传播到应用程序的有意义的部分。无论哪种方式，您都可以相当干净且非常及时地突破低级别的地方，而无需到处撒上新代码。

我经常使用这种代码的策略是跟踪需要关闭的句柄列表，然后让我的中止函数设置一个“已取消”标志，然后关闭它们。当函数失败时，它可以检查标志并报告由于取消而不是由于特定异常/errno 而导致的失败。

您似乎在暗示可接受的取消粒度是在服务调用级别。这可能不是一个好的想法——你最好同步取消后台工作并从前台线程加入旧的后台线程。它更干净，因为：

1. 当旧的 bgwork 线程在意外延迟后恢复运行时，它避免了一类竞争条件。

2. 它可以隐藏挂起的后台线程的影响，从而避免因挂起后台进程而导致的潜在隐藏线程/内存泄漏。

害怕这种方法有两个原因：

1. 您认为自己无法及时中止自己的代码。如果取消是您的应用程序的要求，那么您真正需要做出的决定是资源/业务决定：进行破解或彻底解决您的问题。

2. 您不信任您正在调用的某些代码，因为它超出了您的控制范围。如果您真的不信任它，请考虑将其移出进程。这样一来，您就可以更好地隔离多种风险，包括这个风险。

Answer 6

最佳答案很大程度上取决于您在线程中所做的事情。

• 正如您所说，大多数答案都围绕着每几行轮询一个共享布尔值。即使您可能不喜欢它，这通常是最简单的方案。如果你想让你的生活更轻松，你可以编写一个像 ThrowIfCancelled() 这样的方法，如果你完成了它会抛出某种异常。纯粹主义者会说这是（喘气）使用异常来控制流，但是再次取消是 imo 异常。

• 如果您正在执行 IO 操作（例如网络操作），您可能需要考虑使用异步操作来完成所有操作。

• 如果您正在执行一系列步骤，则可以使用 IEnumerable 技巧来创建状态机。示例：

abstract class StateMachine : IDisposable
{
    public abstract IEnumerable<object> Main();

    public virtual void Dispose()
    {
        /// ... override with free-ing code ...
   }

   bool wasCancelled;

   public bool Cancel()
   {
     // ... set wasCancelled using locking scheme of choice ...
    }

   public Thread Run()
   {
       var thread = new Thread(() =>
           {
              try
              {
                if(wasCancelled) return;
                foreach(var x in Main())
                {
                    if(wasCancelled) return;
                }
              }
              finally { Dispose(); }
           });
       thread.Start()
   }
}

class MyStateMachine : StateMachine
{
   public override IEnumerabl<object> Main()
   {
       DoSomething();
       yield return null;
       DoSomethingElse();
       yield return null;
   }
}

// then call new MyStateMachine().Run() to run.

>

过度工程？这取决于您使用多少个状态机。如果你只有1，是的。如果你有 100 个，那么可能没有。太棘手了？这得看情况。这种方法的另一个好处是，它可以让您（稍作修改）将您的操作移动到 Timer.tick 回调中，如果有意义的话，可以完全取消线程。

并且做 blucz 说的一切。

Answer 7

不要在不属于循环的地方添加while循环，而是在有意义的地方添加if (_shouldStop) CleanupAndExit();之类的东西。无需在每次操作后检查或将代码撒在上面。相反，应将每次检查视为退出线程的机会，并考虑到这一点，战略性地添加它们。

Answer 8

很遗憾，可能没有更好的选择。这真的取决于你的具体情况。这个想法是在安全点优雅地停止线程。这就是Thread.Abort不好的症结所在；因为它不能保证在安全点发生。通过在代码中添加停止机制，您可以有效地手动定义安全点。这称为合作取消。基本上有 4 种广泛的机制可以做到这一点。您可以选择最适合您的情况。

投票停止标志

您已经提到过这种方法。这是一个很常见的。在算法中的安全点定期检查标志，并在收到信号时退出。标准方法是标记变量volatile。如果这不可能或不方便，那么您可以使用lock。请记住，您不能将局部变量标记为volatile，因此，例如，如果 lambda 表达式通过闭包捕获它，那么您将不得不采用不同的方法来创建所需的内存屏障。对于这种方法，无需多说。

使用 TPL 中的新取消机制

这类似于轮询停止标志，只是它使用 TPL 中的新取消数据结构。它仍然基于合作取消模式。您需要获得CancellationToken 并定期检查IsCancellationRequested。要请求取消，您可以在最初提供令牌的 CancellationTokenSource 上致电 Cancel。您可以使用新的取消机制做很多事情。你可以阅读更多关于here的信息。

使用等待句柄

如果您的工作线程需要等待特定时间间隔或在其正常操作期间等待信号，则此方法会很有用。例如，您可以Set 和ManualResetEvent 让线程知道是时候停止了。您可以使用WaitOne 函数测试事件，该函数返回一个bool，指示事件是否已发出信号。 WaitOne 采用一个参数，该参数指定如果在该时间内未发出事件信号，则等待调用返回的时间。您可以使用此技术代替Thread.Sleep 并同时获得停止指示。如果线程可能必须等待其他WaitHandle 实例，它也很有用。您可以致电WaitHandle.WaitAny 以在一个呼叫中等待任何事件（包括停止事件）。使用事件可能比调用 Thread.Interrupt 更好，因为您可以更好地控制程序的流程（Thread.Interrupt 会引发异常，因此您必须战略性地放置 try-catch 块以执行任何必要的清理）。

特殊场景

有几种一次性场景具有非常专门的停止机制。枚举它们绝对超出了这个答案的范围（别介意这几乎是不可能的）。我的意思的一个很好的例子是Socket 类。如果线程在调用Send 或Receive 时被阻塞，那么调用Close 将在有效解除阻塞的任何阻塞调用上中断套接字。我确信 BCL 中还有其他几个领域可以使用类似的技术来解除线程阻塞。

通过Thread.Interrupt中断线程

这里的优点是它很简单，您不必真正专注于在代码中添加任何东西。缺点是您几乎无法控制算法中安全点的位置。原因是Thread.Interrupt 通过在一个固定的 BCL 阻塞调用中注入一个异常来工作。这些包括Thread.Sleep、WaitHandle.WaitOne、Thread.Join 等。所以你必须明智地选择它们的放置位置。但是，大多数情况下，算法决定了它们的去向，这通常很好，特别是如果您的算法将大部分时间花在这些阻塞调用之一中。如果您的算法不使用 BCL 中的阻塞调用之一，那么此方法将不适合您。这里的理论是 ThreadInterruptException 仅由 .NET 等待调用生成，因此它可能处于安全点。至少您知道线程不能处于非托管代码中，也不能脱离临界区而使悬空锁处于获取状态。尽管这比 Thread.Abort 的侵入性小，但我仍然不鼓励使用它，因为不清楚哪些调用会响应它，而且许多开发人员会不熟悉它的细微差别。