可终结对象如何被回收至少需要2个垃圾回收周期? [英] How finalizable objects takes at least 2 garbage collection cycles before it can be reclaimed?

问题描述

我正在阅读这篇文章，我可以不能真正理解可终结对象(覆盖finalize方法的对象)如何至少需要2个GC周期才能回收它.

I'm reading this article and I can't really understand how the finalizable objects (objects which override the finalize method) takes at least 2 GC cycles before it can be reclaimed.

在可以回收可终结对象之前，至少需要两个垃圾回收周期(最好是).

It takes at least two garbage collection cycles (in the best case) before a finalizeable object can be reclaimed.

有人还能详细解释吗?可终结对象如何可能需要多个GC周期进行回收?

Can someone also explain in detail how is it possible for a finalizable object to take more than one GC cycle for reclamation?

我的逻辑参数是，当我们覆盖finalize方法时，运行时将不得不向垃圾收集器注册该对象(以便GC可以调用此对象的finalize，这使我认为GC将引用到所有可终结的对象).为此，GC必须牢记对finalizable对象的强烈引用.如果是这种情况，那么该对象首先如何成为GC回收的候选对象?这个理论使我感到矛盾.

My logical argument is that when we override finalize method, the runtime will have to register this object with the garbage-collector (so that GC can call finalize of this object, which makes me think that GC will have reference to all the finalizable objects). And for this, GC will have to keep a strong reference to the finalizable object. If that is the case then how this object became a candidate for reclamation by GC in the first place? I reach a contradiction by this theory.

PS:我了解不推荐使用覆盖finalize的方法，并且从Java 9开始不推荐使用此方法.

PS: I understand that overriding finalize is not the recommended approach and this method is deprecated since Java 9.

推荐答案

您是对的，因为垃圾收集器需要引用可终结对象.当然，在确定对象在最终确定之前是否仍可到达时，不得考虑该特定参考.这意味着需要对这种引用到垃圾收集器的性质有专门的了解.

You are right in that the garbage collector needs a reference to finalizable objects. Of course, this particular reference must not be considered when deciding whether the object is still reachable before the finalization. This implies special knowledge about the nature of this reference to the garbage collector.

当垃圾回收器确定某个对象可以进行终结处理时，终结处理程序将运行，这意味着至少在执行终结处理程序之后，该对象才能再次强烈地可访问.完成确定后，对象必须再次变得不可访问，并且必须对其进行检测，然后才能回收对象的内存.因此，至少需要两个垃圾回收周期.

When the garbage collector determines that an object is eligible for finalization, the finalizer will run, which implies that the object becomes strongly reachable again, at least as long as the finalizer is executed. After its finalization, the object must become unreachable again and this must be detected, before the object’s memory can be reclaimed. That’s why it takes at least two garbage collection cycles.

在广泛使用的Hotspot/OpenJDK环境(可能还包括IBM JVM)的情况下，这是通过创建

In case of the widely used Hotspot/OpenJDK environment (and likely also in IBM’s JVM), this is implemented by creating an instance of a special, non-public subclass of Reference, a Finalizer, right when an object, whose class has a non-trivial finalize() method, is created. Like with weak & soft references, these references are enqueued by the garbage collector when no strong reference to the referent exist, but they are not cleared, so the finalizer thread can read the object, making it strongly reachable again for the finalization. At this point, the Finalizer is cleared, but also not referenced anymore, so it would get collected like an ordinary object anyway, so by the next time the referent becomes unreachable, no special reference to it exists anymore.

对于其类具有琐碎终结器"的对象，即java.lang.Object继承的finalize()方法或空的finalize()方法，JVM将采取捷径而不在其中创建Finalizer实例.首先，可以说，这些对象(占所有对象的大多数)从一开始就表现出它们的终结器已经运行.

For objects whose class has a "trivial finalizer", i.e. the finalize() method inherited by java.lang.Object or an empty finalize() method, the JVM will take a short-cut and not create the Finalizer instance in the first place, so you could say, these objects, which make the majority of all objects, behave as if their finalizer did already run, right from the start.

这篇关于可终结对象如何被回收至少需要2个垃圾回收周期?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！