Eclipse Memory Analyzer Tool is one of the best tools to analyze JVM heap dumps and to understand the memory allocations, memory leaks etc., Below listed are kind of pointers to what MAT gives and what they actually mean in analyzing the heap dump
The Overview report is the best one to start. It gives
size of your heap dump - which could be very less than the XMX or in most of the cases a bit larger than the XMX. The first case examples are - OOM thrown not in the heap but other areas like perm space, TLA or may be it just could not allocate a large char array say gt. 2GB while there is still lot of free space or sometimes not able to dump large collection of objects which are pending with finalizer thread.
Classes: number of classes loaded
Objects: number of objects loaded
Class Loaders: number of class loaders
Unreachable objects histogram: these are normally removed during analysis but can be set not to by using preference 'keep_unreachable_objects'
The overview report also gives pointers on where to look..
Histogram - gives the number of instances per class.
you can obtain the shallow & retained sizes (shallow heap is the mem. occupied by one object of a class. retained heap is the sum of shallow sizes of all the objects of a class)
you can calculate the approx. or precise retained size of a class or package. group the histogram view at package level or a class loader..
you can also explore the top packages or class loaders by going through outgoing references. outgoing references are basically the tree nodes or leaves that a specific object refers to. Incoming references of an object are basically all the links i.e. references that kept the object alive
Dominator tree - is an object graph showing all the dominators list. it is basically showing all the 'dominating' links of an object tree.
top consumers - it is similar to grouping the histogram view by packages. But nice report to know which packages are the top consumers of the memory. So that we can further explore which classes of the top consuming packages are being instantiated or retaining more space and what are their immediate dominators or gc roots
duplicate classes - gives the list of duplicate classes loaded by different class loaders. If your perm gen space is filling up then probably this view will give good indication on what classes are being loaded and duplicate list.
In addition to above, there are 2 good reports given by MAT
Leak Suspects:It points out what are the biggest objects occupying the memory. They may or may not be the leaks but worth to begin the investigation with. It tells how many instances and memory consumed by each instance. you can also get the gc root information like which gc root like a thread, class loader etc., have instantiated the objects. (This can be obtained from leak hunter report.) It also gives system & thread overview, top consumers, class histograms.
Top Components: use this if there are no heavy objects found by leak suspects. This report will give detailed analysis for all the objects occupying gt. 1% of heap.
Finalizers: this is one more important feature to see what the finalizers are doing. Finalize methods will be executed to free up the object. sometimes if there a long running code in finalize method or a lock in the finalize method could delay in cleaning up the heap. This could result in large accumulation of objects pending for finalization. in MAT, go to Java Basics -> Finalizer Overivew to view these stats. If Finalizer Overview does not show any data then check the thread which is doing finalization like 'Finalizer thread' in weblogic and check how much space it has retained. If that does not show any significant memory held and the heap dump is not the same size as reported in verbose GC logs just before the dump then live monitoring of class histogram is the option. It could be that there are huge number of objects loaded and not live and waiting to get finalized.
you can also query the heap using OQL, analyze threads to see thread stacks, URLs, thread states etc., java collection usage,
Knowing all the above, A quick way to analyze the heap dump is take a look at the leak suspects after getting a high level idea from overview report. see if there are any large collection of an objects is being loaded and by which class loader. now get the path to gc roots (or merge shortest path option for top instances by retained size) from histogram if not given in the suspects report, to find out who is/are holding these objects in the memory. once we know who is holding, now see what the object contains i.e. the content. sometimes there will be a single object holding large amount of memory like some big xml report generation or there could be large collection of small objects occupying the memory. In the second case see why so many instances rather than the size of each instance.
