This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
1) While making Outer class objects as null it is not getting garbage collected. Since inner classes are referring to Outer class.
Thats the way it is supposed to work. Inner classes have to keep reference to outer class so it doesn't matter what your program does to the more obvious references. If your inner class was an event listener, bingo!
I have written the follwing code and garbage collection is happening properly and memory leakage problem is almost solved.
panel.removelAll(); //(panel is nothing but a JPanel) which removes all the components from the container and dispatches all the events also
panel = null; //After removing all from the panel and making it null ensures the panel to be garbage collected.
Leonardo Carreira wrote:
how about if we write down : System.gc(); //garbage collection
The problem here is that there is a memory leak i.e. some objects are not in use logically but are not eligible for GC. This happens if you hold on to references more than required (In simple terms it is a memory leak)
The question here is not whether GC has run or not but even if GC has run the memory is not getting released.
In modern day JVMs. you do not need to indicate that an application is ready for GC (by using System.gc()), JVM in intelligent enough to run GC when required.
JVM in intelligent enough to run GC when required.
We have a graphical display that displays a road network. When we first designed it, we were only dealing with 50,000 road arcs
Currently the raw data is over 3,000,000 road arcs. If we let the GC do its thing, when it thinks it should(during load), we were getting
hit with a 40 minute GC delay and the added slow down from entering swap.
If we are proactive and do a gc after ever 100,000 arcs, it loads in 4-6 minutes and never enters swap.