Search code examples
javaruntime.execthread-dump

Taking thread dumps in production

I am analyzing the differences between approaches for taking thread dumps. Below are the couple of them I am researching on

  1. Defining a jmx bean which triggers jstack through Runtime.exec() on clicking a declared bean operation.

  2. Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.

Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2

  1. Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA
  2. The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)
  3. Any more?

I would appreciate to get suggestions/inputs on

  1. Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?

  2. Any other approach to take thread dumps?

Thank you.

Edit -

A combined approach of 1 and 2 seems to be the way to go. We can have a dedicated thread running in background and printing the thread dumps in the log file in a format understood by the thread dump analyzers. If any extra information is need (like say probably the native thread id) which is logged only by the jstack output, we do it manually as required.

Solution

  • You can use 

    jstack {pid} > stack-trace.log

    running as the user on the box where the process is running.

    If you run this multiple times you can use a diff to see which threads are active more easily.

    For analysing the stack traces I use the following sampled periodically in a dedicated thread.

     Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();

    Using this information you can obtain the thread's id, run state and compare the stack traces.