The built in garbage collection in the JVM is designed so that when an object is no longer alive (can not be referenced from any of the “roots” that are always accessible to the application) then the object can be removed as it is no longer required. This mechanism works well as it allows us to ensure all required resources remain accessible and if the resource is no longer required we just need to dispose of the object, which removes the references from the roots and marking the object for garbage collection.
Recently we have become aware of a memory leak in our software that has now been resolved. It appears that one of our Timers wasn’t disposed of when we dispose of the SwingGUI. It appears that Timer objects seem to have a connection to a root which means when we disposed of SwingGUI with the timer running the Timer object within wasn’t stopped and disposed of as would be expected which meant that SwingGUI was not disposed.
The specific gotcha is that you can create a method object which is never garbage collected even if the method exits. The easiest solution is to make it a global object which you can then explicitly dispose if you use it (otherwise leave it as null). It is a myth that Java has no memory leaks – it removes many causes of leaks but they are still a problem to catch you.
These sorts of issues can also arise when using multiple threads or objects that contain threads if they are not handled correctly and disposed of correctly. Being unwary with these objects can cause problems with the garbage collection as well as your programs performance. So long as you correctly dispose of all objects when your finished with them you should not encounter any issues.
As my mother used to tell me as a child, “When your finished with your toys don’t forget to tidy them away”. Are all your toys put away safely?