如何从Kubernetes（k8s）Pod获取并分析Java堆转储？

Hey there! Let me walk you through exactly how to grab a Java heap dump from a Kubernetes Pod and then analyze it step by step. I’ve done this dozens of times, so let’s break it down clearly.

First up, we need to get the heap dump file out of your running Java Pod. Here's how:

1. Locate your target Pod #

Start by listing all your Pods to find the one running your Java app:

kubectl get pods

Note down the name of your target Pod (e.g., my-spring-app-7f9d6c8d4-2xqzk). If your Pod has multiple containers, confirm the Java container name with:

kubectl describe pod <your-pod-name>

2. Generate the heap dump inside the Pod #

You have two options here—either jump into the Pod or run the command directly from your local terminal.

Option A: Enter the Pod and run commands manually #

• Connect to the Java container in your Pod:

  # Omit -c <container-name> if your Pod only has one container
  kubectl exec -it <your-pod-name> -c <java-container-name> -- /bin/bash
  

• Find the Java process ID (PID):

  ps aux | grep java
  

  Look for the PID column (usually the second number) of your main Java process.
• Generate the heap dump with jmap:

  jmap -dump:format=b,file=/tmp/heapdump.hprof <java-pid>
  

• Exit the Pod shell:

  exit
  

Option B: Run the command directly (no need to enter the Pod) #

If you want to skip entering the Pod, you can chain commands:

• First, get the Java PID:

  kubectl exec <your-pod-name> -c <java-container-name> -- ps aux | grep java
  

• Then generate the heap dump in one go:

  kubectl exec <your-pod-name> -c <java-container-name> -- jmap -dump:format=b,file=/tmp/heapdump.hprof <java-pid>
  

Pro tip: If jmap isn't available #

Some lightweight Java images only include the JRE (not the full JDK). In that case, use jcmd instead (it’s included in most modern JREs):

kubectl exec <your-pod-name> -c <java-container-name> -- jcmd <java-pid> GC.heap_dump /tmp/heapdump.hprof

3. Copy the heap dump to your local machine #

Once the dump is saved in /tmp/heapdump.hprof inside the Pod, copy it to your local system:

# Again, omit -c <container-name> if single-container Pod
kubectl cp <your-pod-name>:/tmp/heapdump.hprof ./local-heapdump.hprof -c <java-container-name>

If the dump is huge, compress it first to save bandwidth:

# Compress inside the Pod
kubectl exec <your-pod-name> -c <java-container-name> -- gzip /tmp/heapdump.hprof
# Copy compressed file
kubectl cp <your-pod-name>:/tmp/heapdump.hprof.gz ./local-heapdump.hprof.gz
# Unzip locally
gzip -d local-heapdump.hprof.gz

Now that you have the dump locally, let’s analyze it with three easy-to-use tools.

Tool 1: JDK’s built-in jhat (quick and simple) #

If you have a JDK installed locally, jhat is a no-fuss option:

• Run the command to start the analysis server:

  # For large dumps, allocate more memory with -J-Xmx (e.g., 4GB)
  jhat -J-Xmx4g ./local-heapdump.hprof
  

• Open your browser and go to http://localhost:7000
• You’ll get access to:
  • Instance counts for all classes
  • Heap histograms (memory usage by class)
  • OQL (Object Query Language) to search for specific objects

Tool 2: VisualVM (intuitive GUI) #

VisualVM is a more user-friendly GUI tool included with most JDKs:

• Launch VisualVM from your JDK’s bin folder (e.g., $JAVA_HOME/bin/jvisualvm)
• Click File > Load and select your local-heapdump.hprof file
• Once loaded, explore key tabs:
  • Overview: See total heap size, GC activity, and basic app info
  • Classes: Sort classes by instance count or memory usage to find bloat
  • Threads: Check for stuck or blocked threads that might be causing issues
  • Sampler: Do live memory sampling to identify memory hogs

Tool 3: Eclipse Memory Analyzer (MAT) (best for leak detection) #

MAT is a powerful tool designed specifically for finding memory leaks and analyzing large dumps:

• Install MAT (it’s free and cross-platform)
• Open MAT, then import your heap dump file
• It will automatically generate a Leak Suspects Report—this is your first stop, as it highlights potential memory leaks with detailed reference chains
• Dig deeper with:
  • Histogram: Filter and sort classes by memory usage
  • Dominator Tree: See which objects are holding the most memory and what’s referencing them
  • OQL Editor: Write custom queries to hunt down specific objects or patterns

• Always make sure your local machine has enough RAM to handle large heap dumps—analyzing a 10GB dump might require 8GB+ of allocated memory for the tool.
• If your Pod is running in a restricted environment (e.g., no shell access), you can configure your Java app to generate a heap dump on OOM (Out Of Memory) by adding JVM flags like -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof when starting the app.

内容的提问来源于stack exchange，提问作者Amrith Raj Herle