Why does finalize() execute only after new object is created, but not after gc() is invoked?

Question

Shouldn't finalize() execute immediately when gc() is called? The order of output result is a little unconvincing.

class Test
{
    int x = 100; 
    int y = 115;

    protected void finalize()
    {System.out.println("Resource Deallocation is completed");}
}

class DelObj
{
    public static void main(String arg[])
    {
        Test t1 = new Test();           
        System.out.println("Values are "+t1.x+", "+t1.y+"\nObject refered by t1 is at location: "+t1);
        t1 = null; // dereferencing
        System.gc(); // explicitly calling

        Test t2= new Test();
        System.out.println("Values are "+t2.x+", "+t2.y+"\nObject refered by t2 is at location: "+t2);

    } 
}

Got the execution result of finalize() after a new object is created, referred by t2:

D:\JavaEx>java DelObj
Values are 100, 115
Object refered by t1 is at location: Test@6bbc4459
Values are 100, 115
Object refered by t2 is at location: Test@2a9931f5
Resource Deallocation is completed

Answer 1

Calling System.gc() only provides a hint to the JVM, but does not guaranty that an actual garbage collection will happen.

However, the bigger problem with your expectation is that garbage collection is not the same as finalization.

Referring to the Java 6 documentation, System.gc() states:

Runs the garbage collector.

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. …

Compare to System.runFinalization():

Runs the finalization methods of any objects pending finalization.

Calling this method suggests that the Java Virtual Machine expend effort toward running the finalize methods of objects that have been found to be discarded but whose finalize methods have not yet been run. …

So there can be “pending finalization”, resp. “objects that have been found to be discarded but whose finalize methods have not yet been run”.

Unfortunately, Java 6’s documentation of finalize() starts with the misleading sentence:

Called by the garbage collector on an object when garbage collection determines that there are no more references to the object.

whereas garbage collection and finalization are two different things, hence, the finalize() method is not called by the garbage collector. But note that the subsequent documentation says:

The Java programming language does not guarantee which thread will invoke the finalize method for any given object.

So when you say “The order of output result is a little unconvincing”, recall that we’re talking about multi-threading here, so in absence of additional synchronization, the order is outside your control.

The Java Language Specification even says:

The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused.

and later on

The Java programming language imposes no ordering on finalize method calls. Finalizers may be called in any order, or even concurrently.

In practice, the garbage collector will only enqueue objects needing finalization, while one or more finalizer threads poll the queue and execute the finalize() methods. When all finalizer threads are busy executing particular finalize() methods, the queue of objects needing finalization may grow arbitrary long.

Note that modern JVMs contain an optimization for those classes not having a dedicated finalize() method, i.e. inherit the method from Object or just have an empty method. Instances of these classes, the majority of all objects, skip this finalization step and their space gets reclaimed immediately.

So if you added a finalize() method just to find out when the object gets garbage collected, it’s the very presence of that finalize() method which slows down the process of the memory reclamation.

So better refer to the JDK 11 version of finalize():

Deprecated.

The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no ordering is specified among calls to finalize methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization. The finalize method might be called on a finalizable object only after an indefinite delay, if at all. Classes whose instances hold non-heap resources should provide a method to enable explicit release of those resources, and they should also implement AutoCloseable if appropriate. The Cleaner and PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable.

So when your object does not contain a non-memory resource, hence, doesn’t actually need finalization, you can use

class Test
{
    int x = 100;
    int y = 115;
}

class DelObj
{
    public static void main(String[] arg)
    {
        Test t1 = new Test();
        System.out.println("Values are "+t1.x+", "+t1.y+"\nObject refered by t1 is at location: "+t1);
        WeakReference<Test> ref = new WeakReference<Test>(t1);
        t1 = null; // dereferencing
        System.gc(); // explicitly calling
        if(ref.get() == null) System.out.println("Object deallocation is completed");
        else System.out.println("Not collected");

        Test t2= new Test();
        System.out.println("Values are "+t2.x+", "+t2.y+"\nObject refered by t2 is at location: "+t2);

    }
}

The System.gc() call still is only a hint, but you will find your object being collected afterwards in most practical cases. Note that the hash code printed for the objects, like with Test@67f1fba0 has nothing to do with memory locations; that’s a tenacious myth. The patterns behind object memory addresses is often unsuitable for hashing, further most modern JVMs can move objects to different memory locations during their lifetime, whereas the identity hash code is guaranteed to stay the same.