Ciclo de vida do encadeamento e estados do encadeamento

"Olá, amigo!"

"Vamos começar um novo tópico: tópicos."

"Vamos começar. Hoje examinaremos os estados pelos quais um objeto Thread passa (ou pode passar) quando um thread está em execução."

"Quantos estados você pode nomear agora, Amigo?"

"Dois. O primeiro é um thread antes do método start() ser chamado: o objeto existe, mas o thread ainda não está ativo. E o segundo é após o método start() ter sido chamado: quando o thread está fazendo algo importante."

"Você está certo - existe essa distinção. Esses estados são chamados de novos e em execução , mas isso é apenas o começo."

"Primeiro, em algum ponto o thread terminará a execução, o que significa que pode haver uma situação em que o objeto Thread existe, mas o thread não está no estado novo ou em execução. "Esse estado, em que o thread terminou de executar, é chamado encerrado ."

"Mas há mais. Não se esqueça de que, a qualquer momento, apenas um thread está realmente em execução. O que parece ser um trabalho simultâneo é, na verdade, o processador constantemente pulando de thread em thread. Há um estado separado para quando o thread parece estar running, mas na verdade está esperando sua vez: é chamado de ready-to-run . À medida que um thread funciona, ele muda constantemente de running para ready e, em seguida, volta a ser executado quando se torna ativo novamente."

"Imediatamente após o método start () ser chamado, o encadeamento recebe o status pronto para execução e é colocado em uma lista compartilhada de encadeamentos entre os quais a JVM alterna."

"Isso não é muito difícil. Antes de começar a executar, ele tem o novo estado. Depois de terminar, ele é encerrado . Quando está em execução, o thread está no estado de execução ; então, quando está esperando, está no estado pronto ."

"Sua brevidade é incrível, mas você está certo."

"Mas há mais. O encadeamento pode ser bloqueado. Por exemplo, quando você insere um bloco sincronizado . Se um encadeamento chegar a um bloco de código marcado como sincronizado e outro encadeamento o estiver usando, nosso encadeamento entrará no estado bloqueado e aguardará para que o mutex (bloqueio) do objeto seja liberado."

"Veja como esta situação com os estados parece:"

"Mas há mais. Há também um estado separado chamado wait . Isso ocorre quando um thread não está bloqueado , mas também não está pronto . Por exemplo, quando você chama o método join () em outro thread."

Quando chamamos join() em outro objeto Thread, é como se nosso thread o tivesse «juntado», mas na realidade ele apenas espera que o outro thread termine.

"Além disso, há também o método wait () (do trio de métodos wait/notify/notifyAll), que alterna um thread para o estado de espera quando é chamado."

"Uau."

"Espere um minuto! Ainda há mais. Um thread pode dormir chamando o método sleep, por exemplo. Há também um estado separado para isso. É chamado de « espera cronometrada ». « espera cronometrada » significa que o thread está esperando por algo para um tempo limitado. Se você chamar um método de espera com um parâmetro, como wait(timeout) ou join(timeout), o thread entrará no estado de espera por tempo."

"Aqui está o diagrama completo:"

"Hmm. Isso é tudo? Ou há mais 10 estados interessantes?"

"Por enquanto, é isso."

"Na prática, você pode se lembrar apenas do primeiro diagrama. É mais simples. Mas o segundo é mais preciso."

"Estranhamente, existem muitos diagramas de estado de Thread na Internet, e todos são diferentes."

"É por isso que lhe dei este diagrama - é o mais completo e correto."

"Neste diagrama, os estados pronto e em execução são combinados em um único bloco chamado executável. Você sabe por quê?"

"Não. É a primeira vez que vejo algo assim."

"A classe Thread tem uma classe interna chamada State , bem como um método público State getState() ."

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

"Você sempre pode chamar o método getState () em um objeto Thread e descobrir seu estado atual. E, é claro, será um dos valores de enumeração de State."

"Entendo. Portanto, os estados reais estão dentro da JVM, mas também há estados que você pode acessar via código Java usando o método State getState()."

"E em que circunstâncias eu usaria isso?"

"Provavelmente, nunca."

"Mas você tem que saber o que está acontecendo dentro dos threads. Caso contrário, você terá muitos bugs e nem será capaz de adivinhar o que os está causando."

"Além disso, os empregadores adoram perguntar sobre os estados do Thread durante as entrevistas."