Talk:Finalizer

Object resurrection problem artificial?

From the current article version:

Languages with finalizers must also address the problem of object resurrection. Resurrection occurs when an object's finalizer causes the object to become reachable (that is, not garbage). The garbage collector must determine if the object has been resurrected by the finalizer or risk creating a dangling reference.

At least from a Java viewpoint, isn't this consideration quite artificial? Can someone come up with an example Object.finalize() implementation that could possibly cause such a problem? I can only see this problem (an object becoming reachable again after exuciting its finalize() method) if the finalize() method called some other object's method passing a this reference. --Abdull (talk) 15:57, 13 April 2012 (UTC)

The object does not became reachable after execution of the finalize method, it is already reachable during execution of the finalize method. For creating a heap reference persisting longer than the method execution, the method has all possibilities Java offers

public class BadFinalize {
  static BadFinalize REFERENCE;
  protected void finalize() throws Throwable {
    REFERENCE = this;
  }
}

But it doesn’t matter whether the finalizer really does this, the VM has to prove safely that it didn’t. At the cost of an extra garbage collection cycle. This is another reason not to use finalizers. — Preceding unsigned comment added by 77.188.68.217 (talk) 14:10, 1 August 2012 (UTC)

Proposed merge with Finalization

Finalization is what a finalizer does. These two articles discuss exactly the same topic. QVVERTYVS (hm?) 09:21, 11 November 2015 (UTC)

Agreed and  Done Klbrain (talk) 09:19, 28 December 2017 (UTC)