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 the application design make it difficult to destroy objects and re utilize the space previously cleared. For example, I am using Observer and MVC patterns.
So, the theory say that..
An Object becomes eligible for Garbage collection or GC if its not
reachable from any live threads or any static reference
In other words you can say that an object becomes eligible for garbage collection if its all references are null.
But, in my short experience, has be too difficult for me destroy all references from objects that I want to remove from memory (for example, when a frame is closed) when you have a scenario like mine, where you don’t know how many references to your classes exists.
According to this context, how can I deal with object destruction when there are multiple references to it? or how do I need to manage the memory when you have a complex references to each others?
Keeping Track
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!!”
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