- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- Solving performance problems
- CPU profiling
- Threads
- Deadlock detector
- Memory profiling
- Memory telemetry
- Memory snapshot
- Object allocation recording
- Shallow and retained sizes
- Memory views
- Objects view
- Class list
- Class and package
- Class loaders
- Web applications
- Object generations
- Reachability scopes
- Shallow size
- Object explorer
- Biggest objects (dominators)
- Allocations
- Object ages
- Merged paths
- Class hierarchy
- Method merged callees view
- Method back traces view
- Quick info view
- GC roots view
- Leak detection: working with paths
- Memory inspections
- Comparing memory snapshots
- Support of HPROF format snapshots
- Support of Java Flight Recorder (JFR)
- Support of Portable Heap Dumps (.phd)
- Values of primitive types
- Persistent object IDs
- Useful actions
- Set description language
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
- FAQ: How to profile in my scenario?
Reachability scopes
Reachability scopes distribute objects according to how/whether they are reachable from GC roots.
This information is helpful when analyzing the profiled application's memory consumption and searching for memory leaks. Also it helps examining excessive garbage allocation, especially if the snapshot doesn't contain recorded object allocation information.
- Strong reachable: objects reachable from GC roots via at least one strong reference, or being GC roots themselves. Such objects will not be garbage collected until all strong references to them are nulled and/or they remain GC roots. Thus, memory leaks should be searched among them.
- Weak/soft reachable: objects reachable from GC roots via weak and/or soft references only. Such objects can be deleted by garbage collector when it decides to free some memory. Such objects are not memory leaks, but they may deserve attention when you analyze memory consumption.
-
Dead objects: unreachable from GC roots, but not yet collected.
Once garbage collector decides to delete them, they will be deleted.
Objects of classes overriding
Object.finalize()
will be placed to the finalizer queue before actual deletion. - Objects pending finalization: objects in the finalizer queue.

In addition to the "Reachability scopes" view, header in the memory tab shows brief summary on the number of strong reachable objects, and if there are any, provides an easy way to open them in new tab, by clicking corresponding link (useful when analyzing memory leaks):

The reachability scope for individual objects (except strong reachable) is shown in Object explorer view:

Actions
Action Memory | Instances by Class... (Ctrl+N) allows you to choose the reachability scope of objects to open:
