可变速队列和终结队列 [英] freachable queue and finalization queue
问题描述
可变长队列和终止队列有什么区别？
One Solution：从Finalization Queue转换到FReachable Queue .net垃圾收集
这两个队列用于管理可终结对象。
Freachable是什么？你可能会问。 Freachable（发音为F-reachable）是垃圾收集的
最终化部分中使用的CLR垃圾收集器内部结构之一
。您可能听说过
的定稿队列，其中每个需要定稿
的对象最初登陆。这是根据他是否有一个Finalize
方法来确定的，或者它的对象类型包含一个Finalize方法定义为
更准确地说。这似乎是一个好主意，GC希望保留所有需要调用Finalize的对象的
跟踪，以便在收集
时可以轻松找到它们。为什么他需要另一个
集合呢？
显然当GC发现一个位于
可终结队列中的垃圾对象时，它会做些什么，比你想像的要复杂一些。 GC
不直接调用Finalize方法，而是从Finalizable队列中删除对象
引用，并将其放在一个（等待它..）
可快速排队的队列中。奇怪，是吧？那么事实证明，有一个专门的
CLR线程只负责监视Freachable
队列，当GC在那里添加新的项目时，他踢进来，并且通过一个对象获得一个
的对象，并调用它是Finalize方法。关于它的一个重点是
，你不应该依赖于同样的
线程调用的Finalize方法作为你应用程序的其余部分，不要指望线程本地存储等。
但是更让我感兴趣的是为什么？那么这篇文章并没有给出
的答案，但是我想到了两件事情。首先
是性能，你显然希望垃圾回收尽可能快速地达到
，并且大量的工作都投入到了这个过程中。
像b $ b这样的后台线程处理终止任务，似乎很自然，所以主要任务可以尽可能快地完成。
其次，但并非不那么重要的是，从GC的角度来看Finalize毕竟是一个客户端
的代码，CLR不能真正相信您亲爱的读者
的实现。也许你的Finalize会抛出异常，或者将
变成无限循环？这不是你想成为GC
过程的一部分，如果它只能影响后台
线程，它的危险性就会降低。
What is difference between freachable queue and finalization queue? One Solution:Transition from Finalization Queue to FReachable Queue .net Garbage Collection
Both queues are for the purpose of managing finalizable objects.
Reference : What do you know about Freachable queue?
Freachable what? You might ask. Freachable (pronounced F-reachable) is one of CLR Garbage Collector internal structures that is used in a finalization part of garbage collection. You might have heard about the Finalization queue where every object that needs finalization lands initially. This is determined based on whether he has a Finalize method, or it’s object type contains a Finalize method definition to speak more precisely. This seems like a good idea, GC wants to keep track of all objects that he needs to call Finalize on, so that when he collects he can find them easily. Why would he need another collection then?
Well apparently what GC does when he finds a garbage object that is on Finalizable queue, is a bit more complicated than you might expect. GC doesn’t call the Finalize method directly, instead removes object reference from Finalizable queue and puts it on a (wait for it.. ) Freachable queue. Weird, huh? Well it turns out there is a specialized CLR thread that is only responsible for monitoring the Freachable queue and when GC adds new items there, he kicks in, takes objects one by one and calls it’s Finalize method. One important point about it is that you shouldn’t rely on Finalize method being called by the same thread as rest of you app, don’t count on Thread Local Storage etc.
But what interest me more is why? Well the article doesn’t give an answer to that, but there are two things that come to my mind. First is performance, you obviously want the garbage collection to be as fast as possible and a great deal of work was put into making it so. It seems only natural to keep side tasks like finalization handled by a background thread, so that main one can be as fast a possible. Second, but not less important is that Finalize is after all a client code from the GC perspective, CLR can’t really trust your dear reader implementation. Maybe your Finalize will throw exception or will go into infinite loop? It’s not something you want to be a part of GC process, it’s much less dangerous if it can only affect a background thread.
这篇关于可变速队列和终结队列的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
