Bad Performance Help! Memory Leak?

[Rigel]

I have a java stand alone app I'm running. This software runs continuously uploading data to an ftp site every 5 minutes. After about a few days I notice that the program begins to run extremely slow until eventually the entire program crashes. Sometimes after a day or so all the text on the menu bar turns black but the program continues to run and function normally. (Of course the performance slows a bit as well)

I know this error is very abstract and vague but I can't really pin point the problem.

My only guess is that there is some sort of inefficient code or some memory leak going on when the program is continuously running and uploading data to the web.

Should I use something like "Runtime.getRuntime().gc()" in my code?
What's the best approach to fixing this problem?

Thanks.

[_uj]

Basically Java cannot leak memory. What can happen is so called memory retention. This is when you involuntarily keep references to objects you don't use anymore. Maybe for example in a collection held in a static variable.

There is a form of resource leek thought that's caused by classes claiming OS resources. All those classes has an explicit termination method that must be called before an object is released for GC. One example is close of Input/OutputStream. Another is dispose of Window and Graphics.

From what you've described it could be that you don't call dispose before releasing objects of class Window (or subclasses of it).

Calls to gc won't help at all.

There are tools available for this kind of problems, for example JProbe.

[Rigel]

Thanks UJ, I'll take a deeper look at the code.

[Davey]

Calling System.gc() only suggests that the JVM performs garbage collection, it doesn't force it to do so. There shouldn't really be any need for you ever to call System.gc().

I aggree that you try something like JProbe (http://www.quest.com/jprobe/ )

[cma]

You may want to do a search for Java "heap profilers" as this is the general name for this type of debugging tool to check for unintentional object retentions.
In general, this type of memory leak occur's because the program manages its own memory. I'll let Joshua Bloch of Effective Java explain better:

So when should you null out a reference? What aspect of the Stack class makes it susceptible
to memory leaks? Simply put, the Stack class manages its own memory. The storage pool
consists of the elements of the items array (the object reference cells, not the objects
themselves). The elements in the active portion of the array (as defined earlier) are allocated,
and those in the remainder of the array are free. The garbage collector has no way of knowing
this; to the garbage collector, all of the object references in the items array are equally valid.
Only the programmer knows that the inactive portion of the array is unimportant. The
programmer effectively communicates this fact to the garbage collector by manually nulling
out array elements as soon as they become part of the inactive portion.

Generally speaking, whenever a class manages its own memory, the programmer should be
alert for memory leaks. Whenever an element is freed, any object references contained in the
element should be nulled out.

And this is the portion of code of the Stack class he's referring too:

public Object pop() {
if (size == 0) throw new EmptyStackException();
return elements[--size];
}

[Joe Nellis]

There are some nonstandard options for profiling
java -Xprof
and heap monitoring
java -Xrunhprof:help

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html#nonstandard

[Rigel]

Thanks everyone.