new - thread java 8

Transición de estado de subproceso de Java, WAITING to BLOCKED o RUNNABLE

Question

Parece haber una discrepancia entre el consenso de SO y casi todos los diagramas de estado de subprocesos de Java en Internet; específicamente, con respecto a la transición del estado del subproceso de WAITING después de que se invoque notify() o notifyAll() ...

• ESPERA never va directamente a RUNNABLE
• El subproceso está EN ESPERA hasta que se le notifique ... Luego se becomes BLOQUEADO ...
• Una vez que se notifique este hilo, no se podrá ejecutar ... Esto es ... Estado bloqueado.

Por lo tanto, el consenso sobre SO es: una hebra pasa de WAITING a BLOCKED después de invocar a notify() o notify() notifyAll() ; El siguiente diagrama ilustra esta transición en verde.

Pregunta

¿Por qué la mayoría de los diagramas de estado en la web ilustran la transición de WAITING a RUNNABLE , NO BLOCKED ? Representación en rojo muestra la transición incorrecta; ¿Me estoy perdiendo de algo?

Answer 1

Cualquier diagrama que muestre una invocación de notify traiga un subproceso de WAITING a RUNNABLE es incorrecto (o está utilizando un método abreviado sin aclarar). Una vez que un hilo se despierta de una notify (o incluso de una activación falsa), debe volver a bloquear el monitor del objeto en el que estaba esperando. Este es el estado BLOCKED .

Estado del hilo para un hilo bloqueado esperando un bloqueo del monitor. Un subproceso en el estado bloqueado está esperando que un bloqueo de monitor ingrese en un bloque / método sincronizado o que vuelva a ingresar en un bloque / método sincronizado después de llamar a Object.wait .

Esto se explica en el javadoc de Object#notify() :

El hilo despertado no podrá continuar hasta que el hilo actual abandone el bloqueo de este objeto.

y el Object#wait()

El hilo luego espera hasta que pueda volver a obtener la propiedad del monitor y reanudar la ejecución.

Answer 2

Me estoy enfocando en el problema recientemente.

como el documento de Oracle Thread.State dice que podemos usar LockSupport.park () para poner el subproceso actual en el estado ''WAITING'' o ''TIMED_WAITING''.

así que cuando pruebes LockSupport.unpark() , el hilo especificado volverá a ''RUNNABLE'' desde ''WAITING'' / ''TIMED_WAITING''. (No estoy seguro de si pasará por el estado ''BLOQUEADO'')

Answer 3

Un subproceso está en estado WAITING entra en estado BLOCK , hasta que adquiere el monitor por notificación y se pone en funcionamiento .

Lo mismo se aplica a TIMEDWAITING , entra en estado BLOQUEO , si el monitor se mantiene en algún otro hilo, incluso aunque haya pasado el tiempo especificado. (tu diagrama necesita ser corregido)