Shichibukai: Leer un javadump desde el notepad

2013-03-19T18:25:22Z

Leer un javadump desde el notepad

Página nueva

'''Javadump''' es la información estructurada de la jvm en un instante determinado, en la cual registra el vuelco de memoria, los thread de la JVM y el estado de cada thread.
Esta información es la que utilizaremos cuando queremos analizar algún problema de perfomance, pergem o simplemente ver como se comporta nuestra aplicación en la JVM.
Existen varias herramientas para leer el javadump que varía según el entorno en la que se genera el javadump (Windows, AIX, etc), en este post vamos a analizar el javadump desde el notepad.

==Información del thread==
Dentro del javadump, tenemos una sección (thread Details/All Thread Details) en donde se detalla cada thread que se encuentra corriendo dentro de la JVM.
<code>
"Java2D Disposer" J9VMthread:0x00000001193E8A00, j9thread_t:0x00000001179DD300, java/lang/thread:0x0700000003B84360,
state:CW, prio=10
(native thread ID:0x904F3, native priority:0xA, native policy:UNKNOWN)
Java callstack:
at java/lang/Object.wait(Native Method)
at java/lang/Object.wait(Object.java:196(Compiled Code))
at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:102(Compiled Code))
at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:79(Compiled Code))
</code>

Por cada thread tenemos la siguiente información:
*'''Nombre:''' En caso de estar en un servidor de aplicaciones, es el identificador que asigna el servidor de aplicaciones al thread. Ej.:Java2D Disposer
*'''Estado:''' estado actual del thread. Ej.: CW. Los estados pueden ser:
**R - Runnable - El thread puede tiene todos los recursos para ejecutarse.
**CW - Condition Wait - El thread se encuentra en espera de algún evento, ej:
***Esperando por una operación E/S.
***El thread ejecuta el metodo wait() de un monitor y espera el evento notify().
***El thread espera para sincronizarse con otro hilo, invocando al metodo join()
***El thread espera por ejecutar el metodo sleep()
**S – Suspended – el thread fue suspendido por otro thread.
**Z – Zombie – el thread fue eliminado.
**P – Parked – el thread fue puesto en ese estado por la nueva api de concurrencia (java.util.concurrent).
**B – Blocked – el thread esta esperando para obtener acceso a la región critica (luego de pasar por el wait()) que posee otro hilo.
*'''Prioridad:''' prioridad del thread (mientra más alto más prioritario), cada prioridad de Java es mapeado a la prioridad del Sistema Operativo. Ej.: prio=10
*'''Stacktrace:''' El stack trace de la invocación realizada por el thread. Ej.:
<code>
Java callstack:
at java/lang/Object.wait(Native Method)
at java/lang/Object.wait(Object.java:196(Compiled Code))
at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:102(Compiled Code))
at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:79(Compiled Code))
</code>

==Monitores/Locks==
Los monitores es el mecanismo que utiliza Java para sincronizar los thread cuando quieren acceder a un recurso compartido. Para entender mejor como funciona el mecanismo de sincronización podemos leer el [http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html tutorial de java sobre los monitores].
Dentro del javadump, tenemos la información de los thread que estan a la espera de un monitor (lock), esta información nos puede ser útil para detectar deadlock o mucho thread compitiendo por el mismo recuros.
Ej.:
<code>
NULL ------------------------------------------------------------------------
0SECTION LOCKS subcomponent dump routine
NULL ===============================
NULL
1LKPOOLINFO Monitor pool info:
2LKPOOLTOTAL Current total number of monitors: 1358
NULL
1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors):
2LKMONINUSE sys_mon_t:0x000000011D560258 infl_mon_t: 0x000000011D560298:
3LKMONOBJECT weblogic/utils/classloaders/ChangeAwareClassLoader@0x0700000001858578/0x0700000001858590:
owner "[ACTIVE] ExecuteThread: '348' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x0000000140298F00),
entry count 2
3LKWAITERQ Waiting to enter:
3LKWAITER "[ACTIVE] ExecuteThread: '9' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011E5DED00)
3LKWAITER "[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000011E942B00)
3LKWAITER "[ACTIVE] ExecuteThread: '17' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x00000001213EE700)
3LKWAITER "[ACTIVE] ExecuteThread: '41' for queue: 'weblogic.kernel.Default (self-tuning)'" (0x000000012175A400)
</code>

En el ejemplo vemos que los threads se encuentran esperando que se libere la instancia '''weblogic/utils/classloaders/ChangeAwareClassLoader@0x0700000001858578/0x0700000001858590''' cuyo dueño es '''[ACTIVE] ExecuteThread: '348' '''

==Ver también==
* [http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html Tutorial Java sobre concurrencia]
* [http://javaeesupportpatterns.blogspot.com.ar/2011/11/how-to-analyze-thread-dump-part-1.html Como analizar el "thread dump"]
* [http://publib.boulder.ibm.com/infocenter/realtime/v1r0/index.jsp?topic=%2Fcom.ibm.rt.doc.10%2Fdiag%2Ftools%2Fjavadump_tags_threads.html Interpretando el javadump en el IBM WebSphere]

[[Category:Java]]

Javadump - Historial de revisiones

Shichibukai: Leer un javadump desde el notepad