Quais são os planos de ação apropriados para depurar o problema de dead lock se estiver no ambiente PRODUÇÃO?

Nota Eu não estou pedindo o conceito de bloqueio morto. Estou interessado em saber o que você fará se encontrar esse problema em seu aplicativo java no servidor de cluster de produção e nas habilidades de debugging.

Questão

  • A melhor prática de planos sobre analisar etapas.

Suposição

  • você já sabe que um servidor é atingido por esse problema.
  • OS está usando o Linux.

Objetivo

  • Você quer saber a causa raiz e corrigi-lo.

  1. Envie ao servidor um sinal SIGQUIT para forçar um despejo de pilha. Se você estiver no Windows, talvez consiga obter um dump comparável usando o jconsole . Talvez . Mas a vida é muito mais fácil se você executar servidores no Linux.
  2. Inspecione o despejo de pilha para encontrar o deadlock
  3. Sabendo o que é, tente reproduzir no servidor de teste
  4. Quando você pode reproduzi-lo, corrigi-lo e, em seguida, teste no servidor de teste

Basta encontrar outra sugestão de link útil pelas dicas de Ernest. http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/

Alguns conselhos neste artigo.

No windows, você pode usar o resultado da amostra aqui.

 2011-08-27 19:48:38 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.2-b03 mixed mode): "DestroyJavaVM" prio=6 tid=0x00000000003db000 nid=0x414 waiting on condition [0x 0000000000000000] java.lang.Thread.State: RUNNABLE "Thread-1" prio=6 tid=0x0000000006621800 nid=0x2178 waiting for monitor entry [0 x0000000006f8f000] java.lang.Thread.State: BLOCKED (on object monitor) at SimpleDeadLock$Thread2.run(SimpleDeadLock.java:33) - waiting to lock <0x00000000ebc3c3e8> (a java.lang.Object) - locked <0x00000000ebc3c3f8> (a java.lang.Object) "Thread-0" prio=6 tid=0x000000000661f000 nid=0x1f50 waiting for monitor entry [0 x0000000006e8f000] java.lang.Thread.State: BLOCKED (on object monitor) at SimpleDeadLock$Thread1.run(SimpleDeadLock.java:20) - waiting to lock <0x00000000ebc3c3f8> (a java.lang.Object) - locked <0x00000000ebc3c3e8> (a java.lang.Object) "Low Memory Detector" daemon prio=6 tid=0x0000000006603000 nid=0x1118 runnable [ 0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" daemon prio=10 tid=0x0000000006600800 nid=0x1340 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" daemon prio=10 tid=0x00000000065ee000 nid=0x1e10 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Attach Listener" daemon prio=10 tid=0x00000000065a2800 nid=0xebc runnable [0x00 00000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x000000000659d000 nid=0x18b4 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x000000000052d800 nid=0x1b6c in Object.wait() [0x 000000000658f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000ebc01300> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) - locked <0x00000000ebc01300> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source) "Reference Handler" daemon prio=10 tid=0x0000000000523800 nid=0x2054 in Object.w ait() [0x000000000648f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000ebc011d8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source) - locked <0x00000000ebc011d8> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x000000000051b800 nid=0x1f44 runnable "GC task thread#0 (ParallelGC)" prio=6 tid=0x0000000000476000 nid=0x25c runnable "GC task thread#1 (ParallelGC)" prio=6 tid=0x0000000000478800 nid=0x1ef0 runnabl e "GC task thread#2 (ParallelGC)" prio=6 tid=0x000000000047b000 nid=0x1d88 runnabl e "GC task thread#3 (ParallelGC)" prio=6 tid=0x000000000047c800 nid=0x1e3c runnabl e "VM Periodic Task Thread" prio=10 tid=0x000000000661c000 nid=0x1f40 waiting on c ondition JNI global references: 882 Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x000000000052abb0 (object 0x00000000ebc3c3e8, a java. lang.Object), which is held by "Thread-0" "Thread-0": waiting to lock monitor 0x000000000052d460 (object 0x00000000ebc3c3f8, a java. lang.Object), which is held by "Thread-1" Java stack information for the threads listed above: =================================================== "Thread-1": at SimpleDeadLock$Thread2.run(SimpleDeadLock.java:33) - waiting to lock <0x00000000ebc3c3e8> (a java.lang.Object) - locked <0x00000000ebc3c3f8> (a java.lang.Object) "Thread-0": at SimpleDeadLock$Thread1.run(SimpleDeadLock.java:20) - waiting to lock <0x00000000ebc3c3f8> (a java.lang.Object) - locked <0x00000000ebc3c3e8> (a java.lang.Object) Found 1 deadlock. Heap PSYoungGen total 18176K, used 937K [0x00000000ebc00000, 0x00000000ed040000 , 0x0000000100000000) eden space 15616K, 6% used [0x00000000ebc00000,0x00000000ebcea520,0x00000000ec b40000) from space 2560K, 0% used [0x00000000ecdc0000,0x00000000ecdc0000,0x00000000ed0 40000) to space 2560K, 0% used [0x00000000ecb40000,0x00000000ecb40000,0x00000000ecd c0000) PSOldGen total 41472K, used 0K [0x00000000c3400000, 0x00000000c5c80000, 0x00000000ebc00000) object space 41472K, 0% used [0x00000000c3400000,0x00000000c3400000,0x00000000 c5c80000) PSPermGen total 21248K, used 2930K [0x00000000be200000, 0x00000000bf6c000 0, 0x00000000c3400000) object space 21248K, 13% used [0x00000000be200000,0x00000000be4dc9f8,0x0000000 0bf6c0000) 

Lista de verificação do especialista

Isso cobre a teoria sobre rastreamentos de pilha Java e agora você deve saber o que procurar na próxima vez que vir um. Para economizar tempo, certifique-se de fazer uso total da pesquisa de erros do JDC para ver se o problema que você está tendo já foi relatado.

Para resumir, aqui estão os passos a seguir quando você se deparar com um problema do programa Java:

Para programas suspensos, congelados ou congelados : Se você acha que seu programa está interrompido, gere um rastreamento de pilha e examine os encadeamentos nos estados MW ou CW. Se o programa estiver em deadlock, alguns dos encadeamentos do sistema provavelmente aparecerão como encadeamentos atuais, porque não há mais nada para a JVM fazer.

Para programas que falharam e foram abortados : No UNIX, procure por um arquivo principal. Você pode analisar esse arquivo em uma ferramenta de debugging nativa, como gdb ou dbx. Procure por encadeamentos que tenham chamado methods nativos. Como a tecnologia Java usa um modelo de memory segura, qualquer corrupção provavelmente ocorreu no código nativo. Lembre-se de que a JVM também usa código nativo, portanto, pode não ser necessariamente um bug em seu aplicativo.

Para programas ocupados : O melhor curso de ação que você pode tomar para programas ocupados é gerar rastreamentos frequentes de pilha. Isso diminuirá o caminho do código que está causando os erros e você poderá iniciar sua investigação a partir daí.

Boa sorte e feliz debugging

Nice artigo oficial de fato! Só quero compartilhar com você!

O comando de envio do SIGQUIT será um pouco diferente no SO diferente.

Mas não a principal preocupação aqui.

Eu acho outra opção para ver o rastreamento de pilha de threads além do comando do sistema operacional. Isso é usando o jstack pid.

Mas o jstack não está atualmente disponível nas plataformas Windows ou na plataforma Linux Itanium.

Existe até uma ferramenta de análise de rastreamento de pilha que é encontrada em uma postagem do SO.

Existe um processo passo-a-passo muito detalhado deste post !