It is possible to let the Java virtual machine dump a stack trace of all available threads together with the call backtrace of each thread. On Unix, the usual way to do this is to send the QUIT signal to the process:
$ kill -QUIT pidOfJavaProcess
This lets the jvm dump the stack trace to the console it has been started from (or into a file in case stderr/stdout have been redirected when launching the JVM).
The drawback is that you need to copy&paste the stack trace from the console window into a text file yourself, in case you want to persist and further analyze it. Also, for background processes, there is sometimes no console attached anymore, so the stack trace goes to /dev/null. During my investigation how to get the stack trace in these cases anyway, I verified whether it is possible to redirect the stdout/stderr output of a running background process. Interestingly this is not very easy, since it means to modify the file descriptor table of the particular process during runtime. Anyway, it is still possible by attaching a debugger like gdb to the process and modifying the running process with some debugger commands – the approach is described at https://stackoverflow.com/questions/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-lin. I have not pursued this further (and I have also not tried it out), since there are easier solutions available.
Starting with Java 5, the JDK includes the jstack command line tool. Getting a stack trace from any java process and writing it into a file is as simple as
$ $JAVA_HOME/bin/jstack pidOfJavaProcess > stack.txt
For the jrockit virtual machine, there exists a similar command, the jrcmd command line tool:
$ $JROCKET_HOME/bin/jrcmd pidOfJavaProcess print_threads > stack.txt
For more information, see also