...
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.
...
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.
...