JProfiler approach for Memory Leak issue

http://www.ej-technologies.com/products/jprofiler/overview.html

JProfiler is a powerful Java Profiling tool for Performance Engineers.

I have mentioned how to verify Memory leaks using JProfiler

Memory Leaks

JProfiler allows you to view a graph of memory usage while an application runs. You can verify whether an application leaks memory by determing whether the overall amount of memory the program uses increases over time rather than returning to a constant level between activity spikes and dips.

To use JProfile to verify a memory leak, follow these steps:

1. If you selected to start a session after configuring JProfiler, the Session Startup dialog appears.
    Otherwise, select Session > Open Session.  An Open Session dialog appears.
    Select Remote application on local host and click Open. The Session Startup dialog appears.
    Note: If using an evaluation copy of JProfiler, an evaluation dialog appears.
              Click Evaluate to get to the Session Startup dialog.

2. Click OK.
    A Connection status dialog appears.

3. Start the application that you want to profile.

4. Click VM Telemetry Views on the left of JProfiler. Then click the Memory tab at the bottom, if not
    already selected.

5. Use the application and watch the application performance in JProfiler. 

The following graph shows an application with a memory leak.

Identifying Memory Leak Source

1. Click  to cause the JVM to start collecting objects.

2. Click Memory Views.

   

3. Filter the view to display Nexaweb objects only; enter: com.nexaweb in the filters field and
    press the Return key.

4. Select View > Mark Current Values.
    This causes JProfiler to remember all classes and number of instances of each in the application.
    In addition, it adds a Difference column to the Memory view.

5. Click  to cause the JVM to start collecting objects.

6. Use the application and observe the values changing in the Difference column.
    You can rule out objects for which JProfiler records a 0 in the Difference column
    as being the source of the memory leak.

7. Select an object with values in the Difference column and then click .
    JProfile displays a dialog prompting you to discard the current snaphsot, if one has already been taken,
    click OK.
    JProfiler displays a dialog prompting you to select options for the snapshot.

8. Click Remove weakly referenced objects check box and click OK.

9. Double-click the object.
    A New Object Set dialog appears.

10. Click References radio button and click OK.
      JProfiler displays a Reference graph.

11. Right click on an object and select Show Paths to GC Root.
      A Path to GC Roots options dialog appears.

12. Click Single root radio button and then click OK.
      This locates and displays the link from a GC root object, a permanent object in memory that
      is not released, to this object.    

The GC root appears in yellow.

13. Follow path from selected object to GC root and look for collections, which appear with [] in the title
     similar to the following:

Collections typically are arrays or hash tables. These are most likely objects causing memory leaks, as the application puts objects in collections and then forgets about the collections. However, since the collection is referenced it cannot be destroyed.

After identifying a referenced object collection, to resolve the memory leak, locate this object in the source code and analyze what is happening with it.