Capturing a thread dump means asking the JVM to print the current state and full stack trace of every live thread, which is the go-to technique when a Java application appears frozen, unresponsive, or is consuming CPU without obvious cause.
Key Points: • The JDK's jstack <pid> utility is the traditional command for pulling a full thread dump from a running process by its OS process ID. • jcmd <pid> Thread.print is the newer, more actively maintained alternative bundled with recent JDKs and generally preferred going forward. • On Unix-like systems, sending SIGQUIT (Ctrl+\) to the JVM process prints the dump straight to standard output/error without needing a separate tool. • Application servers and monitoring tools (e.g. VisualVM, JConsole, or APM products) often expose a "thread dump" button that wraps the same underlying JVM mechanism with a friendlier UI. • Comparing several dumps taken seconds apart helps distinguish a thread that's momentarily busy from one that's genuinely stuck at the same stack frame every time — the latter points to a real deadlock or bottleneck.
Example: If a production server's CPU usage is unexpectedly high, capturing a thread dump with jcmd <pid> Thread.print and correlating it against the JVM's native thread IDs (visible via tools like top -H) lets you identify exactly which Java thread and stack frame is burning CPU.
Interview Tip: A concise interview answer is:
"To get a thread dump I'd use jcmd <pid> Thread.print, or the older jstack <pid>, both shipped with the JDK — or send a SIGQUIT to the process on Unix systems. It shows every thread's state and stack trace at that instant, which is essential for diagnosing hangs, deadlocks, or unexplained CPU usage."