This document shows an example using Heap
Inspector to identify a Java memory leak.Step 1. The Java ProgramEnter and compile the following java program.
Run the application from the console window to ensure that it is working correctly.
Below is a screen shot of the sample application in action. Pressing the "Show JOption Dialog" button will create and show an instance of the swing class JOptionPane. What isn't apparent is that every time the JOptionPane is dismissed by pressing the OK button, a memory leak is created (this has been fixed in 1.1.8).
Step 2. Run the application using Heap Inspector.Now run the same application, this time using the Heap Inspector bootstrap.
Press the 'Refresh' button to show a listing of all the objects present in the Java VM. Enter the substring 'javax.swing.JO' in the filter text field and then press 'Refresh' again. Now only instances whose class name begins with 'javax.swing.JO' will be shown in the list.
Step 3. Identify the JOptionPane's gc root.Using the MessageTester application, create and dismiss a few message dialogs. Then refresh the list again and notice that none of the JOptionPane instances are being garbage collected. Right click on one of the instance nodes in the tree. This expands the tree to show the root reference which is keeping the instance in memory. In this case, it is a static reference from the class sun.awt.SunToolkit. The reference is being kept in memory because of a bug in the class java.awt.LightweightDispatcher.
That's it. Heap Inspector can be quite useful in determining what is keeping top level application objects like javax.swing.JFrame in memory. You can find more information on the memory leak
described above at: |