How to Get a Thread and Heap Dump of a Java Process on Windows That's Not Running in a Console

How can a get a JVM heap dump from Java 5 on Windows without a JDK installed and the process running as a service

AFAIK You can't trigger a heap dump with Java 5.0 even if you has complete access to the machine. (Admittedly I haven't used Java 5.0 for more than five years) With Java 6 you need JMX or trigger a heap dump on an out of memory error.

Some memory profilers may allow you to do a heap dump (of their own format) if you can find one which supports Java 5.0 but you would have to enable profiling from the start and that tended to be relatively slow on Java 5.0 from memory.

how to take thread dump of java application on a distroless container running on kubernetes?

Are you using Spring Boot to build those microservices? If yes, then by using Spring Boot Admin you can get thread dumps, heap dumps and monitor your services from a single window.

Please check here to get more details about it.

Extracting JVM stack trace from a heap dump (hprof) with a command line tool

MAT project comes with a script ParseHeapDump.sh (*.bat on Windows), if you just run it on a heap dump like this: /path/to/MAT/ParseHeapDump.sh <HEAPDUMP_NAME>.hprof, you get a set of files, one of them being a text file <HEAPDUMP_NAME>.threads containing stack traces, e.g.:

Thread 0x715883630

  locals:

Thread 0x71577b418
  at java.lang.Object.wait(J)V (Native Method)
  at java.lang.ref.ReferenceQueue.remove(J)Ljava/lang/ref/Reference; (ReferenceQueue.java:155)
  at jdk.internal.ref.CleanerImpl.run()V (CleanerImpl.java:148)
  at java.lang.Thread.run()V (Thread.java:834)
  at jdk.internal.misc.InnocuousThread.run()V (InnocuousThread.java:134)

  locals:
    objectId=0x715833c30, line=1
    objectId=0x716df1990, line=1
    objectId=0x715832230, line=2
    objectId=0x71577b418, line=2
    objectId=0x71577b418, line=2
    objectId=0x71577b418, line=3
    objectId=0x71577b418, line=4

Thread 0x715883050
  at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
  at java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V (LockSupport.java:234)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(J)J (AbstractQueuedSynchronizer.java:2123)
  at java.util.concurrent.DelayQueue.take()Ljava/util/concurrent/Delayed; (DelayQueue.java:229)
  at com.intellij.util.concurrency.AppDelayQueue.lambda$new$0()V (AppDelayQueue.java:26)
  at com.intellij.util.concurrency.AppDelayQueue$$Lambda$16.run()V (Unknown Source)
  at java.lang.Thread.run()V (Thread.java:834)

  locals:
    objectId=0x715883050, line=1
    objectId=0x715cd8a90, line=2
    objectId=0x7291c6618, line=2
    objectId=0x715f73520, line=3
    objectId=0x715cd8aa8, line=3
    objectId=0x715883050, line=3
    objectId=0x715f73520, line=4
    objectId=0x715cd8ac0, line=5
    objectId=0x715883050, line=6
...

You are only interested in lines starting with Thread 0x... and at ... here.

Notes:

1. The script does a lot more work than would be necessary to only extract a thread dump (it parses the heap as well which is 99.99...% of work); and it generates many files that you do not need (all prefixed <HEAPDUMP_NAME>).
2. Thread names are lost, and thread ids seem to not correspond to anything OS-specific (e.g. native thread id); in other words, you cannot find Thread 0x715883050 in the ps or top/htop output — at least I do not know a way.

---

Related Topics