jcmd

## What jcmd is **The JVM (Java Virtual Machine)** is the process that runs your Java program. While it runs, it holds rich internal state: the heap (where objects live), all the threads, the chosen garbage-collector settings, system properties, and more. To *inspect or influence* that state from outside, the JDK ships a family of command-line **diagnostic tools** in its `bin/` directory. Historically these were *one tool per job*: `jmap` (heap dumps, histograms), `jstack` (thread dumps), `jinfo` (flags/properties), `jstat` (GC statistics). **jcmd** is a single tool that subsumes most of them. You give it a target JVM and a *sub-command*, and it asks that JVM to perform a diagnostic action and return the result. ## How you invoke it ``` jcmd # list every JVM you can attach to (pid + main class) jcmd <pid> help # list the diagnostic commands THIS jvm supports jcmd <pid> help <command> # show the arguments for one command jcmd <pid> <command> [args] # run it ``` The target is identified by its **PID (process id)**. You can also use the main-class name instead of a numeric pid. Examples: ``` jcmd 4242 Thread.print jcmd 4242 GC.heap_dump /tmp/app.hprof jcmd MyApp VM.flags ``` ## Why it works — the attach mechanism jcmd does not read another process's memory directly. It uses the JVM **attach API / serviceability agent path**: it signals the target JVM, the target spins up an internal attach listener, and the two communicate over a local socket (a file under the temp dir on Linux/macOS). Because of this: - The target JVM must be **running** and must accept attach (it does by default unless `-XX:+DisableAttachMechanism` was set). - jcmd must run as the **same OS user** as the target (or with sufficient privilege) and normally **on the same host** — it is not a remote tool. ## Why it replaces jmap / jstack 1. **Unification.** One binary, one mental model, one help system. Discoverability is built in: `jcmd <pid> help` lists exactly what the *running* JVM supports. 2. **Safety.** The old tools could fall back to a *forced* mode that paused or even risked the target. jcmd uses only the cooperative attach path, so it is safer on production JVMs. 3. **Maintenance.** `jmap`/`jstack`/`jinfo` are effectively legacy (some marked for removal); new diagnostic capabilities (JFR control, finer GC commands, NMT) are added to jcmd, not to the old tools. 4. **No flag-juggling.** Each legacy tool had its own flags and quirks; jcmd presents a consistent `command arg=value` grammar. ## The command families you should know - **Threads:** `Thread.print` → a full thread dump (stack of every thread, lock info) — the jstack replacement. - **Heap:** `GC.heap_dump <file>` → an HPROF heap dump; `GC.class_histogram` → per-class instance counts/bytes; `GC.run` → request a full GC — the jmap replacements. - **VM introspection:** `VM.flags` (all the -XX flags in effect), `VM.system_properties`, `VM.version`, `VM.command_line`, `VM.uptime` — the jinfo replacements. - **JFR (Java Flight Recorder):** `JFR.start`, `JFR.dump`, `JFR.stop`, `JFR.check` → start/stop/collect a low-overhead profiling recording. - **NMT (Native Memory Tracking):** `VM.native_memory` (when started with `-XX:NativeMemoryTracking=summary`). ## Bottom line jcmd is the *front door* to JVM diagnostics: discover JVMs (`jcmd`), discover commands (`jcmd <pid> help`), then run them. It is preferred over the scattered legacy tools because it is unified, safer, discoverable, and where new capabilities land.