2011-09-02 14 views
12
ejemplo

Por, este es un seguimiento de pila de un servidor Tomcat:¿Qué significa "bloqueado" en un seguimiento de la pila de Java?

"RMI TCP Accept-0" daemon prio=10 tid=0x091a5800 nid=0x8f1 runnable [0x8b305000] 
    java.lang.Thread.State: RUNNABLE 
    at java.net.PlainSocketImpl.socketAccept(Native Method) 
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) 
    - locked <0x911d3c30> (a java.net.SocksSocketImpl) 
    at java.net.ServerSocket.implAccept(ServerSocket.java:462) 
    at java.net.ServerSocket.accept(ServerSocket.java:430) 
    at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:34) 
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369) 
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341) 
    at java.lang.Thread.run(Thread.java:662) 

Mi conjetura es que "bloqueado" significa que la CPU está esperando en una especie de bloqueo. Sin embargo, si ese es el caso, ¿por qué el estado del hilo aparece como RUNNABLE en lugar de BLOQUEADO?

Gracias.

Respuesta

17

Significa que este subproceso (RMI TCP Accept-0) tiene la propiedad del objeto con el código hash 0x911d3c30, en este caso un java.net.SocksSocketImpl. Si bien este hilo posee el bloqueo, no hay otro hilo que pueda tenerlo, lo que impide que ingresen esta parte del código (a menudo una función). Vea aquí para más información:

http://download.oracle.com/javase/tutorial/essential/concurrency/newlocks.html

Además, es RUNNABLE, ya que todavía está en marcha ... Si se observa que el locked no está en la cima de la pila, sino más bien en su interior, lo que significa que mantiene el bloqueo y continúa ejecutándose. El próximo hilo que vendrá por esta sección de código sería bloqueado por ese bloqueo.

EDIT Porque es demasiado incómodo para encajar en un comentario ... Si ves ESTO, estás viendo un hilo que está bloqueado. Nota Se dice waiting to lock

"http-80-exec-113": 

at com.airs.utilities.server.Entity.serializeZip64(Entity.java:6314) 
- waiting to lock <0x00007fbefe44d5c8> (a java.lang.String) 
at com.airs.utilities.server.Entity.serializeZip64(Entity.java:6300) 
+0

Gracias. Entonces esto no significa que el hilo esté inactivo o dormido, que es lo que había supuesto. Veo muchos hilos como este en mi servidor Tomcat. ¿Es eso una condición normal? –

+0

@Frank LaRosa: Absolutamente. En cualquier momento dado, tenemos de 10 a 100 subprocesos en ese estado en nuestros servidores. El objetivo de este hilo es esperar hasta que otro servidor lo pida pidiendo información, y como normalmente usted quiere tener la capacidad de procesar más de una solicitud a la vez (búsquedas de texto completo, por ejemplo), tendrá múltiples conectores disponibles. –

+0

Pero esos hilos no están girando en un bucle usando ciclos de CPU mientras esperan una conexión, ¿verdad? Suponiendo que no lo son, ¿qué está causando que no lo hagan? Normalmente, cuando creo un hilo de trabajo, pasa la mayor parte del tiempo en estado de ESPERA, hasta que otro hilo lo notifique. En este caso, todos los hilos están listados como RUNNABLE. –

-1

De java 6 documentation:

Un monitor objeto está bloqueado al entrar en un bloque de sincronización o el método de ese objeto.

+2

Si bien es cierto, no es exactamente muy útil o descriptivo. –

+0

¿Desde cuándo se supone que la documentación es útil y descriptiva? ;) –

Cuestiones relacionadas