The following 4-step approach proved to be most efficient to detect memory issues:
This sequence of actions is automated in Memory Analyzer by the Leak Suspects Report.
The following table contains a list of queries that are most helpful in analyzing memory leak issues.
| Dominator Tree | In Dominator Tree every node is responsible for keeping its children alive. The tree is sorted by the retained size, so you find single big objects easily. When there is no single object responsible for big memory consumption it is helpful to group the result by class and class loader to reveal big memory chunks. |
| Top Consumers | Top Consumers query returns information about the biggest objects grouped by class, class loader, and package. |
| Paths to GC Roots | Paths to GC Roots query helps to identify who is responsible for keeping a single object in the heap. It is reasonably to run this query on a possible suspect (memory accumulation point), which you can find e.g. using Big Drops in Dominator Tree Query (see Big Drop entry further down for more details). |
| Duplicate Classes | Lists classes loaded multiple times. Grouping the result by class loader points to the class loaders that load the same class multiple times. Possible cause: Several versions of the same library are deployed. |
| Leaking Bundles | For snapshots for older versions of Eclopse, list bundles which are stale and should have been garbage collected. For newer versions of Eclipse, the duplicate classes query might be an alternative. |
| Big Drops in Dominator Tree Query | Displays memory accumulation points in the dominator tree. Displayed are objects with a big difference between the retained size of the parent and the children and the first "interesting" dominator of the accumulation point. These are places where the memory of many small objects is accumulated under one object. |
| Leak Suspects Report | The Leak Suspects query analyzes the heap dump, searches for memory leak and provides an illustrative description of the identified suspects. |