What is jmap, and what are its two most common uses for inspecting a running Java application's heap?
answer
- JDK heap-inspection tool, attaches by pid
- -histo = class histogram (counts + bytes)
- -dump = .hprof snapshot for MAT/VisualVM
- 'live' forces a GC first
- jcmd is the modern replacement
basics
~20 sjmap is a JDK command-line tool that inspects a running Java program's heap (its object memory). Its two main uses are printing a histogram of how many objects of each class exist, and dumping the whole heap to a file for offline analysis.
solid answer
~50 sjmap ("Java memory map") is a diagnostic command-line tool shipped with the JDK that connects to a live JVM by its process id and reports on the heap, the region of memory where Java objects live. Two uses dominate. First, `jmap -histo <pid>` prints a class histogram: for every class, how many live instances exist and how many bytes they occupy, sorted by size. It is the fastest way to see what is filling memory. Second, `jmap -dump:live,format=b,file=heap.hprof <pid>` writes a binary heap snapshot (an .hprof file) to disk; you then open that file in Eclipse Memory Analyzer (MAT) or VisualVM to walk object graphs and find leaks offline. jmap attaches to a process you already started; it does not launch one. On modern JDKs `jcmd` provides the same operations and is the recommended front end.
go deeper
Knows jmap inspects a running JVM's heap and can name the two uses: histogram and heap dump.
Can run both commands with correct flags, knows 'live' forces a GC, and knows to open the .hprof in MAT/VisualVM.
Explains when a histogram suffices vs needing a full dump, the permission/attach model, and that jcmd is the modern front end.
Frames jmap within a memory-diagnostics strategy: automated dumps on OOM, safepoint/pause cost in prod, and choosing the lightest tool that answers the question.
## What problem jmap solves A running Java program stores its objects in a region of memory called the **heap**. When a program uses too much memory, runs out of memory (an `OutOfMemoryError`), or slowly grows over hours (a **memory leak** — objects that are kept alive by mistake and never freed), you need to look *inside* the heap to see which objects are there. **jmap** ("Java memory map") is a command-line tool that ships with the **JDK** (Java Development Kit) for exactly this: it attaches to an already-running JVM and reports on its heap. ## Key terms, defined - **JVM (Java Virtual Machine):** the process that runs your Java program. Every running Java app is one JVM process with a numeric **pid** (process id). - **Heap:** the memory area where all Java objects (instances of classes) live. The **garbage collector (GC)** automatically frees objects that are no longer reachable. - **Live object:** an object still reachable from the running program (referenced by a thread, a static field, etc.). Live objects cannot be collected; only *unreachable* ones can. - **Histogram:** a table — here, one row per class with a count and a byte total. - **Heap dump:** a complete snapshot of every object in the heap, written to a file, so you can analyze it later on another machine. ## How you use it You first find the pid with `jps` (a JDK tool that lists running Java processes) or `jcmd`. Then: **1. Histogram — `jmap -histo <pid>`** prints rows like `instances bytes class name`, sorted with the biggest consumers at the top. For example you might see millions of `byte[]` and `java.lang.String` instances. Adding `live` (`-histo:live`) first forces a garbage collection so only reachable objects are counted — useful to tell a real leak from short-lived garbage. The histogram answers "*what kind* of object is eating memory?" but not "*who is holding it*." **2. Heap dump — `jmap -dump:live,format=b,file=heap.hprof <pid>`** writes a binary snapshot. The flags mean: `live` = include only reachable objects (runs a GC first); `format=b` = binary (the standard **.hprof** format); `file=` = output path. You then load `heap.hprof` into a heap analyzer such as **Eclipse MAT (Memory Analyzer Tool)** or **VisualVM**, which shows the object graph, **dominator tree** (which object keeps the most memory alive), and **GC roots** (the reference chains keeping a suspected leak alive). This is the workhorse for finding leaks. ## Important boundaries - jmap **attaches** to a process you already started — it does not run your program for you. - It must run as the **same OS user** that owns the target JVM (or as root) because it uses the JVM's attach mechanism. - On current JDKs, `jcmd <pid> GC.class_histogram` and `jcmd <pid> GC.heap_dump <file>` do the same things and are the recommended modern interface; jmap remains for compatibility.
- How do you find the pid to give jmap?Run `jps` (lists running Java processes with their pids and main classes) or `jcmd` with no arguments, which also lists JVMs.
- Why might jmap fail to attach to a process?Most often a permissions mismatch — jmap must run as the same OS user as the target JVM (or root) to use the attach API; otherwise it is denied.
A histogram is like a grocery receipt totaled by category — it tells you milk cost the most. A heap dump is like a photo of your whole fridge — you can open it later and trace exactly which carton is going bad and who left it there.
saying these in an interview costs you the question
- Thinking jmap launches or profiles your app continuously — it is a point-in-time attach, not a running profiler
- Believing -histo tells you what is leaking — it shows counts/bytes by class, not the reference chains holding objects
- Confusing a heap dump (objects) with a thread dump (stacks) — that is jstack, not jmap