JDK Diagnostic Tools

Both are free GUI tools that ship with (or pair with) the JDK to watch a live Java program: heap memory, garbage collection, thread count and CPU. jconsole is the minimal built-in monitor; VisualVM does more, including CPU/memory profiling and dumps.

jmap 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.

jstack is a JDK command-line tool that prints a thread dump: a snapshot of every thread in a running Java process and what line of code each one is currently executing. You use it when an app hangs, is frozen, or is using too much CPU.

Run 'jcmd <pid> Thread.print' to print every thread's stack. To diagnose a hang look for BLOCKED threads and deadlocks; for high CPU look for RUNNABLE threads stuck in the same code across several dumps.

RUNNABLE = the thread is running or ready to run. BLOCKED = it's stuck waiting to enter a synchronized block another thread holds. WAITING = it's parked indefinitely until notified. TIMED_WAITING = same but with a timeout (e.g. sleep). They tell you whether a thread is busy or stuck and on what.

jstat is a command-line tool shipped with the JDK that prints live JVM statistics, mostly about memory and garbage collection. You point it at a running Java process by its PID and it can repeat at an interval, e.g. jstat -gcutil 12345 1000 prints GC stats every 1000 ms.

GC.class_histogram lists how many instances and bytes each class uses — a quick memory overview. GC.heap_dump writes a full snapshot file you analyze in a tool to find leaks. GC.run requests a garbage collection. All can pause the app, so use them carefully in production.

VM.flags shows the JVM's -XX options actually in effect (heap size, GC, etc.). VM.system_properties shows the Java system properties (like java.version or user-set -D values). Together they let you confirm what the running JVM is really configured with versus what you intended.

Sampling periodically takes a snapshot of what each thread is running and adds up where time is spent — cheap but approximate. Instrumenting modifies the code to record every method call — precise but slow and it can skew the numbers.

It dumps the heap to a file. live includes only reachable objects (and runs a garbage collection first), format=b writes the standard binary .hprof format, and file=heap.hprof is the output path. 'live' matters because it filters out short-lived garbage so a leak stands out.

jstack automatically finds deadlocks. When two or more threads each hold a lock the other needs, jstack prints a 'Found one Java-level deadlock' section naming the threads and which lock each holds and waits for, so you see the cycle directly.

-gcutil shows the percentage full of each memory area — S0, S1 (survivor spaces), E (eden), O (old), M (metaspace), CCS (compressed class space) — plus counts and total times of young GCs (YGC/YGCT) and full GCs (FGC/FGCT), and the overall GC time (GCT).

Use jcmd to start, check, dump, and stop a flight recording: 'JFR.start', 'JFR.check', 'JFR.dump filename=...', 'JFR.stop'. JFR records CPU, allocations, locks, and GC over time at very low overhead, so it captures continuous behavior that one-off dumps miss.

First the live memory graph hints at a leak: used heap keeps climbing across GCs and never settles. Then you capture a heap dump — a snapshot of every object — and look for which classes hold the most memory and what chain of references keeps them alive so the garbage collector can't free them.

On the same machine the tools auto-discover and attach to local Java processes with no setup. To watch a JVM on another host or in a container, you must start it with JMX remote enabled (a port, plus authentication and TLS) and connect to that address.

Use -histo for a quick, cheap look at which classes have the most instances and bytes. Capture a full heap dump when you need to know why objects are kept alive — the reference chains and who is holding them — which only an analyzer working on a dump can show.

Run top with per-thread view (top -H) to find the OS thread eating CPU and note its thread id. Convert that decimal id to hexadecimal. Take a jstack dump and search for that hex value as the nid in a thread's header — its stack trace shows the exact hot code.

A single dump is just one instant, so you can't tell a momentarily-busy thread from a truly stuck one. Take several dumps a few seconds apart: a thread on the same stack frame in every dump is stuck, and many threads piling up on one lock across dumps reveals contention.

Run jstat -gcutil <pid> 1000 and watch over time. Frequent full GCs (FGC climbing) with growing FGCT and an Old region that stays high after each full GC point to GC churn or a leak. To find the actual culprit objects you still need a heap dump, because jstat only shows aggregate numbers, not what's filling the heap.

Dumping a large heap pauses the application: the JVM must stop all threads at a safepoint to walk the object graph, and live adds a full garbage collection on top. On a multi-gigabyte heap this can mean seconds of freeze plus heavy disk and memory pressure.

An MBean is a Java object that publishes data and actions for management tools. The MBeans tab in jconsole/VisualVM is a tree of all registered MBeans where you can read values and run operations live. You expose your own by defining an interface and registering it with the platform MBean server.

Each row shows a class with how many instances exist and how many bytes they use, sorted with the biggest memory users at the top. Start by looking at the rows with the most bytes, and watch out for your own application classes rather than just generic ones like byte[] or String.

-gcutil shows each region as a percentage full. -gc shows the same regions but as raw capacity and used bytes (in KB) plus GC times. -gccapacity shows the min, current, and max sizes each region is allowed to be. Use -gcutil for a quick health check, -gc for exact numbers, -gccapacity to see sizing limits.

jstat is a quick, low-overhead, command-line way to watch live GC and memory counters for one JVM. It's great for ad-hoc triage but it only shows aggregate numbers, samples one process interactively, and isn't a real monitoring system. For production fleets you use GC logs, JFR, and a metrics pipeline (e.g. Prometheus) instead.