2 Replies Latest reply on May 30, 2011 6:33 PM by Peter Johnson

    OutOfMemory: java heap space, identify memory leak

    Dave Chen Master

      We have a JSF web app running on JBoss 5.1.0.GA.

      After running for hours on production system, we got a heap dump, but we can not reproduce it on dev machine.

       

      open the heap dump using visualVM:

       

      byte[]:    instances: 31769, size (516M).

      char[]:   instances: 992175, size (96M)

      java.lang.String: instances: 1208661, size (44M)

      org.ajax4jsf.application.TreeStructureNode: instances:747264, size(36M)

      .....

       

      I can open instance view and references, but i could not find a way to identify memory leak.

      How to use visualVM to identify memory leak effectively? or other tools?

       

      Why I can not reproduce the OutOfMemory error  in dev machine using concurrent HTTP requests

      that is more intensive than those for production machine?

       

      Thanks very much

      Dave

       

        • 1. Re: OutOfMemory: java heap space, identify memory leak
          Wolf-Dieter Fink Master

          You might use jProfiler or the netbeans profiler to analyze what kind of objects are not garbaged.

          • 2. Re: OutOfMemory: java heap space, identify memory leak
            Peter Johnson Master

            You can usually ignore the byte[]. char[] and String instances, they are usually the most used instances. Though based on the amount of space taken up by the byte[] instaces, it seem like some object somewhere is storing a lot of byte information (perhaps a StringStream ?). VirtualVM will show you which objects are referencing each byte[] instance, usally you need to look at only a few instances before a pattern developes.

             

            Does the TreeStructureNode declare a byte[], or an object that has a byte[] embedded? You should also look at the next 3 or 4 entries in the list.

             

            The best way to track down a leak is to take multiple heap dumps and see what changed between them. VisualVM is very good for doing this because it can compare multiple memory snapshots (via the memory profiler) and show you what changed. You want to look for classes whose instances increase dramatically. Then it is a matter of doing a search through the source code, for example for occurances of "new TreeStructureNode", and then tracking down who created those objects and why they are not being released.