There are several programs that will read a heap dump and show you what
is holding onto the memory -- you can see who is holding on to your char
arrays (likely strings, which in turn are held in some container, and so
on -- the idea is to look at those objects and determine who is holding
references to them and preventing them from being collected). The JDK
comes with jhat, which lets you use a web browser to look through it and
even do rudimentary queries on the heap; Netbeans will load a heap and
let you poke around inside of it; there is an Eclipse memory analyzer
which does a good job too.
--Scott
On Fri, 2009-04-10 at 01:34 -0700, glassfish_at_javadesktop.org wrote:
> Hi Jacob,
>
> love a good CLI session... so, I setup a cron to run jmap -histo:live every hour and collected the data until the problem resurfaced. After looking at the dumps, the class using the most memory was [C, which from what I have discovered seems to mean char arrays. When I started collecting the data (which was hours after restarting the server, but hours before the symptoms surfaced again), [C was using approx. 700MB. When the CPU spikes began to occur, [C was using 1.3GB. The next most memory intensive class in each dump was [B, but the usage was roughly the same in all dumps, fluctuating less than 20MB.
>
> So, any advice on how to determine what is creating / using / holding on to the char arrays? I'm going to try generating a heap dump and analyzing it with eclipse memory analyzer or jhat. Hopefully that will show me the enclosing object ...
> [Message sent by forum member 'rwillie6' (rwillie6)]
>
> http://forums.java.net/jive/thread.jspa?messageID=341594
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net