How to destroy java objects?

Question

Well, I have developed a java application using several objects relationships that make the memory usage too expensive. I have no experience managing the java memory because

Answer 1

Assign every reference you want the GC to collect to null.

Answer 2

Keeping Track

According this context, how can I deal with object destruction when there are multiples references to it?

By making sure these references are not needed anymore.

If you isolate them, even in a big isolated graph of unused objects not connected anymore to your main progam, then they are all eligible for garbage collection.

Local variables which have reached the end of their scope will be eligible for garbage collection (and so will their contained) objects, if they have not been "linked" to anything else (added to a collection, ac omposite, etc...). For UI objects, which can indeed be difficult to reason with in terms of object graphs, make sure to dispose of them correctly or to read the documentation to make sure that they would naturally disposed of.

"Leave [GC] Alone!!"

or how do I need to manage the memory when you have a complex references to each others?

You can't "manage" the memory. You can simply manage references. The idea is to "severe" your connections to your objects by simply not having references to them. They then live up in memory until the GC exterminates them.

Do not attempt to mess with the GC to force it to do things. It's a rather clever beast, and while you can try to instruct it to react to some requests explicitly - it might ignore you - it's usually a bad idea: do not invoke the GC explicitly, avoid finalizers and explicit nulling if you don't understand their implications.

---

Note to answer your comment

Simply nulling a reference to an object that has been added to several collections or composites will not make it eligible for collection. By doing this, you'd have only nulled one reference.

You do need to remove this object from all the lists or containers that have a reference to it (basically, making them "forget" about this object). Once no objects still "remembers" or has a "link" to your created object, it becomes a lonely item in the Garbage Collector's graph, which makes it a candidate for deletion.

Maybe it sounds tedious, but if you think of it from a language where you manually manage memory (C or C++, to name the most 2 obvious references), free-ing and null-ing pointers to your dynamically allocated objects would indeed destroy them, but you'd still need to remove the element from the lists (or any containers) or they would appear like empty buckets to a null pointer.

---

Further Reading

• Garbage Collection (especially the section on reachability)
• Sun Microsystems's Whitepaper on in the Java HotSpot Virtual Machine ^{(dated, but very good)}
• Java Theory and Practice: A Brief History of Garbage Collection - How does Garbage Collection Work?
• Java Theory and Practice: Garbage Collection Performance
• How Garbage Collection Works in Java
• Handling Memory Leaks in Java Programs
• From Java Code to Java Heap
• These SO questions on:
  • Java Memory Explained ^{(provides a lot of additional info and links)}
  • Java Memory Management Best Practices

Answer 3

The whole point of java garbage collection is that you don't have to do anything. Garbage collection is done for you.

Answer 4

What you could do is make one intermediate class. For example, if you have instance of class A, for which you have a lot of references and you want to remove it but a lot of references makes it difficult, you can do the following: create instance of class B that contains nothing other than reference to instance of class A (like some kind of proxy). Now you will have a lot of references to instance of class B but just one reference to instance of class A, which you can easily remove and garbage collector will collect instance of class A.

Image shows difference when using proxy (instance of class B): Now only one reference has to be removed.

Answer 5

For the most part, GC will do it's magic in good time.

You can have a situation whereby, say, a view is observing a model and you want to ditch the view but keep the model. In that case you will need to remember the observer callback objects, and remove them when you discar the view. You don't necessarily have to have special fields for each observer - a set of tasks that unregister a callback each will be fine. Or, more complexly, you can have a layer of transient indirection over the model which unzips from the underlying one. I suggest avoiding weird stuff with weak references of one sort or another.

In case where you may have finalisers (or require some kind of weak map eviction), such as presumably with a java.awt.Frame, You may want a layer of indirection between the resource and the memory hog which can simply be nulled out.