Um dos requisitos mais importantes quando se investiga deadlocks é ter, de fato, um deadlock para investigar. No meu último artigo, eu escrevi um código chamado DeadlockDemo que usou um grupo de threads para transferir valores aleatórios entre uma lista de contas bancárias antes de chegar a um impasse em um deadlock.

Este artigo executa esse código para demonstrar algumas maneiras de obter um dump de thread. Um dump de thread é simplesmente um relatório que mostra o status de todos as threads do seu aplicativo em um determinado ponto no tempo. A coisa boa sobre isso é que ele contém vários bits de informações que permitirão que você descubra por que você tem um deadlock, permitindo possivelmente que você possa corrigi-lo, mas falaremos mais sobre isso mais tarde.

kill SIGQUIT

Se o seu aplicativo Java estiver rodando em uma máquina UNIX, a primeira e a mais maneira mais fácil para agarrar a um dump de thread é usar o comando do UNIX kill através de um terminal.

Para fazer isso, primeiro obtenha o process identifier ou PID do seu aplicativo usando ps e grep. Por exemplo, se você digitar:

ps –e | grep java

 

…então você vai produzir uma lista que é mais ou menos assim:

74941 ttys000    0:00.01 grep java
70201 ttys004    1:00.89 /usr/bin/java threads.deadlock.DeadlockDemo

 

O PID para DeadlockDemo é, nesse caso, 70201 e é recebido a partir da saída acima. Observe que diferentes sabores do UNIX ou ou diferentes argumentos de linha de comando para o ps podem produzir resultados ligeiramente diferentes, portanto verifique suas páginas man.

Depois de obter seu PID, use-o para emitir um comando kill SIGQUIT:

kill -3 70201

 

O comando kill é o comando UNIX que dispõe de processos indesejados.

Embora o -3 acima seja o argumento SIGQUIT (equivalente ao ctrl-D do teclado), se o Java receber esse sinal, ele não vai parar, vai exibir um dump de thread no seu terminal associado. Você pode, então, se agarrar a ele e copiá-lo em um arquivo de texto para análise posterior.

jstack

Se você estiver trabalhando no Windows, então a linha de comando do UNIX não está disponível. Para resolver esse problema, o Java vem com um utilitário que atua como o equivalente de kill. Ele é chamado de jstack e está disponível no UNIX e no Windows. Ele é usado da mesma maneira que o comando kill demonstrado acima:
Conseguir um PID no Windows é uma questão de abrir o gerenciador de tarefas do Windows. O gerenciador de tarefas não exibe os PIDs por padrão, e por isso você precisa atualizar sua instalação usando a opção view do menu e verificar a opção PID (Process Identifier) da caixa diálogo Select Columns.

Em seguida, é só uma questão de examinar a lista de processos e encontrar a instância adequada do java.exe.

Leia o PID do java.exe e use-o como um argumento jstack como mostrado abaixo:

jstack

 

Uma vez que o comando for concluído, você pode agarrar-se à saída e copiá-la em um arquivo de texto para análise posterior.

jvisualVM

jvisualVM é o jeito “RollsRoyce” de obter um dump de thread. É fornecido pela Oracle como ferramenta que permite que você obtenha muitas informações diferentes sobre uma máquina virtual Java. Isso inclui heap dumps, uso de CPU, perfil de memória e muito mais.

O nome de programa real do jvisualVM é jvisualvm ou jvisualvm.exe no Windows. Uma vez em execução, você verá algo parecido com isto:

Para obter um dump de thread, encontre o seu aplicativo no painel de aplicativo no lado esquerdo, em seguida, clique com o botão direito do mouse e selecione: “dump de thread”.

Um dump de thread é exibido no painel da direita do jvisualvm, conforme mostrado abaixo:

Note que já vi jvisualvm em várias ocasiões, quando conectado à uma máquina virtual local. Quando isso acontece, garanta que suas configurações de proxy estejam definidas para No proxy.

Após ter obtido um dump de thread, meu próximo artigo vai usá-lo para investigar o “o que está acontecendo de errado com o código de exemplo DeadlockDemo”.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.captaindebug.com/2012/10/investigating-deadlocks-part-2.html#.USbGiqU3uSq