Understanding memory leaks in Java & start using HAT for further analysis

[qazmlp]

As I had mentioned in one of my previous thread, the process size of
all of the Java processes in my application keeps increasing. So, I
wanted to do profiling
for all these processes using HAT(Heap Analysis Tool). As it is the
first time, I heard about HAT, I wanted to try it out first with a
simple Java code(intentionally with some memory leaks). Basically, I
wanted to get familiarized about HAT usage.
But, the code with whatever I tried so far, I do not see any leaks
reported by HAT. So, now I suspect my knowledge about memory leaks in
Java.

Can anybody give a short explanation with some sample code having
memory leaks?

Thanks!

 

[Michael Borgwardt]

for all these processes using HAT(Heap Analysis Tool). As it is the
first time, I heard about HAT, I wanted to try it out first with a
simple Java code(intentionally with some memory leaks). Basically, I
wanted to get familiarized about HAT usage.
But, the code with whatever I tried so far, I do not see any leaks
reported by HAT. So, now I suspect my knowledge about memory leaks in
Java.

I'm not familiar with HAT and its capabilities, and after a short websearch it
actually looks like an abandoned project to me.

But it sounds to me like you're expecting it to explicitly tell you
"there's a memory leak in line 42 of class Foo". It can't - no tool can
do that.

What profilers can do is show you the number of live objects of different
classes that exist at a certain point in the VM. If there are unexpectedly
many instances of a given class, a good profiler will show you where they
are referenced. With this information, you should be able to determine
whether there is actually a memory leak (i.e. objects that are referenced
when they should be discarded) and have a pretty good starting point for
finding out where your app creates those references or where it fails to
remove them.

 

[Scott Ellsworth]

I'm not familiar with HAT and its capabilities, and after a short websearch it
actually looks like an abandoned project to me.

But it sounds to me like you're expecting it to explicitly tell you
"there's a memory leak in line 42 of class Foo". It can't - no tool can
do that.

There are tools that will let you get close for some common cases.

For the OP: they take a snapshot of the heap at one point, let you
execute, take a second, and then tell you where the allocations came
from that produced the growth in object count/mem usage. This gives you
a good idea of how your heap is growing, and why.

True, this does not say "leak here" for the zombie static case, but it
comes awfully close for the ever-growing-collection case. I have used
OptimizeIt for this in the past. We are now considering moving to
JProfiler once its heap walker works with 1.4.x on MacOS X, and I have
been impressed thus far.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects and Database consulting

 

[Robert Olofsson]

: qazmlp wrote:
:> ...simple Java code(intentionally with some memory leaks). Basically, I
:> wanted to get familiarized about HAT usage.
:> But, the code with whatever I tried so far, I do not see any leaks
:> reported by HAT. So, now I suspect my knowledge about memory leaks in
:> Java.

: What profilers can do is show you the number of live objects of different
: classes that exist at a certain point in the VM. If there are unexpectedly
: many instances of a given class, a good profiler will show you where they
: are referenced.

Well not entirely true, there exists leaks in java code that are
quite easy to spot:

void method (Connection db) throws Exception {
FileOutputStream fos = new FileOutputStream ("/tmp/file");
PreparedStatement ps = db.prepare ("Select 1 from someTable");
Graphics g = someButton.getGraphics ();
}

All of fos, ps and g are objects that needs to be
closed/closed/disposed when they are no longer in use. This method
leaks because it allocates _system_ resources and never will free them
(no references kept so no other method can remove them).

Some of the above objects may have a finalize method that cleans up if
the garbage collector ever runs, however at least the Oracle prepared
statements do not (so if you use oracle you have to make sure you
close everything).

Most other leaks in java code comes from code that puts objects in a
static container (List, Map, Set...) and that code is truly hard to
determine programmatically, but a good profiler can show how many
instances there are of each clas and you can see who the owner is of
each object.

For a list of other profilers:
jmp, the one I develop, free, GPL, http://www.khelekore.org/jmp
jprobe: www.sitraka.com/software/jprobe/
optimizeit: www.borland.com/optimizeit/
jprofiler:http://www.ej-technologies.com/products/jprofiler/overview.html

For some other tools:
http://www.javaperformancetuning.com/resources.shtml#ProfilingToolsFree

/robo