When Is the Finalize() Method Called in Java

When is the finalize() method called in Java?

In general it's best not to rely on finalize() to do any cleaning up etc.

According to the Javadoc (which it would be worth reading), it is:

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

As Joachim pointed out, this may never happen in the life of a program if the object is always accessible.

Also, the garbage collector is not guaranteed to run at any specific time. In general, what I'm trying to say is finalize() is probably not the best method to use in general unless there's something specific you need it for.

Is 'finalize()' method always called by garbage collector before destroying an 'Unreachable' object?

When the GC has found an object with class where finalize() has been overridden it is added to a queue of objects to have finalize() called on them. It is only after the object has been finalized once, that the GC can clean it up. i.e. this would be on a later GC.

e.g. If an object is in tenured space, it might be found until a full collection is performed, and it will only be cleaned up on a full GC after the finalize method has been called.

For further details, this is the Java 11 Javadoc for Object.finalize()

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Object.html#finalize()

so is there any possibility that garbage collector fully destroyed the object in heap but didn't call the finalize() method on that object?

While the object is in the finalization queue, it can't be removed.

And you all assumed that there is not certainity in the destroying of object by the garbage collector.

It won't be destroyed while there is still a strong reference to it.

Can the finalize() method be called twice if the garbage collector retains memory twice in the same code?

No. The finalize() method will only be called once by the GC on an object. The JVM sets a flag in the object header (I think) to say that it has been finalized, and won't finalize it again.

The javadoc states this explicitly:

" The finalize method is never invoked more than once by a Java virtual machine for any given object. "

Of course, there is nothing to stop an object method from calling this.finalize() any number of times.

Note that finalize() is deprecated in Java 9 and later for reasons stated in the javadoc. It is recommended that you switch to using one of the following instead:

AutoCloseable + try with resources
Cleaner
PhantomReference

Someone commented thus:

finalize() is called for every Object that is collected.

This is not true for a couple of reasons.

The javadoc explicitly states that there are no guarantees that finalize will ever be called. The thing that is guaranteed is that it will be called (once) before an object's storage is reclaimed. That is a weaker statement than the statement that the comment makes.
One scenario where garbage collected objects may not be finalized is if the JVM exits soon after a GC run.
Another (pathological) scenario occurs when a classes finalize method never returns¹. When an instance of that class is finalized, the finalizer thread will get stuck. When all finalizer threads are stuck in that way, no more finalizable objects can be finalized².
If the Object::finalize is not overridden in a class, the JVM will skip the finalization step for that class.

^{1 - This could be due to an infinite loop, or because the finalize() method gets stuck waiting on a lock or waiting for an internal or external "event" that never happens. Note also that "never" could mean "not for a long time" in this context. The overall impact can be the same.

2 - The objects will sit in the finalization queue indefinitely. This is a memory leak.}

when finalize() is being executed?

According to Bruce Eckel:

In Java, Objects do not always get garbage collected.

It generally means, that even if you declare your finalize() method, it might never be called. In this case your cleanup routine will never be executed. It is all up to JVM GC.
Even though GC might run, it might not collect the given object. And as long as the Object, which is not referenced anymore, is still not collected, its finalize() is never called.

Moreover, before the termination of the program, the garbage collection might not be called at all. In this case the memory is returned to the operating system as a whole, without any GC. And without any finalization method calls.

So, the answer to the first question of yours is no.

Your second answer was right. If the object is still in use, no matter if GC runs, it cant be collected (and finalize() called), unless you use WeakReference or something like that.

Java 8 is this assertion about finalize method correct?

This is really more of a theoretical thing: objects are eligible for garbage collection when they aren't referenced from other live objects anymore.

Thus: you could try to create such a reference within finalize(). Which would then theoretically prevent the object from being removed.

There is actually a "pattern name" for that: object resurrection. Now, if this is a pattern, or more of an anti pattern is open for debate.

(personally: I would never do that, and I have never been in a situation where it would have been necessary to use this pattern)

Why finalize() is not called?

The finalize() method is only called when the object is destroyed and finalized by the GC, which happens at some undefined point in time after the last reference to the object is discarded. If the object is never released (e.g. you still have a reference to it), then finalize() is never called.

Also bear in mind you have no control over when finalize() is called, or if it will ever even be called at all. See general description of Object.finalize().

Even System.gc() is not guaranteed to force the GC to do anything. It is only a suggestion to the JVM. See general description of System.gc()

In general, if you find yourself attempting to manipulate the GC like this in order to perform these types of checks, there are generally better ways. This is an inappropriate use of finalize() and the GC.

For example, if you're trying to check if a presumed condition is true, consider using assert in appropriate places (but be forewarned: assert is not a replacement for a functional if; it is merely to self-document and test conditions assumed at design time).

If part of your application's higher level functionality is to verify that a condition is true before exiting, then you should explicitly verify that the condition is true before exiting, e.g. in your case:

public static void main(String[] args)
{   
    Tank tank=new Tank();
    tank.fill();
    // check explicitly before terminating
    if (!tank.empty()) 
        System.err.println("Warning: Ending with non-empty tank!");
}

An explicit check gives you full control over when it happens in addition to the ability to attempt a recovery from the error.

Update: Another good option, which MadProgrammer helpfully brought up in the comments below, is to use a shutdown hook, if that's appropriate for you. That will provide a clean way to exit code on shutdown if your application has multiple exit points that you can't otherwise eliminate or control.

For more complex applications, by the way, you will find testing strategies such as unit testing, etc., when combined with good modular design (e.g. clearly defined preconditions, postconditions, invariants), can provide complete tests of application logic without requiring self-testing to be part of the normal run of the application. Not that there's anything wrong with the latter, especially in simple applications, but it is something you may be interested in finding out about for future reference.