I had the general view that clean up of resources is done in the finally block,
recently I found this particular code snippet in a class and it was overriding the Object class' finalize() method.
protected void finalize() {
try {
In.close();
Out.close();
socket.close();
}
catch (Exception e) {
//logger code here
}
}
Is this a good idea? What are the pros and cons of finalize() over finally?
The finally block is just a block of code that always executes after a try block, even if there is an exception. i.e. it is local in scope
The finalize() method is an approach for cleaning up the whole object when it is garbage collected.
Java documentation of finalize()
finally solves the problem of cleaning up resources in a block of code regardless of whether an exceptional condition occurs...
finalize() is a way to clean up resources when your object is no longer being used, once the Garbage Collecter determines there are no more references to that object.
In short, to answer your question, for example, if the sockets you are closing are members of an object you should close them in the finalize() method, (although that's sub-optimal, and just for example, because there is no guarantee when the GC will actually perform the action)
If however you're opening the socket in a method, and are done with it when the method ends you should free the resources in the finally block.
Always clean up things in finally.
Cleaning up in finalize is not guaranteed to occur.
However, it is often found to clean up such things in finalizers as a last-ditch safety valve should a finally block throw another exception on you.
The real problem with relying on finalizers is something else may need the resource before the GC gets around to calling the finalizer.
Phantom References will do what you want.
Just don't use finalize. There are a few edge cases where it may be helpful (printing debug info when a class is GC'd has come in handy), but in general don't. There is nothing in the JVM contract that even says it ever has to be called.
There is a very under-publicized type of object called "References". One is made explicitly for things that you think you would use finalize for.
"Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed."
It just occurred to me that there MUST be a description of this on the web--so I'll replace all the "how-to" stuff I just wrote with this reference.
They're not related. This is like asking, "Should you create objects in an initializer or in normal methods?" Like, it depends on what you're doing with the objects. A finalizer cleans up an object's state while it's destroyed (maybe — it's not something you should rely on), while a finally block executes code after a try block. There isn't any common situation where you'd be able to choose one or the other since they do different things.
Finalize is probably a bad idea if your application causes lots of these objects to be created. This is because finalize will cause a bottleneck as the objects become eligible for garbage collection.
There are times when finalize is the only solution; but use finally whenever you can
Finally. Finalize is bad in that it may never get called. Use finalize only as a safety net. For example an InputStream should have a finalize that closes the stream incase the applcicationforgets to. However the application should close it.
If it were me I would do the cleanup in the finalizer as well and log the cases when the cleanup was performed and then track down in the application the code that forgot to properly clean up.
There are a number of problems with the code in the question, including:
close will prevent the others from executing (as it happens, this doesn't matter in this example because of the peculiar behaviour of Socket).finalize, leave it throwing Throwable (and add @Override). Technically you should also call the super in a finally block.So: Always use finally for these things. finalize is extremely specialised (and PhantomReference are probably better is superficially more complicated).
If you are looking for alternatives to finalize() the proper question would be:
close() method like, for example, all the stream and writer/reader classes in java.io.* and many others - when there is finalize()?The other answers make it clear that the disadvantage of finalize() is that you have no way to force it to run, and neither do any who might use your code.
Of course, calling a close() methode (best done in a finally block or in a close() method itself) has to be documented by the author and then remembered to be called by the ones using the code. But there are lots of examples (not only java.io.*) where this is imposed and it works.
BTW: close() is merely a convention.
Joshua Bloch makes a very clear recommendation in his book Effective Java (2nd Edition). Copied from chapter 2 Item 7: Avoid finalizers:
Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems. Finalizers have a few valid uses, which we’ll cover later in this item, but as a rule of thumb, you should avoid finalizers.
Please read the reference to find out why.
