Java problema de bloqueo: hilos de bloques ¿por qué habría de JVM en muchas diferentes clases / métodos?

Question

Actualización: Esto parece un problema de memoria. Un archivo de 3,8 Gb hprof indicó que la JVM se dumping a su heap cuando este "bloqueo" se produjo. Nuestro equipo de operaciones de sierra que el sitio no estaba respondiendo, se llevó un seguimiento de pila, a continuación, cerrar la instancia. Creo que cierran el sitio antes de finalizada la descarga del montón. El registro tenía no errores / excepciones / evidencia de problemas -. Probablemente porque la JVM murió antes de que pudiera generar un mensaje de error

Pregunta original Tuvimos una situación reciente en que la aplicación apareció --a el usuario final - para colgar. Tenemos un seguimiento de la pila antes de reiniciar la aplicación y yo encontramos algunos resultados sorprendentes: de 527 hilos, 463 habían bloqueado Estado hilo.

En el pasado En el pasado de rosca bloqueado por lo general tenían este problema: 1) algunos cuello de botella evidentes: por ejemplo, algunos bloqueo de registro de base de datos o un problema de bloqueo del sistema de archivos que causó otros hilos que esperar. 2) Todos bloqueado hilos bloquearían en la misma clase / método (por ejemplo, los JDBC o del sistema de archivos clases)

Unusual datos En este caso, veo todo tipo de clases / métodos bloqueados, incluyendo clases de JVM internos, clases, JBoss log4j, etc, además de clases de la aplicación (incluyendo las llamadas JDBC y Lucene)

La pregunta  lo que causaría una JVM para bloquear log4j.Hierarchy.getLogger, java.lang.reflect.Constructor.newInstance? Obviamente, algunos de los recursos "es escasa", pero que los recursos?

gracias

se

Seguimiento de la pila Extractos

http-0.0.0.0-80-417" daemon prio=6 tid=0x000000000f6f1800 nid=0x1a00 waiting for monitor entry [0x000000002dd5d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at sun.reflect.GeneratedConstructorAccessor68.newInstance(Unknown Source)
                at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
                at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
                at java.lang.Class.newInstance0(Class.java:355)
                at java.lang.Class.newInstance(Class.java:308)
                at org.jboss.ejb.Container.createBeanClassInstance(Container.java:630)

http-0.0.0.0-80-451" daemon prio=6 tid=0x000000000f184800 nid=0x14d4 waiting for monitor entry [0x000000003843d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at java.lang.Class.getDeclaredMethods0(Native Method)
                at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
                at java.lang.Class.getMethod0(Class.java:2670)

"http-0.0.0.0-80-449" daemon prio=6 tid=0x000000000f17d000 nid=0x2240 waiting for monitor entry [0x000000002fa5f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.register(Http11Protocol.java:638)
                - waiting to lock <0x00000007067515e8> (a org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.createProcessor(Http11Protocol.java:630)


"http-0.0.0.0-80-439" daemon prio=6 tid=0x000000000f701800 nid=0x1ed8 waiting for monitor entry [0x000000002f35b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:261)
                at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:242)
                at org.apache.log4j.LogManager.getLogger(LogManager.java:198)

Answer 1

Estos se enumeran más o menos en el orden me gustaría probar ellos, dependiendo de la evidencia recogida:

• ¿Has mirado en GC comportamiento ? ¿Estás bajo presión de memoria? Esto podría resultar en newInstance() y algunos otros por encima de ser bloqueado. Funcionar su máquina virtual con -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc y registrar la salida. ¿Usted está viendo los tiempos excesivos GC cerca del momento del fallo / bloqueo?
  • ¿Es la condición repetible ? Si es así, tratar con diferentes tamaños de almacenamiento dinámico de la JVM (-Xmx) y ver si el comportamiento cambia sustancialmente. Si es así, ver si hay fugas de memoria o el tamaño del montón para su aplicación correctamente.
  • Si el anterior es difícil, y no está recibiendo un OutOfMemoryError cuando debería, puede sintonizar las sintonizables GC ... ver opciones JDK6.0 XX , o JDK6.0 GC sintonización Whitepaper . Analizar específicamente -XX:+UseGCOverheadLimit y -XX:+GCTimeLimit y opciones relacionadas. (Tenga en cuenta estos no están bien documentados, pero puede ser útil ...)
• ¿Podría haber una estancamiento ? Con sólo extractos de rastreo de pila, no se puede determinar aquí. Busque ciclos entre los estados del monitor que los hilos se bloquean en (frente a lo que tienen). Creo jconsole puede hacer esto para usted ... ( sí, debajo de los hilos pestaña, "detectar los puntos muertos" )
• Intente hacer varias stacktraces repetidas y el aspecto de qué cambios frente a lo que sigue siendo el mismo ...
• ¿Las forense ... para cada entrada de la pila que dice "bloqueada", ir a buscar hasta la línea de código específica y averiguar si hay un monitor de allí o no. Si hay una adquisición de monitorización, que debe ser bastante fácil de identificar el recurso limitante. Sin embargo, algunos de los hilos pueden mostrar bloqueado sin un monitor de forma transparente disponible, estos serán más complicado ...