What is jstack and what does it produce? When would you reach for it?
answer
- JDK CLI tool → prints a thread dump
- Snapshot of every thread + state + stack trace
- Run as jstack <pid>; pid from jps/ps
- First tool for hangs, deadlocks, high CPU
- Plain text → works headless over SSH
basics
~20 sjstack 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.
solid answer
~50 sjstack is a command-line tool shipped with the JDK that captures a thread dump from a live JVM (or a core file). A thread dump is a point-in-time snapshot listing every thread, its name, its state (RUNNABLE, BLOCKED, WAITING, TIMED_WAITING), and its full stack trace. You run it as `jstack <pid>`, where the pid comes from `jps` or `ps`. It is the first tool you reach for to diagnose a hung or unresponsive application, to see what threads are stuck on, to find lock contention, or to locate the hot code path during a high-CPU incident. It is lightweight (it doesn't pause the app for long) and produces plain text, so it works over SSH on a headless server where a GUI profiler can't. For transient problems you take several dumps a few seconds apart and compare them.
code
java · 16 lines// 1. Find the JVM's process id:
// $ jps -l
// 12345 com.example.MyApp
//
// 2. Capture a thread dump:
// $ jstack 12345 > dump1.txt
//
// 3. (modern equivalent)
// $ jcmd 12345 Thread.print > dump1.txt
//
// A single thread entry in the output looks like:
//
// "http-nio-8080-exec-3" #42 prio=5 RUNNABLE
// java.lang.Thread.State: RUNNABLE
// at com.example.OrderService.compute(OrderService.java:88)
// at com.example.OrderController.handle(OrderController.java:31)
go deeper
Knows jstack prints a thread dump for a running Java process and is used when the app hangs; can run jstack <pid>.
Explains the four thread states and stack traces, finds the pid via jps, and knows -l/-F flags and the kill -3 alternative.
Uses multiple dumps over time, correlates with top -H for CPU, reads lock ownership, and chooses jcmd Thread.print in production.
Builds dump capture into incident runbooks/automation, reasons about safepoint/attach cost, and standardizes triage across services.
## What a thread is A **thread** is an independent path of execution inside a process. A Java program always has many: the `main` thread, garbage-collection threads, and any threads your code or frameworks (web servers, thread pools) create. At any instant each thread is either running on a CPU, waiting for something, or blocked. ## What a thread dump is A **thread dump** is a snapshot, taken at one instant, of *every* thread in a JVM. For each thread it lists: - the thread **name** (e.g. `http-nio-8080-exec-3`), - its **state** (RUNNABLE / BLOCKED / WAITING / TIMED_WAITING), - its **stack trace** — the chain of method calls from where it started down to the exact line it is on right now, - which **locks (monitors)** it holds and which it is waiting to acquire. It is *not* a heap dump (that captures objects/memory). A thread dump captures *what code is running*, not *what data exists*. ## What jstack is **jstack** is a small command-line utility that ships inside the JDK's `bin/` directory. Given the **process id (pid)** of a running JVM, it attaches to that JVM and prints a thread dump to standard output as plain text: ``` jstack 12345 ``` You find the pid with **jps** (a JDK tool that lists running Java processes) or the OS `ps` command. There are flags: `-l` adds extra lock/ownable-synchronizer info, `-e` (newer JDKs) prints extended thread details, and `-F` forces a dump from a hung process that won't respond normally. ## When you reach for it - **The app is hung / frozen** — requests stop completing. The dump shows what every thread is stuck waiting on. - **A deadlock** — jstack explicitly detects and prints `Found one Java-level deadlock`. - **High CPU** — you correlate the busy OS thread (from `top -H`) with a Java thread in the dump to find the hot loop. - **Lock contention** — many threads BLOCKED on the same monitor reveal a bottleneck. ## Why it's the go-to tool It is **free, built in, lightweight, and text-based**. Because the output is plain text it works over SSH on a server with no display, unlike GUI tools (VisualVM, jconsole). The cost of taking one dump is tiny, so it's safe to run on production. For problems that come and go you take **several dumps over time** and compare — a thread stuck on the same frame across all of them is your culprit. ## Alternative ways to get the same dump Sending `SIGQUIT` to the JVM (`kill -3 <pid>`) makes the JVM itself print a thread dump to its standard output / logs — the same information without the jstack tool. `jcmd <pid> Thread.print` is the modern, preferred equivalent.
- How do you find the pid to pass to jstack?Use jps (lists running JVMs with their main class) or the OS ps command; jcmd and jps both come with the JDK.
- What's a modern alternative to jstack for the same output?jcmd <pid> Thread.print, or sending kill -3 (SIGQUIT) to make the JVM print a dump to its own stdout/logs.
saying these in an interview costs you the question
- Confusing a thread dump (what code runs) with a heap dump (what objects exist) — jstack does NOT show memory
- Thinking jstack profiles over time; a single dump is one instant — take several to see trends
- Believing it needs a GUI; it is pure command line
- Assuming you need a special agent or restart; you attach to an already-running JVM by pid