8

I like to generate a thread dump programmatically. I've learned that there a basically two ways to do it:

  1. Use the "Java Virtual Machine Tool Interface" JVM-TI
  2. Use the higher abstracted "Java Debugger Interface" JDI

For the JVM-TI I was able to find some useful information, but I would have to write a JNI-DLL which, at least for the moment, I would like to avoid. With the JDI I can use Java and it seems I'm able to use it from within the application. But I wasn't able to find some kind of tutorial or HOWTO for it. The only documentation I could find, were the Java-Docs http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/ which isn't very helpful, because it doesn't show me how to use this classes.

So, does anybody know of a good tutorial/book I could read?

Thx for any help!

4 Answers 4

21

There is a third way: Thread.getAllStackTraces()

http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#getAllStackTraces()

This is much easier than the debugger interface...

Sign up to request clarification or add additional context in comments.

Comments

8

You can get just about all the Thread info you need including deadlocks from http://java.sun.com/javase/6/docs/api/java/lang/management/ThreadMXBean.html

Comments

3

Thread.getAllStackTraces() dumps only the execution trace of all the threads, but doesn't give the information of object locks that have been obtained by a particular thread or the lock on which a particular thread has been waiting. Basically, we'll not be able to nail down deadlocks with this.

Comments

1

Did you consider the remote alternative ? I.e. VisualVM

thead dump with visualVM

jps and jstack are also useful tools included in JDK 5, providing a quick command line method for obtaining stack traces of all current threads.

This article suggest JDI is also used as a remote tool.

So I am not sure you can triggers a thread dump within your own program, instead you find a way to send to yourself a SIGQUIT signal (kill -3) on Unix platforms, or press the Ctrl-\ key on Unix or Ctrl-Break on Windows platforms.

Plus, JDI wasn't intended to be used to debug the same process in which the JDI client is running. Still this thread I just linked to is the closest I have found to actually use JDI within the same program.

5 Comments

Thanks, now at least I have a specific forum where I can ask!
You're welcome. If this is the most helpful approach, do not forget to accept this answer ;)
Note that the jvisualvm connection approach only works for "your own" JVM's and not others. This includes when running as a windows service.
@Thorbjørn: so you must be the owner of the JVM process, then?
to my understanding the user you are logged in as must be the same as the one the process is running under.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.