Ciclo de vida de subprocesos y estados de subprocesos

"¡Hola, amigo!"

"Vamos a comenzar un nuevo tema: hilos".

"Empecemos. Hoy examinaremos los estados por los que pasa (o podría pasar) un objeto Thread cuando se está ejecutando un hilo".

"¿Cuántos estados puedes nombrar en este momento, amigo?"

"Dos. El primero es un subproceso antes de que se llame al método start(): el objeto existe, pero el subproceso aún no está activo. Y el segundo es después de que se haya llamado al método start(): cuando el subproceso está haciendo algo importante."

"Tienes razón, existe tal distinción. Estos estados se denominan nuevos y en ejecución , pero eso es solo el comienzo".

"Primero, en algún momento el subproceso terminará de ejecutarse, lo que significa que puede haber una situación en la que exista el objeto Subproceso, pero el subproceso no se encuentre en el estado nuevo o en ejecución. "Este estado, en el que el subproceso ha terminado de ejecutarse, se denomina rescindido ".

"Pero hay más. No olvide que en un momento dado solo se está ejecutando un subproceso. Lo que parece ser un trabajo simultáneo es en realidad el procesador saltando constantemente de un subproceso a otro. Hay un estado separado para cuando el subproceso parece estar funcionando". en ejecución, pero en realidad está esperando su turno: se llama listo para ejecutar . A medida que un subproceso funciona, cambia constantemente de ejecutar a listo , y luego vuelve a ejecutarse cuando vuelve a estar activo".

"Inmediatamente después de llamar al método start (), se asigna al subproceso el estado listo para ejecutarse y se coloca en una lista compartida de subprocesos entre los que cambia la JVM".

"Eso no es demasiado difícil. Antes de que comience a ejecutarse, tiene el nuevo estado. Una vez que finaliza, se finaliza . Cuando se ejecuta, el subproceso está en el estado de ejecución ; luego, cuando está esperando, está en el estado listo ."

"Tu brevedad es increíble, pero tienes razón".

"Pero hay más. El subproceso se puede bloquear. Por ejemplo, cuando ingresa a un bloque sincronizado . Si un subproceso llega a un bloque de código marcado como sincronizado y otro subproceso lo está utilizando, entonces nuestro subproceso entrará en estado bloqueado y esperará. para que se libere el mutex (bloqueo) del objeto".

"Así es como se ve esta situación con los estados:"

"Pero hay más. También hay un estado separado llamado espera . Esto es cuando un subproceso no está bloqueado , pero tampoco está listo . Por ejemplo, cuando llama al método join () en otro subproceso".

Cuando llamamos a join() en otro objeto Thread, es como si nuestro hilo «se uniera», pero en realidad solo espera a que el otro hilo termine.

"Además, también existe el método wait () (del trío de métodos wait/notify/notifyAll), que cambia un subproceso al estado de espera cuando se llama".

"Guau".

"¡Espera un minuto! Todavía hay más. Un subproceso puede dormir llamando al método de suspensión, por ejemplo. También hay un estado separado para esto. Se llama "espera cronometrada". "Espera cronometrada" significa que el hilo está esperando algo para un tiempo limitado. Si llama a un método de espera con un parámetro, como esperar (tiempo de espera) o unir (tiempo de espera), entonces el hilo entrará en el estado de espera cronometrada".

"Aquí está el diagrama completo:"

"Hmm. ¿Eso es todo? ¿O hay 10 estados más interesantes?"

"Por ahora, eso es todo".

"En la práctica, puedes recordar el primer diagrama. Es más simple. Pero el segundo es más preciso".

"Curiosamente, hay muchos diagramas de estado de subprocesos en Internet, y todos son diferentes".

"Por eso te di este diagrama, es el más completo y correcto".

"En este diagrama, los estados listo y en ejecución se combinan en un solo bloque llamado ejecutable. ¿Sabes por qué?"

"No. Es la primera vez que veo algo así".

"La clase Thread tiene una clase interna llamada State , así como un método público State getState() ".

public enum State
{
 NEW,
 RUNNABLE,
 BLOCKED,
 WAITING,
 TIMED_WAITING,
 TERMINATED;
}

"Siempre puede llamar al método getState () en un objeto Thread y averiguar su estado actual. Y, por supuesto, será uno de los valores de enumeración de estado".

"Ya veo. Entonces, los estados reales están dentro de la JVM, pero también hay estados a los que puede acceder a través del código Java usando el método State getState()".

"¿Y bajo qué circunstancias usaría eso?"

"Lo más probable es que nunca".

"Pero debe saber qué sucede dentro de los hilos. De lo contrario, tendrá muchos errores y ni siquiera podrá adivinar qué los está causando".

"Además, a los empleadores les encanta preguntar sobre los estados de Thread durante las entrevistas".