问题
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.
来源：https://stackoverflow.com/questions/4630081/i-found-what-kind-of-objects-are-causing-a-memory-leak-now-what