Generating Java Full Thread Dump


Performance and scalability: Generating Java Full Thread Dump

  1. Generating Java Full Thread Dump (7 messages)

    Hi All, I want to generate full thread dump output(like kill -3) inside JVM. First of all , is it possible (in 1.5 or older)? Is there any code example? How JVM generate this output, when kill -3 is triggered? It uses jni? How can use it in a java class? I can generate partial of this output like using for deadlock, ThreadMXBean mbean = ManagementFactory.getThreadMXBean(); long[] ids = mbean.findMonitorDeadlockedThreads(); and for stacetrace, Map thrdMap = Thread.getAllStackTraces(); But output is not same.I want to use output to see in thread dump analyzers(it must be well-defined format). Thread.getAllStackTraces()doesnt contain - waiting to lock (a java.lang.Object). Thanks, Serdar

    Threaded Messages (7)

  2. You can call Thread.dumpStack().This will give you the stack trace for the current thread.And please avoid duplicating you posting, we anyway look at all the categories. cheers,
  3. Re: Generating Java Full Thread Dump[ Go to top ]

    You can use jstack to take a dump.
  4. Re: Generating Java Full Thread Dump[ Go to top ]

    You would think there would be an easy way to do this.... The one method that works with all Sun VMs (so far) is to write a little JNI lib so that you can get the process ID of your VM (e.g on linux, call getpid()). Then just run kill -3 , or on windows use SendSignal.exe (google for that executable). Unfortunately the thread dump is going to be on stderr, so you had better know where that stream is going (hopefully not /dev/null) With 1.5, a combination of the jps and jstack commands can help you to accomplish the same thing. note: jstack isn't in the windows JDK until 1.6 for some reason. Jrockit might have some special magic for doing thread dumps, I don't know much about it. They might also be some solaris specific things to let you look at thread states. If you're running within Weblogic, I think they include a class for doing exactly this too, although you won't find it adverised as a public feature afaik. Anyway, for the number of platforms and VM versions I have to deal with, the first approach (JNI for process ID plus an OS specific signal program seems) to work best.
  5. In 1.6 thread dump goes to stdout[ Go to top ]

    At least in 1.6 the thread dump generated by Ctrl+Break in Windows goes to stdout.

  6. What are you trying to do ? Depending upon the overhead you are willing to incur, you can enable JVMPI/JVMDI (with pre-1.5) or JVMTI(with 1.5) to get more access to some of the stack trace functions. Another option (if you don't want the overhead) is to use Auptyma's Java Application Monitor. It is an asynchronous thread stack sampler for finding Java performance issues. It will provide you stack (and contended object) information. Regards, Virag
  7. And for when you don't have ssh access to your server, there's only one solution: MessAdmin As a bonus, you will also get plenty of technical information on you server! :-)

  8. We do this[ Go to top ]

    ProcessBuilder processBuilder = new ProcessBuilder("/bin/sh", "-c", "kill -3 $PPID");  


    Process process = processBuilder.start();       

    InputStream inputStream = process.getInputStream();       

    IOUtils.copy(inputStream, System.out);