# Exercise 1.3: Analyzing leak candidates

Before you begin, you must complete Exercise 1.2: Capturing heap dumps.

In this exercise, you will first generate a list of objects (such as arrays, vectors, and sessions) that appear to be leaking. These are the "leak candidates." You will then analyze the list to identify any leaks.

### Generating a list of leak candidates

To generate the list:

1. Following the instructions in the Leak Candidates view, click the Analyze for Leaks toolbar button . The Select Leak Analysis Options dialog box opens.
2. In the dialog box, make sure that the check boxes for your two heap dumps are checked.
   Note: The value for Threshold is set by default to 20. This means that only leak candidates with a Likelihood value of 20 or higher are displayed. (More information about Likelihood values is provided later in this Exercise.)
3. Click OK to generate the list. The indicator at the lower-right corner of the Software Development platform reports that it is finding leak candidates.

### An overview of the Leak Candidates view

When the process is complete, the Leak Candidates view displays a list of leak candidates.

Each candidate has a likelihood value between 100 and 1, with the most likely candidate having a value of 100. The other candidates are ranked accordingly, and are listed in order of descending likelihood. (The heap-comparison algorithm calculates likelihood values based on the size of the leak and on its growth during the interval between the two heap dumps.)

The Threshold value was set to 20 for this profiling run; any candidates with a Likelihood value of 19 or lower will not be displayed.

The view provides the following data for each leak candidate:

- Root of leak. This is the top-level root object that is holding references to the potentially leaked objects.
- Container type. This is a collection object that is holding the leaked objects. Leaks are most likely to occur in collection objects, such as vectors and lists.
- What's leaking. This is the type of the leaked objects.
- Number of leaks. This value represents the number of objects of the type specified in the "What's leaking" column that are in the container object. These objects may in turn refer to other objects. The "Objects leaked" and "Bytes leaked" columns include these referenced objects.
- Bytes leaked.
- Objects leaked.

### Analyzing and identifying the leak

To identify the leak:

1. In the Leak Candidates view, look at the data for the leak candidate that has a likelihood of 100:
   - The root of the leak is `TestThreeTierQueue.<ObjectID>`
   - The container type is `vector`.
   - The vector is leaking strings. In other words, the vector is holding on to references to strings that, judging from the number of leaks and the number of bytes leaked, it should be releasing so that garbage collection can free up the memory. (The number of leaks and the number of bytes leaked will probably be different every time you run this program, depending on the timing of the captured heap dumps.)
2. Double-click the leak candidate. The Object Reference Graph view opens, and displays graphical data for the leak candidate. (Note that it might take some time to prepare the heap dump for display.)
3. Examine the object reference graph. Note the following points:
   - The graph highlights the objects that are connected, by references, with the potential leak: the root of the leak, down through the SecondaryQueue, to the vector, and finally to the leaked set of strings. This provides a visual image of what is leaking.
   - In the graph, there is an `Object` array that is referenced by a `Vector` (the container type involved in the leak), and the `Object` array references the leaking `String` objects.
4. Pause your cursor over the path connecting the `Object` array and `String`, and read the tool-tip that is displayed: It shows a "Count" equal to the Number of Leaks displayed in the Leak Candidates view, so this is the collection of strings that has been identified as the leak.
5. Note that both the Secondary and the Tertiary Queues are holding references to the `Object` array, but the Tertiary Queue isn't identified in the Leak Candidates view as leaking. There are several possible explanations for this:
   - The Tertiary Queue might in fact be leaking, but at a slower rate than the Secondary Queue. If you ran the leak analysis again with a threshold value below the default value 20, you might see a leak displayed for the Tertiary Queue.
   - The Tertiary Queue might have good reasons for holding on to the references to the `[Object` array object, so that the memory is not being leaked, just retained. You will know the answer after you fix the code for the Secondary Queue and rerun the improved application.
6. In the object reference graph, double-click the `String` object. The Object Details view opens. It displays all the details for the `String` object, including all objects that refer to it, and all objects to which it, in turn, refers. Note that, in the Object Details view, you can navigate up through referers by clicking one of them, or down through referees (objects to which the object refers) by clicking one of them.

What have you found out? You now know that the Secondary Queue is the leaking object, and that it is leaking because a `Vector` object is retaining references to many `String` objects.

Now you are ready to begin Exercise 1.4: Fixing the memory leak.

Terms of use | Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.