Neste artigo, ensinarei você a analisar a pilha de threads da JVM e como encontrar a causa raiz do problema das informações da pilha. Na minha opinião, a tecnologia de análise de pilha de threads é uma tecnologia que os engenheiros de suporte para produtos Java EE devem dominar. As informações armazenadas na pilha de threads geralmente estão muito além da sua imaginação.
Meu objetivo é compartilhar o conhecimento e a experiência acumulados na análise de threads nos últimos dez anos. Esses conhecimentos e experiência são obtidos na análise em várias versões da JVM e dos fornecedores de JVM de vários fabricantes.
Então, você está pronto, agora este artigo é adicionado ao marcador. O que você está esperando, apresse -se e compartilhe este plano de treinamento de análise de threads com seus colegas e amigos.
Parece bom.
Minha sugestão é me seguir para concluir este plano de treinamento de análise de threads. Aqui estão o conteúdo de treinamento que abordaremos. Ao mesmo tempo, compartilharei com você os casos reais que lidei para que todos aprendam e entendam com todos.
1) Visão geral das pilhas de threads e conhecimento básico
2) Princípios e ferramentas relacionadas da pilha de threads
3) Diferentes formatos de pilha de threads JVM (Hotspot Sun, IBM JRE, Oracal Jrockit)
4) Método de introdução e análise do log de pilha de threads
5) Análise de pilhas de threads e tecnologias relacionadas
6) Modelos de problemas comuns (encadeamento, fechaduras mortas, IO chamando a morte, reciclagem de lixo/problema de Memoryerror, ciclo morto, etc.)
7) Por exemplo, análise de problemas de pilha de threads
Espero que esta série de treinamento traga sua verdadeira ajuda, por isso continue prestando atenção à atualização semanal dos artigos.
Mas o que devo fazer se tiver alguma dúvida no processo de estudo ou não consigo entender o conteúdo do artigo?
Não se preocupe, apenas me trate como seu mentor. Você pode me consultar qualquer dúvida sobre a pilha de threads (desde que o problema não possa ser muito baixo). Selecione as seguintes maneiras de entrar em contato comigo:
1) Comentado diretamente neste artigo (se você lamenta, você pode ser anônimo)
2) Envie os dados da pilha de threads para raios de causa do fórum de análise
3) Envie -me e -mail, o endereço é@[email protected]
Você pode me ajudar a analisar os problemas encontrados em nossos produtos?
Obviamente, se você estiver disposto, poderá me enviar seus dados ao vivo da pilha por meio de correio ou fórum de análise de capas raiz do fórum. O problema real é o rei de aprender a melhorar as habilidades.
Eu realmente espero que todos possam gostar desse treinamento. Então, farei o possível para fornecer materiais de alta qualidade e responder às suas várias perguntas.
Antes de introduzir a tecnologia de análise de pilha de threads e o modelo de problemas, você deve primeiro informar o conteúdo básico. Portanto, neste post, abordarei o conteúdo mais básico, para que todos possam entender melhor a interação entre contêineres JVM, Middleware e Java EE.
Visão geral do Java VM
Java Virtual Machine é a base da plataforma Jave EE. É o local onde o middleware e os aplicativos são implantados e em execução.
A JVM fornece as seguintes coisas para o software de middleware e seu programa Java/Java EE:
(Formulário binário) Programa Java / Java EE Ambiente de execução Algumas características e ferramentas funcionais do programa (infraestrutura de IO, estrutura de dados, gerenciamento de threads, segurança, monitoramento etc.).).).)
Alocação de memória dinâmica e gerenciamento com a ajuda da recuperação de lixo
Sua JVM pode permanecer em muitos sistemas operacionais (Solaris, AIX, Windows, etc.) e pode ser configurado de acordo com o seu servidor físico.
Interação entre JVM e Middleware
O diagrama a seguir mostra o modelo interativo de alta rise entre JVM, middleware e aplicativos.
Algumas interações simples e típicas entre a JVM, o middleware e os aplicativos exibidos na figura. Como você pode ver, a alocação dos threads do aplicativo Java EE padrão é concluída entre o núcleo da parte do meio e a JVM. (Claro, existem exceções. O aplicativo pode chamar diretamente a API para criar um tópico. Essa abordagem não é comum e é necessário ter cuidado durante o uso)
Ao mesmo tempo, observe que alguns threads são gerenciados pela JVM.
Como a maioria dos threads é feita pelo contêiner Java EE, é importante entender e entender o rastreamento da pilha de threads e pode identificá -lo a partir dos dados da pilha de threads, o que é importante para você. As solicitações estão prestes a executar o contêiner Java EE.
Da perspectiva da análise de uma pilha de armazenamento de threads, você poderá entender a diferença entre o pool de threads descoberto da JVM e identificar o tipo de solicitação.
A última seção fornecerá uma visão geral da pilha de threads JVM para o HotSOP V fornecer.
Observe que você pode obter um exemplo de pilha de threads para este artigo das razões fundamentais.
Pilha de threads jvm -Qual é?
A pilha de threads JVM é um determinado instantâneo de tempo que pode fornecer uma lista completa de todos os threads java criados.
Todo tópico Java encontrado fornecerá as seguintes informações:
O nome do tópico;
Tipo e prioridade do thread, por exemplo: Daemon PRIO = 3 ** O programa de middleware geralmente cria seus threads na forma de tutela de fundo, o que significa que esses threads estão sendo executados em segundo plano; Para o seu aplicativo Java EE **
ID do thread java, como: tid = 0x000000011e52a800 ** Este é o ID do thread java obtido através do java.lang.thread.getId ().
ID do thread nativo, como: nid = 0x251c **, a chave é porque o ID do thread nativo permite obter você da perspectiva do sistema operacional.
Status do thread Java e informações detalhadas, como: Waiting for Monitor Entry [0xffffffffffFea5afb000] java.lang.thread.state: bloco (no monitor de objeto)
** Você pode entender rapidamente o possível motivo pelo qual o status do thread está extremamente bloqueado **
Rastreamento de thread java; Causa de muitos tipos de problemas, 90%das informações necessárias.
Decomposição da memória da pilha Java; Esta informação é muito útil ao analisar os problemas causados por GCs frequentes. Você pode usar os dados ou modo de encadeamento conhecido para fazer um posicionamento rápido.
Heappynggen Total 466944k, usado 178734k [0xffffffffffffffffffffffffffffffffffff50 233472k, 76% F45C00000, 0xfffff50) fffffffff62400000, 0xfffffff62400000,0xffffffffff70800000) E 233472K, 0% Userd [0xfffffffffffffffffffff540000, 0xfffffffffffff5000000 , 0XFFFFFFFFF62400000) PSOLDGEN TOTAL 1400832K, USED 1400831K [0xffffffffef0400000, 0xffffff45c00000, 0xFFFFFFFFF45C00000) Object Space 1400832K, 99% Used [0xffffffFFFFFFFEF0400000, 0XFFFFFFFFF45BFFFFB8,0XFFFFFFFFFFF45C00000) PSPERMGEN TOTAL 262144K, USED 248475K , 0xffffffee0400000, 0xFFFFFFFFFF0400000) Object Space 262144K, 94 % used [0xffffffffed0400000 , 0xfffffffedf6f08,0xfffffffffffee0400000)
Grande desmontagem de informações de pilha de threads
Para permitir que todos entendam melhor, a imagem a seguir é fornecida a todos.
Na figura acima, pode -se observar que a pilha de thread é composta por várias partes diferentes. Essas informações são importantes para a análise do problema, mas a análise de diferentes problemas de problemas usará diferentes peças (o modo de problema simulará e demonstrará nos artigos posteriores.)
Agora, por meio deste exemplo de análise, explicarei em detalhes os componentes do Hotespot em informações de pilha de thread:
# Lixo completo dump
O "despejo de thread completo" é uma palavra -chave global. Este é o começo do instantâneo da pilha de threads.
Hotspot Java (TM) de 64 bits VM (20.0-B11 Misto de 64 bits (20.0-B11):
# Java EE Middleware, terceiros e threads no software de aplicativo personalizado
Esta parte é a parte central de toda a pilha de threads e também é a parte que geralmente precisa analisar o tempo. O número de linhas intermediárias da Stack depende do middleware que você usa, uma biblioteca de terceiros (pode ter threads independentes) e seu aplicativo (se você criar um thread personalizado, isso geralmente não é uma boa prática).
Em nossa pilha de threads de exemplo, o WebLogic é o middleware que usamos. A partir do WebLogic 9.2, você usará o pool de threads exclusivo que pode ser gerenciado por "
"[Standby] ExecutEThread: '414' para fila: 'weblogic.kernel.default (ajuste auto-ajuste)'" Daemon prio = 3 tid = 0x000000010916a800 nid = 0x2613 em objeto .wait () [0XFFFFFFFFFFFFF000] Estado: espera (no monitor de objeto) em java.lang.Object.wait (método nativo) -Waiting em <0xfffffffff27d44de0> (a weblogic.work.exectetethread). Work.work.cutethread.waitForRequest (Executethread.java:160) -locked <0xffffffffff27d44de0> (a weblogic.work.exectetethread) C.Work.executhread.run (executethread.java:181)
# Thread de hotspot vm
Este é um encadeamento interno gerenciado pela VM do Hotspot para a operação nativa de operações internas. Geralmente, você não precisa fazer muito sobre isso, a menos que encontre uma alta taxa de ocupação da CPU, a menos que você (através de pilhas de threads relacionadas e PRSTAT ou ID de thread nativo).
"Thread de tarefas periódicas da VM" prio = 3 tid = 0x0000000101238800 nid = 0x19 aguardando na condição
# Tópico de hotspot gc
Ao usar o Hotspot para GC paralelo (agora é comum no ambiente de vários núcleos físicos), quando a VM do ponto de acesso criada por padrão, ou cada JVM gerencia um thread GC com um logotipo específico. A limpeza periódica do GC causará a redução geral do tempo de GC;
"GC Thread Thread#0 (ParallelGC)" PRIO = 3 TID = 0x0000000100120000 NID = 0x3 Runnable "GC Tarefa Thread#1 (ParallelGC)" PRIO = 3 TID = 0x0000131000 NID = 0x4444 ……………………………………………………………………………………………………………………………… ………………………………………………………
Esses são dados críticos, porque quando você encontra problemas relacionados ao GC, como GC excessivo e vazamentos de memória, você poderá usar o sistema operacional ou o thread Java associado ao valor de ID nativo desses threads e, em seguida, encontrar qualquer direito Certo.
# Jni contagem de referência global
A referência global do JNI (interface local Java) é do código local para o objeto básico do objeto Java gerenciado pelo Java Lipe Collector. coleta de lixo.
Ao mesmo tempo, também é importante prestar atenção às referências do JNI para detectar vazamentos relacionados ao JNI.
REFERÊNCIAS GLOBAL JNI: 1925
# Java Stack Use View
Esses dados foram adicionados ao JDK 1.6, fornecendo uma visão curta e rápida da pilha de pontos de acesso. E a pilha Java em um instantâneo separado, para que você possa analisar (ou excluir) em um espaço específico da memória da pilha Java naquele momento.
Heap Psyounggen Total 466944K, Used 178734K [0xffffffff45c00000, 0xFFFFFFFF70800000, 0XFFFFFFFFF70800000) Eden Space 233472K, 76% USED F45C00000, 0XFFFFFFFF50AB7C50,0XFFFFFFFFFF540000) From Space 233472K, 0% Used [0xffffffffffffff62400000, 0xFFFFFFF62400000,0XFFFFFFFFF70800000) e 233472K, 0% used [ 0XFFFFFFFFF54000000, 0xffffffff540000, 0xFFFFFFFFF62400000) PSOLDGEN TOTAL 1400832k, Used 1400831K [0xffffffef0400000, 0xffffffffffffffffff, 0XFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFI FF45C00000) Object space 1400832k, 99% USED [0xffffffFFFFEF0400000,0XFFFFFFFFFF45BFFFFB8,0XFFFFFFFFF45C00000) PSPERMGEN TOTAL 262144K, USED 248475K [0 XFFFFFFFFFED0400000, 0xFFFFFFFFFEE0400000, 0xFFFFFFFFFEF0400000) Object Space 262144K, 94% utilizados [0xfffffffffed0400000,0xffffffffff6a6f08,0xffffffffee040000