title: Is it possible to keep track of an object from its finalizer, to detect accidental resurrection of the object by a different object's finalizer?
body: <p>One of the many issues with <code>finalize</code> methods in Java is the "object resurrection" issue (explained in <a href="https://stackoverflow.com/q/1002567">this question</a>): if an object is finalized, and it saves a copy of <code>this</code> somewhere globally reachable, the reference to the object "escapes" and you end up with a finalized but living object (that won't be finalized again, and otherwise is something of a problem).</p>
  
  <p>In order to avoid the creation of resurrected objects, the normal advice (as, e.g., seen in <a href="https://stackoverflow.com/a/1002700">this answer</a>) is to create a fresh instance of the object, rather than save the object itself; this would typically be accomplished by copying all the object's fields into a fresh object. In most cases, this achieves the goal of allowing the original object to be deallocated, rather than resurrected.</p>
  
  <p>However, the Java garbage collector supports garbage collection of reference cycles; this means that an object can be finalized while (directly or indirectly) containing a reference to itself, and two objects can be finalized while (directly or indirectly) containing references to each other. In this case, the "copy all the fields into a new object" advice doesn't actually solve the problem; although we discard the <code>this</code> reference once the finalizer finishes running, the partially finalized object will be resurrected via the reference from the field. So we end up with the object being resurrected anyway.</p>
  
  <p>In the case where the object indirectly holds a reference to itself, it's possible to recursively look through all the fields of the object until we find the self-reference (in which case we can replace it with a reference to the new object we're constructing), thus preventing the resurrection. So that solves the issue in that case.</p>
  
  <p>However, if two objects hold references to each other (and thus both get deallocated at the same time), and we're creating a new instance of each, then each of the new objects will be holding a reference to the old, finalized object (rather than the new object that's been constructed as a replacement). This is obviously an undesirable state of affairs, so one thing I've been looking into is attempting to use the same solution as in the single-object case: recursively scanning the fields of the (living, newly constructed) objects looking for finalized objects, and replacing them with the corresponding replacement objects.</p>
  
  <p>The problem is: how can I recognise a finalized/resurrected object, when I'm doing this? The obvious way to do this is to somehow record the identity of the finalized object in the finalizer, and then compare all the objects we find during the recursive scan with a list of finalized objects. The problem is, there doesn't seem to be a valid way to record the identity of the object in question:</p>
  
  <ul>
  <li>A regular (strong) reference would hold the object alive, effectively resurrecting it automatically, and gives no method via which to determine that the object is not in fact referenced. This would solve the problem of identifying the resurrected objects, but comes with a problem of its own: although the resurrected objects would never be used, except for their identities, there would be no means via which to deallocate them (e.g. you can't use a <code>PhantomReference</code> to detect that the object is now truly dead, like you normally would in Java, because the object is now strongly reachable and thus the phantom reference never clears). So this would effectively mean that the objects in question stay allocated forever, causing a memory leak.</li>
  <li>Using a weak reference was my first idea, but has the problem that at the time we construct the <code>WeakReference</code> object, the referenced object is not in fact strongly, softly, nor weakly reachable. As such, as soon as we store the <code>WeakReference</code> anywhere that's strongly reachable (to prevent the <code>WeakReference</code> itself being deallocated), the <code>WeakReference</code>'s target becomes weakly reachable and the reference automatically clears. So we can't store any information that way.</li>
  <li>Using a phantom reference has the problem that there's no way to compare a phantom reference with an object to see if that reference references that object. (Maybe there should be – unlike <code>get()</code>, which can resurrect an object, there's never any danger in this operation because we clearly have a reference to the object anyway – but it doesn't exist in the Java API. Likewise, <code>.equals()</code> on <code>PhantomReference</code> objects is <code>==</code>, not value equality, so you can't use it to determine whether two phantom references reference the same thing.)</li>
  <li>Using <code>System.identityHashCode()</code> to record a number corresponding to the object's identity almost works – deallocation of the object won't change the recorded number, the number won't prevent the object's deallocation, and resurrecting an object leaves the value the same – but unfortunately, being a <code>hashCode</code>, it's subject to collisions, so might have false positives in which an object appears to be resurrected when it isn't.</li>
  <li>One final possibility is to modify the object itself to mark it as finalized (and track the location of its replacement), meaning that observing this mark on a strongly reachable object would reveal it as a resurrected object, but this requires adding an additional field to any object that might be involved in a reference cycle.</li>
  </ul>
  
  <hr>
  
  <p>As a summary, my underlying problem is "given an object that's currently being finalized, safely create a copy of it, without accidentally resurrecting any objects that may be in a reference cycle of it in the process". The approach I've been trying to use is "when an object that might potentially be involved in a cycle is finalized, keep track of that object's identity so that it can subsequently be replaced with its copy if it turns out to be reachable from another finalized object"; but none of the five approaches mentioned above seems satisfactory.</p>
  
  <p>Is there some other way to keep track of finalized objects, so that they can be recognised if accidentally redirected? Is there an entirely different solution to the original problem, of safely making a copy of an object during its finalization?</p>