2012-07-05 15 views
9

Tengo una aplicación basada en Java EE que se ejecuta en tomcat y veo que, de repente, la aplicación se cuelga después de ejecutarse durante un par de horas.Analizando el volcado de subprocesos de un proceso de Java

I recogió el volcado de hilo de la aplicación justo antes de que cuelga y la puso en TDA para el análisis:

enter image description here

TDA (Thread Dump Analyzer) da el siguiente mensaje para el monitor de arriba:

A lot of threads are waiting for this monitor to become available again. 
This might indicate a congestion. You also should analyze other locks 
blocked by threads waiting for this monitor as there might be much more 
threads waiting for it. 

Y aquí es el StackTrace de la rosca destacó anteriormente:

"MY_THREAD" prio=10 tid=0x00007f97f1918800 nid=0x776a 
      waiting for monitor entry [0x00007f9819560000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.util.Hashtable.get(Hashtable.java:356) 
    - locked <0x0000000680038b68> (a java.util.Properties) 
    at java.util.Properties.getProperty(Properties.java:951) 
    at java.lang.System.getProperty(System.java:709) 
    at com.MyClass.myMethod(MyClass.java:344) 

Quiero saber qué significa el estado "waiting for monitor entry"? Y también agradecería cualquier sugerencia para ayudarme a depurar este problema.

+4

I guardaría en caché las búsquedas de las propiedades del sistema en lugar de llamarlas de este modo repetidas veces. No debería necesitar llamar a System.getProperty() más de una docena de veces durante la vida de la aplicación. es decir, debe codificarlo para que no sea un cuello de botella. –

+0

hmm ... ¡buen punto Peter! – peakit

Respuesta

1

Monitor = sincronizado. Tienes muchos hilos que intentan bloquear el mismo objeto.

Tal vez debería cambiar de usar una tabla hash y utilizar un HashMap

+0

Si ve que no estoy usando 'Hashtable' directamente. Viene de mi llamada a 'System.getProperty()'. ¿Hay una versión no bloqueante de 'System.getProperty()'? ¡Gracias! – peakit

1

Esto significa que el hilo está tratando de establecer un bloqueo (en la tabla hash), sino algún otro hilo ya tiene acceso a él y ha establecido un bloqueo . Así que está esperando a que se abra la cerradura. Comprueba qué están haciendo tus otros hilos. Especialmente hilo con tid = "0x00007f9819560000"

+0

Curiosamente, NO veo ningún hilo con 'tid = 0x00007f9819560000' en el archivo de volcado de hilo. ¿Alguna idea? – peakit

+0

Mmmmh, probablemente sea el bloqueo de la mesa del monitor VM entonces. Si no se ve el código, va a ser difícil. Esencialmente, el Hashtable se está compitiendo por dos hilos. Una opción podría ser reemplazar Hashtable con HashMap (porque HashMap no es seguro para subprocesos). Sé que estás usando Propiedad pero solo copias en un mapa y luego utilizas el mapa. Entonces verá que explota en la contención (ConcurrentModificationException probablemente), o comienza a funcionar porque el bloqueo ni siquiera era necesario. – mprivat

5

Uno de sus subprocesos adquirió un objeto de monitor (un bloqueo exclusivo en un objeto). Eso significa que el hilo está ejecutando código sincronizado y por la razón que sea, está atrapado allí, posiblemente esperando otros hilos. Pero los otros subprocesos no pueden continuar su ejecución porque encontraron un bloque sincronizado y pidieron un bloqueo (objeto de monitor), sin embargo, no pueden obtenerlo hasta que otro subproceso lo libere. Entonces ... probablemente un punto muerto.

2

Por favor, busque esta cadena de todo el hilo volcar

- encerrados < 0x00007f9819560000>

Si lo encuentra, el hilo es punto muerto con hilo "tid = 0x00007f97f1918800"

+0

sí bobon, busqué en todo el volcado de subprocesos de esta cadena y no pude encontrar ninguna otra referencia para esta identificación, aparte del subproceso resaltado en la pregunta. – peakit

Cuestiones relacionadas