Component Report

A heap dump contains many objects. But which of those belong to your component? And what conclusions can you draw from them? This is where the Component Report can help.
Press the Help button for more detailed information.

Open a Heap Dump

The analysis is based on heap dumps. Consult the help pages on how to acquire a heap dump of your application.
If you do not already have a heap dump, use the link below to open a sample heap dump.

Run the Component Report

Before starting, one has to decide what constitutes a component. Typically, a component is either a set of classes in a common root package or classes loaded by the same class loader.
To select a set of packages:
Choose Leak Identification -> Component Report from the Query drop-down list in the toolbar.
Provide a class name pattern (for example java.util.*) and hit Finish.
The Component Report consists of HTML pages. It is stored in a ZIP file next to the heap dump file.

Getting an Overview

» The size of the component relative to the size of the whole heap.
» The Top Consumer section lists the biggest object, classes, class loader and packages.
» The Retained Set is a histogram of all objects kept alive by the component.

Duplicate Strings

Duplicate Strings are a prime example for memory waste: multiple char arrays with identical content.
The content of the char arrays typically gives away ideas how to reduce the duplicates.

Empty Collections

Empty collections take up space without storing any data. If only a few collections actually hold data, think about lazy initialization, i.e. create the collection only when needed.

Collection Fill Ratios

Collections are typically created with a default initial capacity. Many collections with low fill ratios indicate that the initial capacity could be reduced.

Soft Reference Statistics

Softly referenced objects require more GC activity (possibly during a stop-the-world phase) and should be used in small doses only.

Finalizer Statistics

Finalizers come with a lot of drawbacks: For example, they require multiple Garbage Collections to run until the objects are actually freed. Also, the time of the execution is up to the VM which makes Finalizer unpredictable.

Map Collision Ratios

Maps place the values in different buckets based on the hash code of the keys. High collision ratios can indicate sub-optimal hash codes. This is not a memory problem (a better hash code does not save space) but rather performance problem because of the (usually) linear access inside the buckets.