jstack

Print Java stack traces for all threads in a Java process

$ jstack [java_pid]

$ jstack -m [java_pid]

$ jstack [/usr/bin/java] [file.core]

jstack [ options ] <pid>
jstack [ options ] <executable> <core>

<pid>
    The process ID of the target Java application. This is the most common way to use jstack.

<executable>
    The path to the Java executable that generated the <core> dump. Used when analyzing a core dump.

<core>
    The path to the core dump file to be analyzed. Used in conjunction with <executable>.

-l
    Performs a long listing. Prints additional information about java.util.concurrent locks. This is especially useful for detecting deadlocks involving these types of locks, showing owned and waiting monitors.

-F
    Forces a stack dump. Use this option if the initial jstack <pid> command is unresponsive (e.g., due to the JVM being in a hung or unresponsive state). This option can only be used with a <pid>.

-m
    Prints both Java and native C/C++ frames (mixed mode). This is helpful when debugging issues involving Java Native Interface (JNI) calls or native libraries, as it shows the complete call stack across language boundaries.

-h, --help
    Displays the help message for the command and exits.

-V, --version
    Prints the version information of the jstack utility and exits.

The jstack command is a utility provided with the Java Development Kit (JDK) that prints Java stack traces of all Java threads for a given Java process or core dump. It is an invaluable tool for diagnosing issues such as deadlocks, performance bottlenecks, or understanding the runtime state of a Java application. By analyzing the output, developers can determine what each thread is doing, which methods are being executed, and which locks are held or waited upon. It attaches to a running Java Virtual Machine (JVM) process, or can analyze a core dump file generated from a crashed JVM, providing a snapshot of the thread activity at that moment. This tool is essential for deep-dive troubleshooting of Java applications.

Requires the Java Development Kit (JDK) to be installed on the system, not just the Java Runtime Environment (JRE).
The user running jstack must have sufficient permissions to inspect the target Java process (e.g., running as the same user as the JVM, or with root privileges).
While generally non-intrusive, jstack may momentarily pause the target JVM for a very short duration while collecting thread information.
Using the -F (force) option should be done with caution, as it bypasses normal communication and might sometimes be more disruptive, though it is usually safe for diagnostics.
The output can be very large for applications with a high number of active threads, requiring careful analysis.

The output of jstack provides a detailed snapshot of each thread's state, crucial for diagnostics:
Thread State: Indicates whether a thread is RUNNABLE (actively executing), BLOCKED (waiting for a monitor lock), WAITING (indefinitely waiting for another thread to perform an action), or TIMED_WAITING (waiting for a specified time).
Stack Trace: The sequence of method calls that led to the current execution point of the thread, showing the exact line number where the thread is paused or executing.
Lock Information: For BLOCKED or WAITING threads, it shows which monitor or lock the thread is waiting for, and which object it is trying to acquire. The -l option provides more granular detail on java.util.concurrent locks.

Analyzing this output helps identify common issues such as deadlocks (where two or more threads are BLOCKED, each waiting for a resource held by another), infinite loops, or performance bottlenecks caused by contention for shared resources or long-running operations.

jstack has been a fundamental diagnostic tool within the Java Development Kit (JDK) since its early versions, prominently available since Java SE 5. Its primary function of providing thread dumps has remained consistent, evolving alongside Java's concurrency utilities and debugging capabilities. It serves as a staple utility for profiling and troubleshooting Java applications in both production and development environments, reflecting the continuous need for detailed runtime insights.

jps(1), jcmd(1), jmap(1), jinfo(1), kill(1), gdb(1)