http://www.ej-technologies.
JProfiler is a powerful Java Profiling tool for Performance Engineers.
I have mentioned how to verify Memory leaks using JProfiler
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.
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.
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.
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.
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.
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.
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.
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.
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.
.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.
A New Object Set dialog appears.
10. Click References radio button and click OK.
JProfiler displays a Reference graph.
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.
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.
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:
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.
