blocks|key|2300757|text|因此，它可以在不同的线程中运行，从而避免阻塞主GC线程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2300758|你可以从这个MSDN+article中学到很多关于GC的知识。|offset|length|2300759|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/magazine/bb985010.aspx^0|0|6|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

So it can run in a different thread and thus keep from blocking the main GC thread. 

You can learn a lot about the GC from this <a href="http://msdn.microsoft.com/en-us/magazine/bb985010.aspx">MSDN article</a>.

blocks|key|3361221|text|这里有一个很好的解释|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3361222|What+are+the+Finalizer+Queue+and+Control%2BThreadMethodEntry?|offset|length|3361223|从本质上讲，原因是GC可能并不总是理想的，必须等待终结器代码执行，所以队列终结器允许将终结器推迟到更方便的时候。|3361224|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1268525/what-are-the-finalizer-queue-and-controlthreadmethodentry^0|0|0|1N|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

There is a great explanation here

<a href="https://stackoverflow.com/questions/1268525/what-are-the-finalizer-queue-and-controlthreadmethodentry">What are the Finalizer Queue and Control+ThreadMethodEntry?</a>

Essentially the reasoning is that it may not always be ideal for the GC to have to wait on finalizer code to execute, so queuing finalizers allows finalization to be deferred until a time when it's more convenient.

blocks|key|385950|text|垃圾收集暂停越短越好。为此，运行终结器通常被推迟到稍后的时间，当疯狂的垃圾收集工作完成时。相反，它是在后台的单独线程上完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|385951|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's desirable for garbage collection pauses to be as short as possible. To that end, running finalizers is usually deferred to a later time, when the frantic work of garbage collection is done. It is instead done in the background on a separate thread.

blocks|key|388765|text|@Jason:这对于f-reachable+是正确的。但我不能解释为什么会有finalization-queue本身。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|388766|我猜测finalization-queue的存在是为了添加另一个信息，它可以帮助GC区分对象生命周期的所有可能状态。|388767|对象标头中的finalization标志表示“对象需要被终结”或“对象不需要被终结”，但它没有说明终结是否已经发生。|388768|但老实说，我不明白为什么在当前的最终过程实现中需要它。|388769|实际上，这是我想象中没有finalization-queue的可能的天真的工作流程：|388770|终结器在创建对象时，如果它有一个终结器flag;|388771|if，那么在调用SupressFinalize之后，+GC+将设置终结器；现在让我们跳到GC收集对象时，这不是从任何地方引用的:如果设置了终结器标志，则GC将对对象的引用放入<>e124>f-|unordered-list-item|388772|
|388773|队列<代码>e225，并让终结器线程使该引用出队，重置终结器标志并运行终结器；|388774|388775|如果对象想要再细化，稍后它可以重新设置终结标志；|388776|388777|稍后GC再次收集对象:如果终结标志没有被设置，它知道没有什么可做的，然后释放对象内存；|388778|388779|如果终结标志被设置，GC再次将对对象的引用入队到f-队列中，然后我们再次开始另一轮；|388780|
<>H139>在某个时间点对象是快乐的，完成终结并被收集；或者应用程序域或进程关闭，内存也会被释放。|388781|因此，在这些场景中，似乎不需要finalization-queue，只有finalization标志是有用的。|388782|一个可能的原因是，从概念的角度来看，可能存在这样的规则：“当且仅当不从任何根引用一个对象时，该对象才被收集”。因此，如果没有终结化队列，而是根据对象状态本身来决定收集对象，那么检查终结化标志是不符合这一规则的。|388783|但实际上，我并不认为GC实现是基于这种理论规则的教条式应用，而仅仅是基于实用的选择；因此，很明显，我遗漏了一些关键场景，即GC需要finalization队列来知道在收集对象时要做什么，但是哪些|388784|entityMap^0|A|C|12|I|0|3|I|18|6|0|0|0|0|0|8|F|Q|4|2G|8|0|0|0|13|0|0|0|O|0|0|0|17|0|0|0|16|0|1|1E|0|0|1J|0|0|2X|0|0|2P|0^^$0|@$1|2|3|4|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1P|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1R|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1S|8|@]|D|@]|E|$]]|$1|P|3|Q|5|R|7|1T|8|@$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|20|8|@]|D|@]|E|$]]|$1|U|3|V|5|R|7|21|8|@$9|22|A|23|B|C]]|D|@]|E|$]]|$1|W|3|T|5|6|7|24|8|@]|D|@]|E|$]]|$1|X|3|Y|5|R|7|25|8|@$9|26|A|27|B|C]]|D|@]|E|$]]|$1|Z|3|T|5|6|7|28|8|@]|D|@]|E|$]]|$1|10|3|11|5|R|7|29|8|@$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|12|3|T|5|6|7|2C|8|@]|D|@]|E|$]]|$1|13|3|14|5|R|7|2D|8|@$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|15|3|16|5|6|7|2G|8|@$9|2H|A|2I|B|C]]|D|@]|E|$]]|$1|17|3|18|5|6|7|2J|8|@$9|2K|A|2L|B|C]]|D|@]|E|$]]|$1|19|3|1A|5|6|7|2M|8|@$9|2N|A|2O|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|2P|8|@$9|2Q|A|2R|B|C]]|D|@]|E|$]]|$1|1D|3|-4|5|6|7|2S|8|@]|D|@]|E|$]]]|1E|$]]

@Jason: this is true for the f-reachable queue. But IMHO it does not explain why there is the finalization-queue itself.

My guess is that the finalization-queue is there to add another information that helps the GC to distinguish between all the possible states of an object life-cycle.

The finalization flag in the object's header says "the object needs to be finalized" or "the object does not need to be finalized" but it does not say if the finalization has already occurred.

But to be honest I don't grasp why it's needed in the current finalization process implementation.

Indeed, here is the naive workflow I imagine possible without the finalization-queue:

<ul>
<li>when creating the object, if it has a finalizer, the GC sets the finalization flag;</li>
<li>if later SupressFinalize is called then the flag is zeroed;</li>
<li>now let's jump to when the GC collects the object, which is not referenced from anywhere: if the finalization flag is set then the GC puts a reference to the object into the f-reachable queue and lets the finalization thread operates;</li>
<li>later the finalization thread dequeues the reference, resets the finalization flag and runs the finalizer;</li>
<li>if the object wants to be refinalized later it could ReRegisterForFinalize to set the finalization flag again;</li>
<li>later the GC collects the object again: if the finalization flag is not set it knows there is nothing to do and then frees the object memory;</li>
<li>if the finalization flag is set the GC enqueues again a reference to the object into the f-reachable queue and there we go again for another round;</li>
<li>at some point in time the object is happy, completes the finalization and is collected; or the app-domain or process is shutdown and memory is freed anyway.</li>
</ul>

So seems like in these scenarios there is no need for a finalization-queue, only the finalization flag is useful.

One possible reason would be that from a conceptual point of view there might be a rule like: "an object is collected if and only if it is not referenced from any root".
So not having a finalization queue, and basing the decision to collect an object on the object state itself, checking the finalization flag, is not compatible with this rule.

But really I don't think the GC implementation is based on the dogmatic application of such theoretical rules but only on pragmatic choices; so it's obvious I'm missing some key scenarios where the GC needs the finalization queue to know what to do when collecting an object, but which ones?

blocks|key|5473252|text|垃圾收集器不识别和检查垃圾，可能处理大对象堆时除外。相反，它的行为就像是保龄球馆的排管员在两次投球之间清除死木的行为:排管员抓住所有仍然站立的针脚，将它们抬离球道表面，然后让清扫杆穿过球道，而不考虑球道表面有多少针。批量清理内存比确定要删除的单个对象要快得多。如果1%25的对象有终结器(实际数字可能更少)，那么有必要检查100个对象头来找到每个可终结化的对象。有一个单独的具有终结器的对象列表，使得GC甚至没有必要查看任何没有终结器的垃圾对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5473253|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The garbage-collector does not identify and examine garbage, except perhaps when processing the Large Object Heap. Instead, its behavior is like a that of a bowling-alley pinsetter removing deadwood between throws: the pinsetter grabs all the pins that are still standing, lifts them off the surface of the lane, and then runs the sweeper bar across the lane without regard for how many pins are on that surface. Sweeping out memory wholesale is much faster than identifying individual objects to be deleted. If 1% of objects have finalizers (the real number's probably even less), then it would be necessary to examine 100 object headers to find each finalizable object. Having a separate list of objects which have finalizers makes it unnecessary for the GC to even look at any garbage objects that don't.

As I understand, garbage collector in c# will put all objects of a class into finalization queue, as soon as I implement destructor of the class. When I was reading documentation for GC.Suppresfinalize, it mentions that object header already has a bit set for calling finalize.

I am wondering that why the implementers of GC had to put all objects in a queue, and delay the freeup of memory by 1-2 cycles. Could not they just look at the bit flag while releasing memory, then call finalize of the object and then release memory? 

No doubt I am an idiot and I not able to understand the working of GC. I am posing this question just to improve my understanding or fill the missing gap in my knowledge

EDIT : If the bit flag is for suppressfinalize, GC implementers could have added another flag in object header for this purpose, no?

Why does GC put objects in finalization queue?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

据我所知，只要我实现一个类的析构函数，c#中的垃圾回收器就会把这个类的所有对象放入终结化队列。当我阅读GC.Suppresfinalize的文档时，它提到object头已经为调用finalize设置了位。我想知道为什么GC的实现者必须将所有对象放在一个队列中，并将内存释放延迟1-2个周期。难道它们不能在释放内存时只查看位标志，然后调用对象的finalize，然后释放内存吗？毫无疑问，我是一个笨蛋，

问为什么GC会将对象放在finalization队列中？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么GC会将对象放在finalization队列中？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么GC会将对象放在finalization队列中？
EN