Of course. Generating and analyzing dumps in a Linux environment for a Java application is a critical skill for troubleshooting issues like memory leaks, out-of-memory errors (OOM), and CPU spikes.

Here’s a comprehensive guide covering the main types of Java dumps, how to generate them, and how to analyze them.

The Three Main Types of Java Dumps

Understanding the difference between these three is crucial.

How to Generate Heap Dumps

A heap dump is the most common dump for memory-related issues.

Method 1: Automatic on OutOfMemoryError (Recommended)

This is the best practice. Configure your JVM to automatically generate a heap dump when it runs out of memory.

Command-line argument:

java -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/myapp/java_pid<pid>.hprof -jar myapp.jar

• -Xmx1024m: Sets the maximum heap size to 1GB.
• -XX:+HeapDumpOnOutOfMemoryError: The flag to enable automatic heap dump generation.
• -XX:HeapDumpPath: Specifies the file path for the dump. If omitted, it's created in the working directory of the JVM.

Method 2: Manually using jcmd (Recommended for live systems)

jcmd is a powerful, modern tool that is generally preferred over older tools like jmap.

1. Find the Process ID (PID) of your Java application.

   # To find all Java processes
   jps -l
   # Or using ps
   ps -ef | grep java

   Let's say the PID is 12345.

   
   （图片来源网络，侵删）

2. Generate the heap dump using jcmd.

   # The command format is: jcmd <PID> GC.heap_dump <filename>
   jcmd 12345 GC.heap_dump /var/log/myapp/manual_heapdump.hprof

   This will create the manual_heapdump.hprof file.

Method 3: Manually using jmap (Older method)

Note: Using jmap -dump on a running application can be a very heavy operation and may cause a long pause or even a timeout in your application. jcmd is safer.

# Find the PID (e.g., 12345)
# Generate the dump
jmap -dump:format=b,file=/var/log/myapp/jmap_heapdump.hprof 12345

How to Generate Thread Dumps

Thread dumps are essential for diagnosing performance, deadlocks, and high CPU.

Method 1: Using jstack (Standard)

1. Find the PID of your Java application (e.g., 12345).
2. Generate the thread dump.

   jstack 12345 > /var/log/myapp/thre_dump.log

   You can run this command multiple times to get a series of thread dumps over time, which is very useful for identifying bottlenecks.

Method 2: Using jcmd (Modern alternative)

# The command format is: jcmd <PID> Thread.print
jcmd 12345 Thread.print > /var/log/myapp/jcmd_thre_dump.log

Method 3: Using kill -3 (Useful when you can't run jstack)

If you have SSH access to the server but not the ability to install/run jstack (e.g., in a restricted container), you can send a signal to the process.

1. Find the PID (e.g., 12345).
2. Send the SIGQUIT signal.

   kill -3 12345

   The thread dump will be printed to the standard output of the Java process. If the application is running as a service (e.g., Tomcat, Spring Boot), this output is typically captured in its log file (e.g., catalina.out, myapp.log).

How to Generate Core Dumps

Core dumps are for low-level crashes and are usually not needed by application developers. You need to configure the system first.

Step 1: Configure Core Dump Settings

By default, Linux often limits or disables core dumps. You can change this for the current session or permanently.

For the current session:

# Allow unlimited core file size
ulimit -c unlimited
# Set the output pattern for core dumps (e.g., core.PID)
# The %p will be replaced by the process ID.
export CORE_PATTERN="core.%p"

To make it permanent (e.g., for a user): Add the following lines to ~/.bashrc or ~/.profile:

ulimit -c unlimited
export CORE_PATTERN="core.%p"

Step 2: Trigger the Core Dump

This will crash your JVM, so only do this if you are trying to diagnose a crash.

1. Find the PID (e.g., 12345).
2. Send a SIGSEGV signal to cause a segmentation fault.

   kill -11 12345

   After the process crashes, you will find a file named core.12345 in the directory where the JVM was running.

How to Analyze the Dumps

You cannot open .hprof or .threaddump files with a standard text editor. You need specialized tools.

Analyzing Heap Dumps (.hprof files)

The most popular tool is Eclipse MAT (Memory Analyzer Tool).

1. Download and install Eclipse MAT from the official website.
2. Launch MAT and open your .hprof file.
3. MAT will automatically analyze the dump and present you with a "Leak Suspects Report". This is often all you need to identify the cause of a memory leak.
4. Key Features:
   • Dominator Tree: Shows which objects are retaining the most memory. This is the best place to start.
   • Histogram: Shows a count of all objects and their total memory footprint, grouped by class.
   • Path to GC Roots: Shows you the chain of references that is preventing an object from being garbage collected.

Other tools:

• VisualVM: Bundled with the JDK. Good for basic analysis and monitoring a running JVM.
• JProfiler: A commercial, very powerful profiler.
• YourKit: Another commercial, highly-rated profiler.

Analyzing Thread Dumps (.threaddump files)

You can analyze these with a simple text editor or a dedicated tool.

Manual Analysis (with a text editor): Look for these common patterns:

• Deadlock: Search for the word "Deadlock". MAT will often detect this for you in a heap dump too.
• Blocked Threads: Look for threads with state "RUNNABLE" that are waiting on a lock, or "BLOCKED" on a monitor.
• CPU Hogs: Find threads with "RUNNABLE" state that have been running for a long time. Examine their stack traces to see what code they are executing.
• Waiting Threads: Threads in "WAITING" or "TIMED_WAITING" state are usually idle, waiting for a notification or a timer to expire.

Using Tools:

• FastThread: A simple, web-based analyzer. Just paste your thread dump.
• IBM Thread and Monitor Dump Analyzer for Java (TMDA): A command-line tool that can parse thread dumps and detect deadlocks, locks, etc.
• VisualVM: Can parse and display thread dumps graphically.

Summary Workflow for an OOM Error

1. Reproduce the Issue: Try to trigger the OutOfMemoryError again.
2. Check Logs: Look for the OutOfMemoryError message. The JVM should have automatically created a heap dump.
3. Locate the Heap Dump: Find the .hprof file at the path specified by -XX:HeapDumpPath or in the application's working directory.
4. Analyze with MAT:
   • Open the .hprof file in Eclipse MAT.
   • Review the Leak Suspects Report first.
   • If that's inconclusive, open the Dominator Tree to find the largest objects and see what is holding them in memory.
   • Use the Path to GC Roots on the large suspect object to find the reference chain causing the leak.
5. Check for Threads: While the application is struggling (or before it crashes), take a few thread dumps using jstack or kill -3. Analyze them to see if threads are stuck, deadlocked, or consuming excessive CPU.