问题
The main question is in the topic but let me show my vision of finalization proccess in Java so that I can ask you a little more.
Well the gc starts garbage collection by marking all live objects. When all reachable objects are marked as "live". All other objects are unreachable. The next step is to check every unreachable object and determine whether it can be sweeped right now or it should be finalized at first. The gc thinks the next way if the object's finalize method has a body then this object is finalizable and should be finalized; if the object's finalize method has an empty body (protected void finalize(){ }) then it is not finalizable and can be sweeped by gc right now. (Am I right about it?)
All finalizable objects will be put in the same queue to be finalized later one by one. As I understand a finalizable object can spend a lot of time being placed to the queue while waiting for its turn to be finalized. This can happen because normally only one thread called Finalizer are taking objects from the queue and call their finalize method, and when we have some time consuming operations in some object's finalize method the other objects in the queue will be waiting pretty long to be finalized. Well when an object has been finalized it is marked as FINALIZED and removed from the queue. During the next garbage collection process the collector will see that this object is unreachable (again) and has non-empty finalize method (again) so this object should be put in the queue (again) - but it won't because the collector somehow see that this object was marked as FINALIZED. (This is my main question: in what way this object was marked as FINALIZED, how the collector knows that this object shouldn't be finalized again?)
回答1:
As long as we are talking about HotSpot JVM ...
Object itself IS NOT marked as finalized.
Each time when you create new finalize object, JVM creates an extra object FinalizerRef (which is somewhat similar with Weak/Soft/Phantom references).
Once your object is proven to unreachable with strong references special references to this object are processed. FinalizerRef for you object will be added to finalizer queue (which is linked list, same as with other reference types).
When finalizer thread consumes FinalizerRef from queue it would null its null pointer to object (though thread will keep strong reference to object until finalizer is finished).
Once FinalizerRef is nullified, object cannot get to finalizer queue any more.
BTW
You can see preference processing times (and number of references) in GC logs with -XX:+PrintReferenceGC (see more GC diagnostic JVM options)
回答2:
The JVM stores meta data in the object header. Any object with a sub-classes finalize() is called, even if empty. Placing in the queue doesn't take long, but it can wait in the queue for a long time.
回答3:
I don't know how exactly the real, implemented finalizing process works, but if i had to do it, i'd do it this way - store a tri-state flag in the object metadata that tells GC if the object just stopped being in use, needs the finalizer to be run, or may be removed. You'll probably have to check the java source for details but this should be the overall pattern:
(in new)
object.metadata.is_finalized=NEEDS_FINALIZE;
(in gc)
while ((object=findUnreachableObject())!=null) {
if (object.metadata.is_finalized==NEEDS_FINALIZE) {
if (hasNonNullBody(object.finalize)) {
Finalizer.addForProcessing(object);
object.metadata.is_finalized=IN_FINALIZER_QUEUE;
} else {
object.metadata.is_finalized=REMOVE_NOW;
}
}
if (object.metadata.is_finalized==REMOVE_NOW) {
// destroy the object and free the memory
}
}
(in Finalizer)
while ((object=getObjectForProcessing)!=null) {
object.finalize();
object.metadata.is_finalized=REMOVE_NOW;
}
来源：https://stackoverflow.com/questions/21809922/how-is-an-object-marked-as-finalized-in-java-so-that-the-finalize-method-wouldn