finalize() is one of the 9 methods in java.lang.Object class. The api docs for the function state:
Called by the garbage collector on an object when garbage collection determines that there are no more references to the object.
But what does the finalize() method actually do?
What happens if we manually call the finalize() method?
it doesn't do anything by default but it gives you an interception point if you want to perform some action
this is the implementation of finalize() in java.lang.Object
protected void finalize() throws Throwable { }
The general contract of finalize is that it is invoked if and when the JavaTM virtual machine has determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, except as a result of an action taken by the finalization of some other object or class which is ready to be finalized. The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded.
See Also
demo code (might not work in all cases)
When is the finalize() method called in Java?
I think there is one rule: Never, ever, use it in normal situations. Only for educational purposes and for debugging purposes, it is acceptable.
By default, it does nothing. You can override it in order to find out wether your garbage collector is cleaning up the object. But never put cleanup logic in that method. So, it might be useful to find check if you are releasing the memory or not of specific objects, if you are having memory trouble.
I encountered this question in an interview with following options:
How to destroy an object in java?
a. System.gc();
b. Runtime.getRuntime.gc();
c. object.delete();
d. object.finalize();
e. Java performs gc by itself, no need to do it manually.
The answer should be e?
what if e was not there? then ?
clearly c is not the answer. a and b will do gc for the whole application(question requires for one object).
I think it is d because finalize() is called just prior to gc(but is it necessary that after finalize gc is invoked ?) or I am wrong ? e must be there to answer this question ?
Answer E is correct answer. If E is not there, you will soon run out of memory (or) No correct answer.
Object should be unreachable to be eligible for GC. JVM will do multiple scans and moving objects from one generation to another generation to determine the eligibility of GC and frees the memory when the objects are not reachable.
To clarify why the other answers can not work:
System.gc() (along with Runtime.getRuntime().gc(), which does the exact same thing) hints that you want stuff destroyed. Vaguely. The JVM is free to ignore requests to run a GC cycle, if it doesn't see the need for one. Plus, unless you've nulled out all reachable references to the object, GC won't touch it anyway. So A and B are both disqualified.
Runtime.getRuntime.gc() is bad grammar. getRuntime is a function, not a variable; you need parentheses after it to call it. So B is double-disqualified.
Object has no delete method. So C is disqualified.
While Object does have a finalize method, it doesn't destroy anything. Only the garbage collector can actually delete an object. (And in many cases, they technically don't even bother to do that; they just don't copy it when they do the others, so it gets left behind.) All finalize does is give an object a chance to clean up before the JVM discards it. What's more, you should never ever be calling finalize directly. (As finalize is protected, the JVM won't let you call it on an arbitrary object anyway.) So D is disqualified.
Besides all that, object.doAnythingAtAllEvenCommitSuicide() requires that running code have a reference to object. That alone makes it "alive" and thus ineligible for garbage collection. So C and D are double-disqualified.
Short Answer - E
Answer isE given that the rest are plainly wrong, but ..
Long Answer - It isn't that simple; it depends ...
Simple fact is, the garbage collector may never decide to garbage collection every single object that is a viable candidate for collection, not unless memory pressure is extremely high. And then there is the fact that Java is just as susceptible to memory leaks as any other language, they are just harder to cause, and thus harder to find when you do cause them!
The following article has many good details on how memory management works and doesn't work and what gets take up by what. How generational Garbage Collectors work and Thanks for the Memory ( Understanding How the JVM uses Native Memory on Windows and Linux )
If you read the links, I think you will get the idea that memory management in Java isn't as simple as a multiple choice question.
Set to null. Then there are no references anymore and the object will become eligible for Garbage Collection. GC will automatically remove the object from the heap.
Here is the code:
public static void main(String argso[]) {
int big_array[] = new int[100000];
// Do some computations with big_array and get a result.
int result = compute(big_array);
// We no longer need big_array. It will get garbage collected when there
// are no more references to it. Since big_array is a local variable,
// it refers to the array until this method returns. But this method
// doesn't return. So we've got to explicitly get rid of the reference
// ourselves, so the garbage collector knows it can reclaim the array.
big_array = null;
// Loop forever, handling the user's input
for(;;) handle_input(result);
}
In java there is no explicit way doing garbage collection. The JVM itself runs some threads in the background checking for the objects that are not having any references which means all the ways through which we access the object are lost. On the other hand an object is also eligible for garbage collection if it runs out of scope that is the program in which we created the object is terminated or ended.
Coming to your question the method finalize is same as the destructor in C++. The finalize method is actually called just before the moment of clearing the object memory by the JVM. It is up to you to define the finalize method or not in your program. However if the garbage collection of the object is done after the program is terminated then the JVM will not invoke the finalize method which you defined in your program.
You might ask what is the use of finalize method?
For instance let us consider that you created an object which requires some
stream to external file and you explicitly defined a finalize method to this object which checks wether the stream opened to the file or not and if not it closes the stream. Suppose, after writing several lines of code you lost the reference to the object. Then it is eligible for garbage collection. When the JVM is about to free the space of your object the JVM just checks have you defined the finalize method or not and invokes the method so there is no risk of the opened stream. finalize method make the program risk free and more robust.
Hi I have one doubt about phantom reference. What I understand the finalize method is called just before when object are going for garbage collection. But some time if object are not eligible for garbage collection then finalize method will not execute.
Now talking about phantom reference when this finalize method will called.
Is finalize always called in phantom reference.
I am very much confuse about this. Please help me.
Finalizers are never guaranteed to be called, whether there is a phantom reference or not. Don't rely on finalizers for any critical part of your code because there is no guarantee that they will be called in a timely manner or in fact at all.
Many people advocate that you simply should never use finalizers at all because they are incredibly difficult to use correctly.
When object becomes available only through phantom reference then after the first GC finalize() method is invoked and after the second GC the reference is enqueued. If after that phantom reference is cleaned (or becomes unavailable itself) then the memory is cleared after the third GC.
Finalize will always be called, but not neccessarely, when you expect it. It may happen, that the call will only be made at the JVM shutdown (assuming you don't simply kill the program). You should not rely on finalize() in order to do significant work. But it is also good practice to implement a usefull finalize() and include a call to super.finalize() too.
What happened internally (JVM) when System.gc() or finalize() method called?
Is this really collect garbage or reduce performance ?
Exactly what happens when you call System.gc() is JVM dependent. The JVM looks at this call as a suggestion that it might be a good time to run the garbage collector, so don't depend on it.
An object's finalize() method is run on an object by the garbage collector when the JVM determines that there are no more reachable references to that object. You shouldn't call it in your code. Keep in mind that finalize() is not called at the time when your program loses that final reference, but at a future time when the garbage collector is run, so don't depend on it happening at a specific point in time (or at all).
If you want to know garbage collection internals, you should read Hotspot Memory Management Whitepaper from Sun.
By invoking System.gc() the garbage collector is run, as the name says. At this point, when the objects are really being removed, the finalize() is called on these objects before they vanish.
The last question shouldn't have an "or" in it. It is garbage collection and reduced performance.
Usually you shouldn't care about gc at all because it does a really good job for you. There are usage scenarios where you want to get rid of a lot of objects at a certain point in time; Then it is feasible.
System.gc() cleans up memory, and uses finalize() to get rid of the individual objects.
finalize() is a means to execute final bit of code just before the object is ready for garbage collection ( when the object has no strong reference to it).
So when should it be used?
Only in the present two cases:
As a safety to make sure that some service is closed down or some
desired final change is made. For example InputStream class uses it
to close down the i/o stream. That is for example you have made an
instance of BufferedInputStream. Manually after using it one is
suppose to close() it. But because one can forget to do that,
finalize() act’s as a safety net to close() the stream.
While
using Native’s. Because garbage collector has no control over native
objects, finalize() can be used as a means to reclaim it.
Apart from the above two cases never use it. To understand why? we need to understand the functioning and lifecycle of an object.
Introduction: There is a separate daemon thread called as finalizer thread which is responsible for calling finalize() method . Finalization queue is the queu where objects which are ready to be called finalize() method are placed.
When an Object is created, JVM checks if the object has a finalize() method. If it has then it internally notes that this particular object has finalize() method.
When an object is ready for garbage collection, then the garbage collector thread checks if this particular object has finalize() from table mentioned in (1).
2a) If it doesn’t then it is sent for garbage collection.
2b) It is has, then it is added to the finalization queue. And it removes the entry of the object from the table (1).
Finalizer thread keeps polling the queue. For every object in the queue, its finalize() method is called. After calling the finalize() cycle from (2) is again repeated. If this object still has no strong reference, then sent for GC. If
it has then ALWAYS (2a) is called because the entry was deleted in (2b)
Basically finalize() method is only called once.
So what’s the issue with the above cycle?
From (1). Its take extra time in object creation. Memory allocation in Java is 5x to 10x faster than malloc/calloc etc. All the time gained is lost in the procedure of noting the object in the table etc. I once tried it. Create 100000 objects in a loop and measure the time taken for program to terminate in 2 cases: One with no finalize(), Second with finalize(). Found it to be 20% faster.
From (2b): Memory Leakage and Starvation. If the object in the queue has references to a lot of memory resources, then all those objects wont get freed unless this object is ready for GC.If all the objects are heavy weight objects, then there can be a shortage.
From (2b): Because finalize() is called only once, what if in teh finalize() you had a strong reference to “this” object. Next time the object’s finalie() is never called hence can leave the object in an inconsistent state.
If inside finalize() an exception is thrown, it is ignored.
You do not know when finalize() is called as you have no control over when GC is called. Sometimes it might happen that you are printing the value’s in finalize() but the output is never shown, because your program might have got terminated by the time finalize() is called.
Hence avoid using it. Instead create a method say dispose() which will close the necessory resources or for final log etc.
the complete post on it. I hope this clears.
Yes System.gc(); will trigger finalize() method if required.
public class TestGarbageCollection {
public static void main(String[] args) {
while (true) {
TestClass s = new TestClass();
s.display();
System.gc();
}
}
}
public class TestClass {
public TestClass() {
System.out.println("constructor");
}
public void display() {
System.out.println("display");
}
#Override
public void finalize() {
System.out.println("destructor");
}
}
This will trigger finalize() method. whether you override finalize or not finalize method of local class or Object's finalize will be called.
I've been reading through a lot of the rookie Java questions on finalize() and find it kind of bewildering that no one has really made it plain that finalize() is an unreliable way to clean up resources. I saw someone comment that they use it to clean up Connections, which is really scary since the only way to come as close to a guarantee that a Connection is closed is to implement try (catch) finally.
I was not schooled in CS, but I have been programming in Java professionally for close to a decade now and I have never seen anyone implement finalize() in a production system ever. This still doesn't mean that it doesn't have its uses, or that people I've worked with have been doing it right.
So my question is, what use cases are there for implementing finalize() that cannot be handled more reliably via another process or syntax within the language?
Please provide specific scenarios or your experience, simply repeating a Java text book, or finalize's intended use is not enough, as is not the intent of this question.
You could use it as a backstop for an object holding an external resource (socket, file, etc). Implement a close() method and document that it needs to be called.
Implement finalize() to do the close() processing if you detect it hasn't been done. Maybe with something dumped to stderr to point out that you're cleaning up after a buggy caller.
It provides extra safety in an exceptional/buggy situation. Not every caller is going to do the correct try {} finally {} stuff every time. Unfortunate, but true in most environments.
I agree that it's rarely needed. And as commenters point out, it comes with GC overhead. Only use if you need that "belt and suspenders" safety in a long-running app.
I see that as of Java 9, Object.finalize() is deprecated! They point us to java.lang.ref.Cleaner and java.lang.ref.PhantomReference as alternatives.
finalize() is a hint to the JVM that it might be nice to execute your code at an unspecified time. This is good when you want code to mysteriously fail to run.
Doing anything significant in finalizers (basically anything except logging) is also good in three situations:
you want to gamble that other finalized objects will still be in a state that the rest of your program considers valid.
you want to add lots of checking code to all the methods of all your classes that have a finalizer, to make sure they behave correctly after finalization.
you want to accidentally resurrect finalized objects, and spend a lot of time trying to figure out why they don't work, and/or why they don't get finalized when they are eventually released.
If you think you need finalize(), sometimes what you really want is a phantom reference (which in the example given could hold a hard reference to a connection used by its referand, and close it after the phantom reference has been queued). This also has the property that it may mysteriously never run, but at least it can't call methods on or resurrect finalized objects. So it's just right for situations where you don't absolutely need to close that connection cleanly, but you'd quite like to, and the clients of your class can't or won't call close themselves (which is actually fair enough - what's the point of having a garbage collector at all if you design interfaces that require a specific action be taken prior to collection? That just puts us back in the days of malloc/free.)
Other times you need the resource you think you're managing to be more robust. For example, why do you need to close that connection? It must ultimately be based on some kind of I/O provided by the system (socket, file, whatever), so why can't you rely on the system to close it for you when the lowest level of resource is gced? If the server at the other end absolutely requires you to close the connection cleanly rather than just dropping the socket, then what's going to happen when someone trips over the power cable of the machine your code is running on, or the intervening network goes out?
Disclaimer: I've worked on a JVM implementation in the past. I hate finalizers.
A simple rule: never use finalizers.
The fact alone that an object has a finalizer (regardless what code it executes) is enough to cause considerable overhead for garbage collection.
From an article by Brian Goetz:
Objects with finalizers (those that
have a non-trivial finalize() method)
have significant overhead compared to
objects without finalizers, and should
be used sparingly. Finalizeable
objects are both slower to allocate
and slower to collect. At allocation
time, the JVM must register any
finalizeable objects with the garbage
collector, and (at least in the
HotSpot JVM implementation)
finalizeable objects must follow a
slower allocation path than most other
objects. Similarly, finalizeable
objects are slower to collect, too. It
takes at least two garbage collection
cycles (in the best case) before a
finalizeable object can be reclaimed,
and the garbage collector has to do
extra work to invoke the finalizer.
The result is more time spent
allocating and collecting objects and
more pressure on the garbage
collector, because the memory used by
unreachable finalizeable objects is
retained longer. Combine that with the
fact that finalizers are not
guaranteed to run in any predictable
timeframe, or even at all, and you can
see that there are relatively few
situations for which finalization is
the right tool to use.
The only time I've used finalize in production code was to implement a check that a given object's resources had been cleaned up, and if not, then log a very vocal message. It didn't actually try and do it itself, it just shouted a lot if it wasn't done properly. Turned out to be quite useful.
I've been doing Java professionally since 1998, and I've never implemented finalize(). Not once.
The accepted answer is good, I just wanted to add that there is now a way to have the functionality of finalize without actually using it at all.
Look at the "Reference" classes. Weak reference, Phantom Reference & Soft Reference.
You can use them to keep a reference to all your objects, but this reference ALONE will not stop GC. The neat thing about this is you can have it call a method when it will be deleted, and this method can be guaranteed to be called.
As for finalize:
I used finalize once to understand what objects were being freed. You can play some neat games with statics, reference counting and such--but it was only for analysis, but watch out for code like this (not just in finalize, but that's where you are most likely to see it):
public void finalize() {
ref1 = null;
ref2 = null;
othercrap = null;
}
It is a sign that somebody didn't know what they were doing. "Cleaning up" like this is virtually never needed. When the class is GC'd, this is done automatically.
If you find code like that in a finalize it's guaranteed that the person who wrote it was confused.
If it's elsewhere, it could be that the code is a valid patch to a bad model (a class stays around for a long time and for some reason things it referenced had to be manually freed before the object is GC'd). Generally it's because someone forgot to remove a listener or something and can't figure out why their object isn't being GC'd so they just delete things it refers to and shrug their shoulders and walk away.
It should never be used to clean things up "Quicker".
I'm not sure what you can make of this, but...
itsadok#laptop ~/jdk1.6.0_02/src/
$ find . -name "*.java" | xargs grep "void finalize()" | wc -l
41
So I guess the Sun found some cases where (they think) it should be used.
class MyObject {
Test main;
public MyObject(Test t) {
main = t;
}
protected void finalize() {
main.ref = this; // let instance become reachable again
System.out.println("This is finalize"); //test finalize run only once
}
}
class Test {
MyObject ref;
public static void main(String[] args) {
Test test = new Test();
test.ref = new MyObject(test);
test.ref = null; //MyObject become unreachable，finalize will be invoked
System.gc();
if (test.ref != null) System.out.println("MyObject still alive!");
}
}
====================================
result:
This is finalize
MyObject still alive!
=====================================
So you may make an unreachable instance reachable in finalize method.
finalize() can be useful to catch resource leaks. If the resource should be closed but is not write the fact that it wasn't closed to a log file and close it. That way you remove the resource leak and give yourself a way to know that it has happened so you can fix it.
I have been programming in Java since 1.0 alpha 3 (1995) and I have yet to override finalize for anything...
You shouldn't depend on finalize() to clean up your resources for you. finalize() won't run until the class is garbage collected, if then. It's much better to explicitly free resources when you're done using them.
To highlight a point in the above answers: finalizers will be executed on the lone GC thread. I have heard of a major Sun demo where the developers added a small sleep to some finalizers and intentionally brought an otherwise fancy 3D demo to its knees.
Best to avoid, with possible exception of test-env diagnostics.
Eckel's Thinking in Java has a good section on this.
Be careful about what you do in a finalize(). Especially if you are using it for things like calling close() to ensure that resources are cleaned up. We ran into several situations where we had JNI libraries linked in to the running java code, and in any circumstances where we used finalize() to invoke JNI methods, we would get very bad java heap corruption. The corruption was not caused by the underlying JNI code itself, all of the memory traces were fine in the native libraries. It was just the fact that we were calling JNI methods from the finalize() at all.
This was with a JDK 1.5 which is still in widespread use.
We wouldn't find out that something went wrong until much later, but in the end the culprit was always the finalize() method making use of JNI calls.
Hmmm, I once used it to clean up objects that weren't being returned to an existing pool.
They were passed around a lot, so it was impossible to tell when they could safely be returned to the pool. The problem was that it introduced a huge penalty during garbage collection that was far greater than any savings from pooling the objects. It was in production for about a month before I ripped out the whole pool, made everything dynamic and was done with it.
When writing code that will be used by other developers that requires some sort of "cleanup" method to be called to free up resources. Sometimes those other developers forget to call your cleanup (or close, or destroy, or whatever) method. To avoid possible resource leaks you can check in the finalize method to ensure that the method was called and if it wasn't you can call it yourself.
Many database drivers do this in their Statement and Connection implementations to provide a little safety against developers who forget to call close on them.
Edit: Okay, it really doesn't work. I implemented it and thought if it fails sometimes that's ok for me but it did not even call the finalize method a single time.
I am not a professional programmer but in my program I have a case that I think to be an example of a good case of using finalize(), that is a cache that writes its content to disk before it is destroyed. Because it is not necessary that it is executed every time on destruction, it does only speed up my program, I hope that it i didn't do it wrong.
#Override
public void finalize()
{
try {saveCache();} catch (Exception e) {e.printStackTrace();}
}
public void saveCache() throws FileNotFoundException, IOException
{
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("temp/cache.tmp"));
out.writeObject(cache);
}
It can be handy to remove things that have been added to a global/static place (out of need), and need to be removed when the object is removed. For instance:
private void addGlobalClickListener() {
weakAwtEventListener = new WeakAWTEventListener(this);
Toolkit.getDefaultToolkit().addAWTEventListener(weakAwtEventListener, AWTEvent.MOUSE_EVENT_MASK);
}
#Override
protected void finalize() throws Throwable {
super.finalize();
if(weakAwtEventListener != null) {
Toolkit.getDefaultToolkit().removeAWTEventListener(weakAwtEventListener);
}
}
The accepted answer lists that closing a resource during finalize can be done.
However this answer shows that at least in java8 with the JIT compiler, you run into unexpected issues where sometimes the finalizer is called even before you finish reading from a stream maintained by your object.
So even in that situation calling finalize would not be recommended.
iirc - you can use finalize method as a means of implementing a pooling mechanism for expensive resources - so they don't get GC's too.
As a side note:
An object that overrides finalize() is treated specially by the garbage collector. Usually, an object is immediately destroyed during the collection cycle after the object is no longer in scope. However, finalizable objects are instead moved to a queue, where separate finalization threads will drain the queue and run the finalize() method on each object. Once the finalize() method terminates, the object will at last be ready for garbage collection in the next cycle.
Source: finalize() deprecated on java-9
The resources (File, Socket, Stream etc.) need to be closed once we are done with them. They generally have close() method which we generally call in finally section of try-catch statements. Sometimes finalize() can also be used by few developers but IMO that is not a suitable way as there is no guarantee that finalize will be called always.
In Java 7 we have got try-with-resources statement which can be used like:
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
// Processing and other logic here.
} catch (Exception e) {
// log exception
} finally {
// Just in case we need to do some stuff here.
}
In the above example try-with-resource will automatically close the resource BufferedReader by invoking close() method. If we want we can also implement Closeable in our own classes and use it in similar way. IMO it seems more neat and simple to understand.
Personally, I almost never used finalize() except in one rare circumstance: I made a custom generic-type collection, and I wrote a custom finalize() method that does the following:
public void finalize() throws Throwable {
super.finalize();
if (destructiveFinalize) {
T item;
for (int i = 0, l = length(); i < l; i++) {
item = get(i);
if (item == null) {
continue;
}
if (item instanceof Window) {
((Window) get(i)).dispose();
}
if (item instanceof CompleteObject) {
((CompleteObject) get(i)).finalize();
}
set(i, null);
}
}
}
(CompleteObject is an interface I made that lets you specify that you've implemented rarely-implemented Object methods like #finalize(), #hashCode(), and #clone())
So, using a sister #setDestructivelyFinalizes(boolean) method, the program using my collection can (help) guarantee that destroying a reference to this collection also destroys references to its contents and disposes any windows that might keep the JVM alive unintentionally. I considered also stopping any threads, but that opened a whole new can of worms.