当应用程序关闭时，我可以检测到后台线程何时被应用程序杀死？答案

【问题标题】：Can I detect when a background Thread is killed by the application when the application closes?当应用程序关闭时，我可以检测到后台线程何时被应用程序杀死？
【发布时间】：2012-06-13 07:27:14
【问题描述】：

我在 C# 中使用了一个线程，我将 IsBackground 属性设置为 true。线程在循环中运行一些代码，直到应用程序关闭。当应用程序关闭时，线程也停止执行（因为我设置了 IsBackground = true）。

应用程序如何杀死线程？似乎它不会通过调用 abort 来做到这一点，因为我没有得到 ThreadAbortException。它发生在幕后吗？我想在循环的 finally 块中做一些回滚。

我知道我可以自己在线程上调用 abort，但我想知道应用程序如何关闭我的后台线程，以及我是否可以从线程内部对其做出反应。我知道我可以订阅 Application.ApplicationExit 事件，但我在服务和 winform 中都运行此代码，我更喜欢在循环中捕获异常，以便能够在 finally 语句中回滚。

【问题讨论】：

您可以将其设为前台线程，并创建一个手动关闭线程的“全局”应用程序关闭场景。
你看过AppDomain.ProcessExit事件吗？
所以你们都说它发生在幕后，除了创建这些自定义解决方案之外，我无法对它做出反应？

标签： c# multithreading threadabortexception isbackground

【解决方案1】：

似乎调用 abort 并没有做到这一点，因为我没有得到 ThreadAbortException

确实如此，CLR 有两种方法可以中止线程。 “正常”方式，通过 Thread.Abort() 调用，线程可以看到 ThreadAbortException。但也有粗鲁的中止，以同样的方式工作。但是减去 TAE 并且没有 finally 块执行。你无法观察它。

【讨论】：

啊哈..感谢您整理出来。我找不到有关此的任何文档
是 MSDN 上的错误吗？ msdn.microsoft.com/en-us/library/… 当公共语言运行时 (CLR) 在托管可执行文件中的所有前台线程都结束后停止后台线程时，它不使用 Thread.Abort。因此，您不能使用 ThreadAbortException 来检测后台线程何时被 CLR 终止。
我看不出那篇 MSDN 文章和这个答案之间有任何差异。粗鲁的中止可以由应用程序代码触发，但您需要 AppDomain.Unload 或 Environment.Exit，通常不是任何人首先想到的那种方法来中止线程:)

【解决方案2】：

当操作系统将处理器分配给thread 时，已启动的thread 进入运行状态（即开始执行）。当 Started 线程第一次收到处理器并成为 Running 线程时，该线程将执行其 ThreadStart delegate，它指定线程在其生命周期中将执行的操作。当程序创建一个新线程时，程序将线程的ThreadStart delegate 指定为线程构造函数的参数。

当其ThreadStart delegate 终止时，正在运行的线程进入Stopped (or Dead) 状态。在您的情况下，您的主线程已终止。因此，您的 ThreadStart delegate 对象不会保留在内存中。当没有对线程对象的引用时，垃圾收集器可以从内存中删除线程对象。

【讨论】：

感谢您对此进行了很好的解释。我最终按照 Botz3000 的建议使用了 AppDomain.ProcessExit 事件。然后，我可以在引发此事件时调用 thread.Abort()。它似乎运作良好。
这个答案不正确。 GC 收集它不会中止一个废弃的后台线程。无论您对托管线程对象有什么强引用，它都会被运行时强制中止。请参阅 Hans 的答案以获得解释。
@JoshEinstein：也许你是对的，但 Hans 没有解释 CLR 是如何异常中止线程的……你能解释一下吗？
它在不运行托管代码的情况下在您的控制之外杀死它（可能使用诸如 ExitThread 之类的 Windows 函数）。如果您需要确保代码在线程终止时运行，您应该在退出主线程之前通知后台线程终止。