GC为什么要将对象放入最终队列中？

Question

据我了解，在C＃垃圾回收器会放一个类的所有对象到结束队列，只要我实现类的析构函数。当我正在阅读GC.Suppresfinalize的文档时，它提到对象头文件已经有一些设置用于调用finalize。

我想知道的是，为什么GC的实施者不得不把所有的对象在队列中，并通过1-2个周期延迟的内存freeup。难道他们不能在释放内存时查看位标志，然后调用对象的finalize并释放内存？

毫无疑问，我是一个白痴，我不能够理解GC的工作。我提出这个问题只是为了提高我的理解，或者填补我的知识缺失

编辑：如果位标志是用于suppressfinalize，GC实现者可能已经在此对象头中添加了另一个标志，不是吗？

Answer 1

这里有一个很好的解释

What are the Finalizer Queue and Control+ThreadMethodEntry?

本质上的理由是，它可能并不总是理想的GC不得不等待终结代码来执行，所以排队的终结让定稿是推迟到更方便的时候。

Answer 2

因此，它可以在不同的线程运行，从而堵塞了主GC线程保持。

你可以学到很多关于此MSDN article的GC。

Answer 3

这是理想的垃圾收集暂停要尽可能的短。为此，当垃圾收集的疯狂工作完成时，运行终结器通常会延迟到稍后的时间。它是在单独的线程中在后台完成的。

Answer 4

@Jason：对于f-reachable队列是如此。但恕我直言，它并没有解释为什么有自己的定稿队列。

我的猜测是，终结队列有加另一个信息，帮助GC 所有对象的生命周期的可能状态之间进行区分。

对象头部中的终结标志表示“对象需要终结”或“对象不需要终结”，但并不表示终止是否已经发生。

但说实话，我不明白为什么它需要在当前的定稿过程实施。

事实上，这里是天真的流程我想可能没有终结队列：

• 创建对象时，如果它有一个终结，则GC设置结束标志;
• 如果后来SupressFinalize被调用，那么该标志被归零;
• 现在让我们跳到GC收集对象的方式，该对象从任何地方都没有被引用：如果设置了终结标记，则GC将该对象的引用放入f-reachable队列，并让终结线程运行;
• 后来终结线程退出引用，重置终结标志并运行终结器;
• 如果对象想要重新设定以后它可以ReRegisterForFinalize重新设置终止标志;
• 后来GC再次收集对象：如果没有设置终结标志，它知道没有什么要做，然后释放对象内存;
• 如果设置了终结标志，则GC再次将该对象的引用排入f可到达的队列，然后再次进入另一轮;
• 在某个时间点对象很高兴，完成定稿并收集;或者应用程序域或进程被关闭并且无论如何都释放内存。

因此，似乎在这些情况下不需要定型队列，只有定型标志是有用的。

一个可能的原因是，从概念的角度来看，可能会有一条规则：“一个对象被收集，当且仅当它没有被任何根引用”。 因此，没有确定队列，并且根据对象状态本身收集对象的决定，检查确定标志，与此规则不兼容。

但是我真的不认为GC的实现是基于这种理论规则的教条性应用，而只是基于实用的选择;所以很明显，我错过了一些关键场景，其中GC需要确定队列才能知道在收集对象时要做什么，但是哪些是？

Answer 5

垃圾收集器不会识别和检查垃圾，除了处理大对象堆时。相反，它的行为就像一个保龄球胡同的取样器，可以在抛掷之间去除死木：取样器抓住仍然存在的所有销钉，将它们从车道表面提起，然后在整个车道上运行清扫杆，而不考虑表面上有多少针脚。清除内存批量比识别要删除的单个对象快得多。如果1％的对象具有终结器（实数可能更少），那么有必要检查100个对象标题以找到每个可终结对象。有一个单独的具有终结器的对象列表使得GC甚至无需查看任何不包含的垃圾对象。