I found what kind of objects are causing a memory

Using the jmap -histo command on a running process, every 30 minutes or so, I found one kind of object that is obviously a memory leak (in a desktop app).

The object responsible for the leak (I.e. the only kind of object whose number of instances grows over time, and by a huge amount) is int[].

I suspect BufferedImage to be the culprit but I'm not sure about that (I took great care about flushing/nullifying BufferedImages but I still think that's where the leak hangs).

However I'm also using int[] in another part of the program and I'm simply not sure as to where the leak is coming from. The output of jmap -histo is a bit too "thin" to my liking.

How can I now pinpoint where the leak(s) of int[] are occuring.

By the way I'd like to point out how great a simple jmap -histo can be: I'm sure that for a lot of objects simply seeing the number of instances and memory used is enough to spot a leak, without needing further analysis.

However in my case I need something else.

My question is not what kind of tools allow to spot a leak. My question is:

Knowing that my app (or an API that my app is using) is leaking int[], what steps can I take (using your favorite profiler, for example) to, hopefully, find the leaks?

The tool has to work on a Java 1.5 OS X 10.4 Apple JVM.

回答1:

You need to sort the objects by Retained Heap. You will find the meaningfull object/class which contains all the int[] very quickly.

回答2:

I would recommend first using Eclipse MAT as I dont know, personally, the capabilities of jProfiler. Then when you load your heap dump you can check some of the int[]'s incoming references. You can thin pin point who created the arrays and see which holding class is really creating the massive amount.