Detectar threads deadlocks con jstack

Se llegan a tener "threads deadlocks" que impactan en performance a la aplicación (si nos va bien) o pueden consumir toda la memoria y hasta tirar la JVM.

Para localizar estas situaciones, primero se tiene que identificar el PID de la JVM:

 

Adjuntar jstack al id del proceso identificado anteriormente:

 

Si se encuentran deadlocks:

 
El thread dump que hacemos con jstack es de extrema ayuda, debido a que nos facilita:

  • Cuántos deadlocks existen en el proceso JVM
  • Cuáles son los dos threads esperando para cada deadlock.
  • Qué está haciendo cada thread (si es necesario)

Existen herramientas de análisis de thread dumps gráficos como TDA que la interfaz es muy amistosa e intuitiva en su uso. Si llegaran a tener problemas más serios(threads de pools de conns a dbs bloqueados) les sugiero utilizarlo, pues agrupa threads actuando de la misma manera, direcciones de memoria, números de threads, ect.

Espero les sirva y a seguir aportando.

Saludos,
jm

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

jstack

A mi parecer, jstack es una de las herramientas más útiles que incluyó Java 6 (o creo que venía desde la 5). Más que jconsole.

Imagen de jali

Desconocia Jstack

Que buena herramienta! desconocia su existencia. Gracias por el aporte!

Hacía mucha falta algo como

Hacía mucha falta algo como jstack

En UNIX con kill -3 salia el thread dump, pero en Windows no había forma. Cuando los servidores NT se volvieron más confiables y más clientes requerían tener instalaciones ahí se había un relajo ( si se queda la consola abierta se puede ejecutar Ctrl-Break o Ctrl-Pause para generar el stacktrace, pero una consola abierta es muy peligrosa - no tanto por la seguridad, sino por que en cualquier momento aguién le puede dar click al tachecito y se cierra todo - )

En Windows, un producto que ayuda(ba) a sacar este stacktrace era: Stack Trace ( vaya nombre ) y que era un proyecto independiente y luego fue comprado por esta empresa "adapj" .

Luego con ayuda de un script de Ruby generábamos una gráfica donde se veian los nodos y salia cual era el thread que estaba causando el deadlock ( creo que hasta lo ponía en rojito y con una flecha diciendo "Fue él!!" )

Por mucho tiempo me lamenté de no haber hecho una copia de ese script y de ese programa, pero ahora con jstack + tda, me parece que se puede conseguir los mismo resultados ( aunque sinceramente, espero jamás tener que usarlo, es horrible hacerle cirugía a corazón abierto a un servidor de producción :-S )

Imagen de ezamudio

RTFS

Claro que toda la info de jstack es inútil si no estás dispuesto a leer el maldito stack trace!

jajaj Quizá la excepción

jajaj Quizá la excepción se materializa, sale de la computadora y teclea  

Lo único que hay que tener en cuenta, es que con el thread dump los threads aún siguen vivos y con el stracktrace lo que se ve es un cadáver, sacándole unas fotos a intervalos suficientes se ve claramente quién es el que se está atragantando para irle a aplicar la maniobra heimlich.

Imagen de ezamudio

Así es

el stack trace de una excepción no siempre equivale a una autopsia; si cachaste la excepción, la manejaste y la imprimiste a un log, sirve para corregir problemas o detectar ciertas condiciones que hay que reportar (y posiblemente enviar una alarma), pero la app sigue viva...