了解 .NET 中的垃圾收集

您在这里被绊倒并得出非常错误的结论，因为您使用的是调试器。您需要按照在用户机器上运行的方式运行代码。首先使用 Build + Configuration manager 切换到 Release build，将左上角的“Active solution configuration”组合更改为“Release”。接下来，进入工具 + 选项、调试、常规并取消选中“抑制 JIT 优化”选项。

现在再次运行您的程序并修改源代码。注意额外的大括号根本没有效果。并注意将变量设置为 null 没有任何区别。它总是打印“1”。它现在按您希望和预期的方式工作。

这确实留下了解释为什么在运行调试构建时它的工作方式如此不同的任务。这需要解释垃圾收集器如何发现局部变量以及调试器如何影响局部变量。

首先，在将方法的 IL 编译为机器代码时，抖动执行两个重要任务。第一个在调试器中非常明显，可以通过Debug + Windows + Disassembly窗口看到机器代码。然而，第二个职责是完全看不见的。它还生成一个表，描述如何使用方法体内的局部变量。该表对每个方法参数和具有两个地址的局部变量都有一个条目。变量将首先存储对象引用的地址。以及不再使用该变量的机器代码指令的地址。此外，该变量是否存储在堆栈帧或 cpu 寄存器中。

该表对于垃圾收集器来说是必不可少的，它需要知道在执行收集时到哪里查找对象引用。当引用是 GC 堆上对象的一部分时，这很容易做到。当对象引用存储在 CPU 寄存器中时，绝对不容易做到。桌子上写着去哪里看。

表中“不再使用”的地址非常重要。它使垃圾收集器非常高效。它可以收集对象引用，即使它在方法内部使用并且该方法尚未完成执行。这很常见，例如，您的 Main() 方法只会在程序终止之前停止执行。显然，您不希望该 Main() 方法中使用的任何对象引用在程序期间存在，这将构成泄漏。抖动可以使用该表来发现这样的局部变量不再有用，这取决于程序在调用之前在 Main() 方法中的进度。

与该表相关的一个几乎神奇的方法是 GC.KeepAlive()。这是一种非常特殊的方法，它根本不会生成任何代码。它的唯一职责是修改该表。它延长了局部变量的生命周期，防止它存储的引用被垃圾收集。您需要使用它的唯一时间是阻止 GC 过度收集引用，这可能发生在将引用传递给非托管代码的互操作场景中。垃圾收集器看不到此类代码正在使用此类引用，因为它不是由抖动编译的，因此没有说明在哪里查找引用的表格。将委托对象传递给像 EnumWindows() 这样的非托管函数是需要使用 GC.KeepAlive() 时的样板示例。

因此，正如您在 Release 构建中运行示例代码片段后所看到的那样，可以在方法完成执行之前及早收集局部变量。更强大的是，如果该方法不再引用此对象，则该对象可以在其方法之一运行时被收集。这样做有一个问题，调试这种方法非常尴尬。因为您可以将变量放在 Watch 窗口中或对其进行检查。如果发生 GC，它会在您调试时消失。那将是非常不愉快的，所以抖动知道有一个调试器连接。然后它修改表并改变“最后使用”的地址。并将其从正常值更改为方法中最后一条指令的地址。只要方法没有返回，它就会使变量保持活动状态。这使您可以继续观看它，直到方法返回。

现在这也解释了你之前看到的内容以及你问这个问题的原因。它打印“0”，因为 GC.Collect 调用无法收集引用。该表显示该变量在 GC.Collect() 调用之后一直在使用，一直到方法结束。通过附加调试器并运行调试版本来强制这么说。

将变量设置为 null 现在确实有效果，因为 GC 将检查变量并且将不再看到引用。但是请确保您不会落入许多 C# 程序员所陷入的陷阱，实际上编写该代码是没有意义的。当您在 Release 构建中运行代码时，无论该语句是否存在都没有区别。事实上，抖动优化器将删除该语句，因为它没有任何效果。所以千万不要写这样的代码，即使它似乎有效果。

关于这个主题的最后一点说明，这就是让编写小程序来使用 Office 应用程序做某事的程序员陷入困境的原因。调试器通常会让他们走上错误的道路，他们希望 Office 程序按需退出。适当的方法是调用 GC.Collect()。但是当他们调试他们的应用程序时，他们会发现它不起作用，通过调用 Marshal.ReleaseComObject() 将他们引导到永远不会到达的地方。手动内存管理，它很少能正常工作，因为它们很容易忽略不可见的接口引用。 GC.Collect() 确实有效，只是在调试应用程序时无效。

---

[只是想进一步补充最终确定过程的内部]

您创建一个对象，当该对象被垃圾回收时，应该调用该对象的 Finalize 方法。但除了这个非常简单的假设之外，还有更多的事情要做。

概念：

没有实现 Finalize 方法的对象：它们的内存被立即回收，当然，除非它们不再被应用程序代码访问。实现 Finalize 方法的对象：Application Roots、Finalization Queue、Freachable Queue 的概念需要理解，因为它们都涉及到回收过程。如果应用程序代码无法访问任何对象，则将其视为垃圾。

假设：类/对象 A、B、D、G、H 不实现 Finalize 方法，而 C、E、F、I、J 实现 Finalize 方法。

当应用程序创建新对象时，new 运算符会从堆中分配内存。如果对象的类型包含 Finalize 方法，则指向该对象的指针被放置在终结队列中。因此指向对象 C、E、F、I、J 的指针被添加到终结队列中。

终结队列是由垃圾收集器控制的内部数据结构。队列中的每个条目都指向一个对象，在回收对象的内存之前应该调用其 Finalize 方法。

下图显示了一个包含多个对象的堆。其中一些对象可以从 应用程序根 访问，而有些则不能。创建对象 C、E、F、I 和 J 时，.NET 框架会检测到这些对象具有 Finalize 方法，并将指向这些对象的指针添加到终结队列。

https://i.stack.imgur.com/33Wsz.gif

当发生 GC（第一次收集）时，对象 B、E、G、H、I 和 J 被确定为垃圾。 A、C、D、F 仍然可以通过上面黄色框中箭头所示的应用程序代码访问。

垃圾收集器扫描终结队列寻找指向这些对象的指针。当找到一个指针时，该指针从终结队列中移除并附加到freachable queue（“F-reachable”，即终结器可达）。 freachable 队列是由垃圾收集器控制的另一个内部数据结构。 freachable 队列中的每个指针都标识一个准备好调用其 Finalize 方法的对象。

在第 1 次 GC 之后，托管堆看起来类似于下图。解释如下：

对象 B、G 和 H 占用的内存已被立即回收，因为这些对象没有需要调用的 finalize 方法。但是，对象 E、I 和 J 占用的内存无法回收，因为它们的 Finalize 方法还没有被调用。调用 Finalize 方法是由 freachable queue 完成的。 A、C、D、F 仍然可以通过上面黄色框中箭头所示的应用程序代码访问，因此在任何情况下都不会收集它们。

https://i.stack.imgur.com/A4qf2.gif

有一个专门用于调用 Finalize 方法的特殊运行时线程。当 freachable 队列为空时（通常是这种情况），该线程休眠。但是当条目出现时，该线程唤醒，从队列中删除每个条目，并调用每个对象的 Finalize 方法。垃圾收集器压缩可回收的内存，特殊的运行时线程清空 freachable 队列，执行每个对象的 Finalize 方法。所以最后是你的 Finalize 方法被执行的时候。

下次调用垃圾收集器（第 2 次 GC）时，它会发现最终对象是真正的垃圾，因为应用程序的根不指向它，并且 freachable 队列不再指向它（它也是 EMPTY），因此可以从堆中回收对象 E、I、J 的内存。见下图并与上图进行比较。

https://i.stack.imgur.com/atQbH.gif

这里要理解的重要一点是，需要两次 GC 来回收需要终结的对象使用的内存。实际上，甚至需要两个以上的集合，因为这些对象可能会被提升到老一代。

注意：freachable 队列被认为是根，就像全局和静态变量是根一样。因此，如果一个对象在 freachable 队列上，则该对象是可访问的并且不是垃圾。

最后一点，请记住调试应用程序是一回事，垃圾收集是另一回事，并且工作方式不同。到目前为止，您无法仅通过调试应用程序来感受垃圾收集。如果您想进一步研究内存，请开始here。

---