Related
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.
I implemented a class in Java7. It does not inherit/implements anything. It uses Tess4J so I thought it would be nice to free the resources in the end. So I overrode the finalize() method like this:
#Override
protected void finalize() throws Throwable
{
try
{
TessAPI1.TessBaseAPIDelete(handle);
}
catch(Throwable t)
{
throw t;
}
finally
{
super.finalize();
}
}
Netbeans 8.0.2 gives me warning for this method:
finalize declared()
The description on Netbeans website is not more useful to me:
warns about implementation of Object.finalize()
I didn't overrode any other method like equals or anything (maybe I should?).
Can you tell me why I get this warning?
finalize methods have the problem that they may be called at an arbitrary time by an arbitrary thread or even never at all. And like discussed in this question they may be called surprisingly early, i.e. when instance methods are still being executed, so using them to free a resource is quite dangerous.
So if they are not really useful for what is their original purpose, it’s legitimate to always warn when you are using them.
If you want to implement code for cleaning up a resource, when client code has forgotten to call close or dispose or whatever you provide for explicit resource management (which you should if there are associated native resources) can be done using a PhantomReference to the instance and a ReferenceQueue.
The advantage is that you have control over when to poll the queue and perform the cleanup and you may even opt-out the post-mortem cleanup by letting the PhantomReference go out of scope (it will be ordinarily collected and not enqueued) in the case that the client code did not forget to call close (it’s strongly recommended to implemented AutoClosable to allow using “try with resources”). So this also solves the small performance issue that objects having a non-trivial finalize method must be collected twice as executing the finalize method implies that they become reachable again.
Generally speaking, most Java programmers never have a reason to implement finalize(), since their own code only uses classes which are already managed (and therefore have their own finalizers). (See comments below the question).
Some developers might not be aware of how the garbage collector really works, and therefore rely on finalize() to do cleanup work that should be done somewhere else. This mistake can especially lead to the kind of defects that go unnoticed in testing, but cause failures in production.
For that reasons, I think a warning about finalize() is appropriate.
finalize() is called when the jvm going to gc. so maybe the resource is not released as you wish.
use try finally instead.
I'm new in Java with some background in C++ in my High School years. Now I'm trying to make something and I chose Java as the programming language.
I've done my homework and look a lot about "destructors" for Java, finalize() method, and close() or shutdown() methods. But still I think I don't have the idea of how this should work (more info below of course)
OK, the concrete question would be why do I need to call close() or shutdown() methods?
In my particular case I'm working with a class that I didn't develop that handles a smart card reader, but I've seen that the case of file management, where you have to call a close() method, would be similar.
Isn't calling a close() method the same idea as freeing memory in C++ (that sucks)? Meaning, I have to take care of the deletion or destruction of the object... isn't the GC for?
It could be an option that the class that I'm trying to use for the smart card reader is not the best, it might be better that this class implements the finalize() method so when is no longer used and ready for GC, frees memory (most probably is a native code) and/or frees hardware resources that the GC might not know how to do.
But what about the file management classes? Those are very used and maintained, why is still needed a close() method? I understand the purpose of existence, to unlock the file, but why do I have to remember to close it? Once the object is not used any more then unlock the file automatically, at least in the most common cases.
Finally, is it a proper workaround to wrap the class that needs to be closed or shutdown with a class that implements the finalize() method and there I call the close() or shutdown() method?
I've seen that the finalize() method is not very popular, so that is why I'm asking how this problem should be solved.
Thanks in advance
Juan
PS: what I've seen:
Is there a destructor for Java?
Why would you ever implement finalize()?
http://www.codeguru.com/java/tij/tij0051.shtml
explain the close() method in Java in Layman's terms
Do I need to close files I perform File.getName() on?
Most classes will clean up their external resources in their finalize methods, but this isn't analogous to C++'s destructor - a destructor is called as soon as an object is no longer used, but a finalizer isn't called until an object is garbage-collected, and you don't know when this is going to happen (and it might never happen if you don't have a memory-intensive program). So let's say you're allocating a bunch of objects that are each allocating a database connection (yes, you should be using connection pooling, but this is a hypothetical); you use each object and then null out its references so that it can be garbage-collected without first closing their database connections, and now your database is going to crap out on you because it's got too many connections open. You can call System.gc in the hopes that this will clean up the connections, but this is only a suggestion to the garbage-collector that it perform a collection, and it's possible that your garbage database connections' finalizers aren't smart enough to fully clean up the connections.
Long story short, you need to call close and shutdown because you don't know if/when your objects' finalizers are going to run, and you don't know how good they are at cleaning up external resources.
Incidentally, you should use try-catch-finally blocks to make sure you call close and shutdown - put the methods in the finally block. Or if you're using Java7, use try-with-resources.
the java garbage collector would do the work for you, BUT in some cases (with sockets or database connections) you need to call the close method (for example to close a connection with a database, or a file handler etc.).
There's people that calls the close() method of a connection and then turn it into null like:
conn.close();
conn = null;
Then they shoot it in the head to make it clear that it's dead.
Java's garbage collection automatically frees memory that's no longer referenced.
It doesn't free other resources. Consequently, you need an explicit method to free other resources.
Ok, the concrete question would be why do I need to call to .close or .shutdown methods?
To free resources that are not disposed of automatically.
I understand the purpose of existence, to unlock the file, but why do I have to remember to close it?
If you use Java 7's try-with-resources, you don't have to.
Finally, is it a proper workaround to wrap the class that needs to be closed or shutdown with a class that implements the finalize method and there I call the close or shutdown method?
No. You cannot rely on the finalize() method being called soon or at all after an object is no longer referenced.
Many classes exist to encapsulate the services of outside entities. In many cases, the usefulness of a class will depend upon its asking an outside entity to do something on its behalf until further notice, to the potential detriment of other prospective users of that entity. A class which asks an outside entity to act on its behalf until further notice, takes upon itself the responsibility of notifying the outside entity when its services are no longer needed.
Calling close() will tell an object that its services are no longer required; the (no-longer-needed) object can thus pass the messages along to entities that are acting on its behalf that their services won't be needed either. Such notice may then allow those entities to make their services available to other prospective users.
Garbage-collection operates on the presumption that the system knows when it needs memory, and there isn't any real benefit to getting rid of garbage until such time as the system would have use for memory that could be freed up. Such a philosophy doesn't really work with most things that use close. In many cases, code which holds a resource will have no way of knowing whether anyone else might want to use it. Consequently, code should generally try to hold resources only for the duration that they will actually be used. Once code is done with a resource, it should release it so as to make it available to anyone else who might want it.
I came across this question and am looking for some ideas?
You do not need (nor should you try to use) destructors - or what they are called in Java: "Finalizers".
The VM specification does allow for VM implementations to never call them. So they are not reliable for resource releases and the like. Generally speaking the code in the finalize() method of any object can be called by the VM before the object is garbage collected, but as this is not mandatory, you should avoid it.
Java is garbage-collected, so there is no way to tell when your destructor would be called (when your object will be garbage-collected).
There is a finalize (inherited) method but you can't rely on that for the exact reasons above (you can't predict when -and if- it will be called).
If you just need to cleanup some resources, you can call Runtime.getRuntime().addShutdownHook
Automatic object "destruction" in Java never happens at a guaranteed time. The only grantees for garbage collection are that before an object is collected the finalizer method will be called. Of course the garbage collector is never guaranteed to run, or do anything when it does run. So there is no guarantee that the finalize method will be called.
If you want to simulate C++ destructors in Java the best way is to use the following idiom (there are variations when it comest to exception handling - I'll just show the simplest case here):
final Resource r;
r = new Resource();
try
{
r.use();
}
finally
{
r.cleanup();
}
where the "cleanup" method is the "destructor".
This is more like the C++ Resource Acquisition Is Initialization idiom which is really for stack based objects, but isn't as nice.
You can check this for more info on finalization - finalize() method
Since others are talking about normal cases.. There are special cases where you want to create destroy(), destruct(), releaseExternalResources(), shutdown() etc. methods that should be actively called by the entity that controls the life cycle of that instance.
For example, an object can be an ActiveObject, which has live threads in it. In this case, you want to shut them down because else you will have memory leaks.
While one may not call that a destructor...
On a sidenote, I guess that interview question was intended as a trick question!
Try-with-resources is available as of Java 1.7
Anything that inherits from Closeable or Autocloseable can use it.
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
try (FileReader br = new FileReader(path)) {
return br.readLine();
}
This will automatically call a close function which is guaranteed to be called at the end of the block.
Is there a destructor for Java? I don't seem to be able to find any documentation on this. If there isn't, how can I achieve the same effect?
To make my question more specific, I am writing an application that deals with data and the specification say that there should be a 'reset' button that brings the application back to its original just launched state. However, all data have to be 'live' unless the application is closed or reset button is pressed.
Being usually a C/C++ programmer, I thought this would be trivial to implement. (And hence I planned to implement it last.) I structured my program such that all the 'reset-able' objects would be in the same class so that I can just destroy all 'live' objects when a reset button is pressed.
I was thinking if all I did was just to dereference the data and wait for the garbage collector to collect them, wouldn't there be a memory leak if my user repeatedly entered data and pressed the reset button? I was also thinking since Java is quite mature as a language, there should be a way to prevent this from happening or gracefully tackle this.
Because Java is a garbage collected language you cannot predict when (or even if) an object will be destroyed. Hence there is no direct equivalent of a destructor.
There is an inherited method called finalize, but this is called entirely at the discretion of the garbage collector. So for classes that need to explicitly tidy up, the convention is to define a close method and use finalize only for sanity checking (i.e. if close has not been called do it now and log an error).
There was a question that spawned in-depth discussion of finalize recently, so that should provide more depth if required...
Have a look at the try-with-resources statement. For example:
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
System.out.println(br.readLine());
} catch (Exception e) {
...
} finally {
...
}
Here the resource that is no longer needed is freed in the BufferedReader.close() method. You can create your own class that implements AutoCloseable and use it in a similar fashion.
This statement is more limited than finalize in terms of code structuring, but at the same time it makes the code simpler to understand and maintain. Also, there is no guarantee that a finalize method is called at all during the livetime of the application.
Nope, no destructors here. The reason is that all Java objects are heap allocated and garbage collected. Without explicit deallocation (i.e. C++'s delete operator) there is no sensible way to implement real destructors.
Java does support finalizers, but they are meant to be used only as a safeguard for objects holding a handle to native resources like sockets, file handles, window handles, etc. When the garbage collector collects an object without a finalizer it simply marks the memory region as free and that's it. When the object has a finalizer, it's first copied into a temporary location (remember, we're garbage collecting here), then it's enqueued into a waiting-to-be-finalized queue and then a Finalizer thread polls the queue with very low priority and runs the finalizer.
When the application exits, the JVM stops without waiting for the pending objects to be finalized, so there practically no guarantees that your finalizers will ever run.
Use of finalize() methods should be avoided. They are not a reliable mechanism for resource clean up and it is possible to cause problems in the garbage collector by abusing them.
If you require a deallocation call in your object, say to release resources, use an explicit method call. This convention can be seen in existing APIs (e.g. Closeable, Graphics.dispose(), Widget.dispose()) and is usually called via try/finally.
Resource r = new Resource();
try {
//work
} finally {
r.dispose();
}
Attempts to use a disposed object should throw a runtime exception (see IllegalStateException).
EDIT:
I was thinking, if all I did was just
to dereference the data and wait for
the garbage collector to collect them,
wouldn't there be a memory leak if my
user repeatedly entered data and
pressed the reset button?
Generally, all you need to do is dereference the objects - at least, this is the way it is supposed to work. If you are worried about garbage collection, check out Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning (or the equivalent document for your JVM version).
With Java 1.7 released, you now have the additional option of using the try-with-resources block. For example,
public class Closeable implements AutoCloseable {
#Override
public void close() {
System.out.println("closing...");
}
public static void main(String[] args) {
try (Closeable c = new Closeable()) {
System.out.println("trying...");
throw new Exception("throwing...");
}
catch (Exception e) {
System.out.println("catching...");
}
finally {
System.out.println("finalizing...");
}
}
}
If you execute this class, c.close() will be executed when the try block is left, and before the catch and finally blocks are executed. Unlike in the case of the finalize() method, close() is guaranteed to be executed. However, there is no need of executing it explicitly in the finally clause.
I fully agree to other answers, saying not to rely on the execution of finalize.
In addition to try-catch-finally blocks, you may use Runtime#addShutdownHook (introduced in Java 1.3) to perform final cleanups in your program.
That isn't the same as destructors are, but one may implement a shutdown hook having listener objects registered on which cleanup methods (close persistent database connections, remove file locks, and so on) can be invoked - things that would normally be done in destructors.
Again - this is not a replacement for destructors but in some cases, you can approach the wanted functionality with this.
The advantage of this is having deconstruction behavior loosely coupled from the rest of your program.
No, java.lang.Object#finalize is the closest you can get.
However, when (and if) it is called, is not guaranteed.
See: java.lang.Runtime#runFinalizersOnExit(boolean)
I agree with most of the answers.
You should not depend fully on either finalize or ShutdownHook
finalize
The JVM does not guarantee when this finalize() method will be invoked.
finalize() gets called only once by GC thread. If an object revives itself from finalizing method, then finalize will not be called again.
In your application, you may have some live objects, on which garbage collection is never invoked.
Any Exception that is thrown by the finalizing method is ignored by the GC thread
System.runFinalization(true) and Runtime.getRuntime().runFinalization(true) methods increase the probability of invoking finalize() method but now these two methods have been deprecated. These methods are very dangerous due to lack of thread safety and possible deadlock creation.
shutdownHooks
public void addShutdownHook(Thread hook)
Registers a new virtual-machine shutdown hook.
The Java virtual machine shuts down in response to two kinds of events:
The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit) method is invoked, or
The virtual machine is terminated in response to a user interrupt, such as typing ^C, or a system-wide event, such as user logoff or system shutdown.
A shutdown hook is simply an initialized but non-started thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled.
Finally, the virtual machine will halt. Note that daemon threads will continue to run during the shutdown sequence, as will non-daemon threads if the shutdown was initiated by invoking the exit method.
Shutdown hooks should also finish their work quickly. When a program invokes exit the expectation is that the virtual machine will promptly shut down and exit.
But even Oracle documentation quoted that
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly
This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
Conclusion : use try{} catch{} finally{} blocks appropriately and release critical resources in finally(} block. During release of resources in finally{} block, catch Exception and Throwable.
First, note that since Java is garbage-collected, it is rare to need to do anything about object destruction. Firstly because you don't usually have any managed resources to free, and secondly because you can't predict when or if it will happen, so it's inappropriate for things that you need to occur "as soon as nobody is using my object any more".
You can be notified after an object has been destroyed using java.lang.ref.PhantomReference (actually, saying it has been destroyed may be slightly inaccurate, but if a phantom reference to it is queued then it's no longer recoverable, which usually amounts to the same thing). A common use is:
Separate out the resource(s) in your class that need to be destructed into another helper object (note that if all you're doing is closing a connection, which is a common case, you don't need to write a new class: the connection to be closed would be the "helper object" in that case).
When you create your main object, create also a PhantomReference to it. Either have this refer to the new helper object, or set up a map from PhantomReference objects to their corresponding helper objects.
After the main object is collected, the PhantomReference is queued (or rather it may be queued - like finalizers there is no guarantee it ever will be, for example if the VM exits then it won't wait). Make sure you're processing its queue (either in a special thread or from time to time). Because of the hard reference to the helper object, the helper object has not yet been collected. So do whatever cleanup you like on the helper object, then discard the PhantomReference and the helper will eventually be collected too.
There is also finalize(), which looks like a destructor but doesn't behave like one. It's usually not a good option.
The finalize() function is the destructor.
However, it should not be normally used because it is invoked after the GC and you can't tell when that will happen (if ever).
Moreover, it takes more than one GC to deallocate objects that have finalize().
You should try to clean up in the logical places in your code using the try{...} finally{...} statements!
If it's just memory you are worried about, don't. Just trust the GC it does a decent job. I actually saw something about it being so efficient that it could be better for performance to create heaps of tiny objects than to utilize large arrays in some instances.
Perhaps you can use a try ... finally block to finalize the object in the control flow at which you are using the object. Of course it doesn't happen automatically, but neither does destruction in C++. You often see closing of resources in the finally block.
There is a #Cleanup annotation in Lombok that mostly resembles C++ destructors:
#Cleanup
ResourceClass resource = new ResourceClass();
When processing it (at compilation time), Lombok inserts appropriate try-finally block so that resource.close() is invoked, when execution leaves the scope of the variable. You can also specify explicitly another method for releasing the resource, e.g. resource.dispose():
#Cleanup("dispose")
ResourceClass resource = new ResourceClass();
The closest equivalent to a destructor in Java is the finalize() method. The big difference to a traditional destructor is that you can't be sure when it'll be called, since that's the responsibility of the garbage collector. I'd strongly recommend carefully reading up on this before using it, since your typical RAIA patterns for file handles and so on won't work reliably with finalize().
Just thinking about the original question... which, I think we can conclude from all the other learned answers, and also from Bloch's essential Effective Java, item 7, "Avoid finalizers", seeks the solution to a legitimate question in a manner which is inappropriate to the Java language...:
... wouldn't a pretty obvious solution to do what the OP actually wants be to keep all your objects which need to be reset in a sort of "playpen", to which all other non-resettable objects have references only through some sort of accessor object...
And then when you need to "reset" you disconnect the existing playpen and make a new one: all the web of objects in the playpen is cast adrift, never to return, and one day to be collected by the GC.
If any of these objects are Closeable (or not, but have a close method) you could put them in a Bag in the playpen as they are created (and possibly opened), and the last act of the accessor before cutting off the playpen would be to go through all the Closeables closing them... ?
The code would probably look something like this:
accessor.getPlaypen().closeCloseables();
accessor.setPlaypen( new Playpen() );
closeCloseables would probably be a blocking method, probably involving a latch (e.g. CountdownLatch), to deal with (and wait as appropriate for) any Runnables/Callables in any threads specific to the Playpen to be ended as appropriate, in particular in the JavaFX thread.
Many great answers here, but there is some additional information about why you should avoid using finalize().
If the JVM exits due to System.exit() or Runtime.getRuntime().exit(), finalizers will not be run by default. From Javadoc for Runtime.exit():
The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.
You can call System.runFinalization() but it only makes "a best effort to complete all outstanding finalizations" – not a guarantee.
There is a System.runFinalizersOnExit() method, but don't use it – it's unsafe, deprecated long ago.
If you got the chance of using a Contexts and Dependency Injection (CDI) framework such as Weld you can use the Java annotation #Predestroy for doing cleanup jobs etc.
#javax.enterprise.context.ApplicationScoped
public class Foo {
#javax.annotation.PreDestroy
public void cleanup() {
// do your cleanup
}
}
Though there have been considerable advancements in Java's GC technology, you still need to be mindful of your references. Numerous cases of seemingly trivial reference patterns that are actually rats nests under the hood come to mind.
From your post it doesn't sound like you're trying to implement a reset method for the purpose of object reuse (true?). Are your objects holding any other type of resources that need to be cleaned up (i.e., streams that must be closed, any pooled or borrowed objects that must be returned)? If the only thing you're worried about is memory dealloc then I would reconsider my object structure and attempt to verify that my objects are self contained structures that will be cleaned up at GC time.
If you're writing a Java Applet, you can override the Applet "destroy()" method. It is...
* Called by the browser or applet viewer to inform
* this applet that it is being reclaimed and that it should destroy
* any resources that it has allocated. The stop() method
* will always be called before destroy().
Obviously not what you want, but might be what other people are looking for.
No Java doesn't have any destructors .The main reason behind it in Java is the Garbage Collectors that passively works in the background always and all the objects are made in the heap memory , that is the place where GC works .In c++ there we have to explicitly call the delete function since there is no Garbage collector like thing.
In Java, the garbage collector automatically deletes the unused objects to free up the memory. So it’s sensible Java has no destructors available.
Try calling the onDestroy() method when it comes to android programming. This is the last method that executed just before the Activity/Service class is killed.
Missing form all the answers I just scanned is the safer replacement for finalizers. All of the other answers are correct about using try-with-resources and avoiding finalizers as they are unreliable and are now deprecated...
However they haven't mentioned Cleaners. Cleaners were added in Java 9 to explicitly handle the job of cleanup in a better way than finalizers.
https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Cleaner.html
I used to mainly deal with C++ and that is what lead me to the search of a destructor as well. I am using JAVA a lot now. What I did, and it may not be the best case for everyone, but I implemented my own destructor by reseting all the values to either 0 or there default through a function.
Example:
public myDestructor() {
variableA = 0; //INT
variableB = 0.0; //DOUBLE & FLOAT
variableC = "NO NAME ENTERED"; //TEXT & STRING
variableD = false; //BOOL
}
Ideally this won't work for all situations, but where there are global variables it will work as long as you don't have a ton of them.
I know I am not the best Java programmer, but it seems to be working for me.