What has to be done during destroy() to prevent memory leaks?

Hello,

I have written an applet that presents a GUI build with multiple JLabels, JSliders and a JScroller (containing a JPanel).

To work with those I define multiple variables and Event-Listeners (ChangeListeners for the Slider, MouseListeners for the JPanel and JLabels and similar). As a response to a particular Slider-Event a thread is started, which ends by itself. Another Event starts a Timer-Task that is executed only once.

I do not use the keyword "static" anywhere in the applet source code. The various needed classes (for the listener etc) are defined as internal classes.

My problem is that some memory is retained by the java plugin when the user changes the page and the applet is not displayed any longer. The destroy method of the applet is being called - this is shown in the Java Console (with logging enabled) and I also see the effect of some code I put into the destroy() method.

Every time the user opens the page again with the applet in it (and the applet gets initialised), additional memory is allocated by the plugin. After destroying and initialising the applet multiple times during the same browser session, the Java plugin throws a Out-Of-HeapMemory error and the Applet doesn't start.

This is repaired fairly easily by simple restarting the browser, so that the plugin restarts as well; but of course I'd prefer it to work cleaner than that.

So I guess there is a memory leak somewhere. Some object is not destroyed properly or something like that. I am a little confused by this. Shouldn't Java automatically destroy all objects once the applet is being destroyed?

I did add code in the destroy() to remove all Listeners from all my objects, set all ObjectVariables to "null" and called getContentPane().removeall() to get rid of the GUI, but none of these solved my problem.

What are the recommended things to do in the destroy() of an applet? I searched around and read the Java Tutorial about Applets but I couldn't find any information about good programming practice concerning the destroy() in Java Applets.

Can anyone give me some hints about the possible source for this memory leak, or maybe some information about proper things to do when destroying the applet?

Thanks for your help,

Sven

[2319 byte] By [Sven_Lala] at [2007-11-26 18:14:28]
# 1

So I guess there is a memory leak somewhere. Some object is not destroyed properly or something like that. I am a little confused by this. Shouldn't Java automatically destroy all objects once the applet is being destroyed?

No, that's a slight misunderstanding. Objects which are not strrongly reachable are cleared when the garbage collector runs; and all heap space is cleared when the VM is shut down.

So, since your VM is being recycled between applets, all you need is for one or more objects to remain reachable somewhere and you have a leak. It's not necessarily anything to do with the destroy() method of the applet, and to be honest, unlikely to be so. Nulling references and removing GUI components is pointless, so don't bother. Detaching listeners from unreachable objects is also worthless.

Some issues can occur if you use native resources - for example images should be flush()ed, streams should be close()d and so should database resources (Connections etc) - note that in some cases, especially database connections, you have to code carefully to avoid resource leaks when exceptions are thrown (not least because the close() methods can throw exceptions). Safe resource closing code is quite verbose and is best done in a utility class to reduce both risk and code bloat.

Without going through your code with a fine toothed comb it's impossible to say what your leak may be. You can always investigate it with a tool such as JProbe, which should direct you to the problem much more quickly than sifting through source code.

itchyscratchya at 2007-7-9 5:47:52 > top of Java-index,Desktop,Core GUI APIs...
# 2
Thanks for your help!I am going to search through my code then...
Sven_Lala at 2007-7-9 5:47:52 > top of Java-index,Desktop,Core GUI APIs...