Comme ckhan l'a mentionné, jstack est génial car il donne la trace complète de la pile de tous les threads actifs dans la JVM. La même chose peut être obtenue sur stderr de la JVM en utilisant SIGQUIT.
Un autre outil utile est jmap qui peut récupérer un vidage de tas du processus JVM en utilisant le PID du processus :
jmap -dump:file=/tmp/heap.hprof $PID
Ce vidage de tas peut être chargé dans des outils comme visualvm (qui fait maintenant partie de l'installation standard du SDK Oracle Java, nommée jvisualvm). De plus, VisualVM peut se connecter à la JVM en cours d'exécution et afficher des informations sur la JVM, y compris des graphiques d'utilisation du processeur interne, du nombre de threads et de l'utilisation du tas - idéal pour rechercher les fuites.
Un autre outil, jstat , peut collecter des statistiques de récupération de place pour la JVM sur une période de temps similaire à vmstat lorsqu'il est exécuté avec un argument numérique (par exemple, vmstat 3 ).
Enfin, il est possible d'utiliser un agent Java pour pousser l'instrumentation sur toutes les méthodes de tous les objets au moment du chargement. La bibliothèque javassist peut aider à rendre cela très facile à faire. Ainsi, il est possible d'ajouter votre propre traçage. La partie difficile avec cela serait de trouver un moyen d'obtenir une sortie de trace uniquement lorsque vous le vouliez et pas tout le temps, ce qui ralentirait probablement la JVM. Il existe un programme appelé dtrace qui fonctionne d'une manière comme celle-ci. J'ai essayé, mais sans grand succès. Notez que les agents ne peuvent pas instrumenter toutes les classes car celles nécessaires pour amorcer la JVM sont chargées avant que l'agent puisse instrumenter, et il est alors trop tard pour ajouter l'instrumentation à ces classes.
Ma suggestion - commencez par VisualVM et voyez si cela vous dit ce que vous devez savoir car il peut afficher les threads actuels et les statistiques importantes pour la JVM.
Dans le même vain, lors du débogage de programmes qui ont mal tourné sur un système Linux, vous pouvez utiliser des outils similaires pour déboguer les JVM en cours d'exécution sur votre système.
Outil #1 - jvmtop
Similaire à top , vous pouvez utiliser jvmtop pour voir quelles sont les classes dans les JVM en cours d'exécution sur votre système. Une fois installé, vous l'invoquez comme ceci :
$ jvmtop.sh
Sa sortie est de style similaire pour ressembler à l'outil top :
JvmTop 0.8.0 alpha amd64 8 cpus, Linux 2.6.32-27, load avg 0.12
http://code.google.com/p/jvmtop
PID MAIN-CLASS HPCUR HPMAX NHCUR NHMAX CPU GC VM USERNAME #T DL
3370 rapperSimpleApp 165m 455m 109m 176m 0.12% 0.00% S6U37 web 21
11272 ver.resin.Resin [ERROR: Could not attach to VM]
27338 WatchdogManager 11m 28m 23m 130m 0.00% 0.00% S6U37 web 31
19187 m.jvmtop.JvmTop 20m 3544m 13m 130m 0.93% 0.47% S6U37 web 20
16733 artup.Bootstrap 159m 455m 166m 304m 0.12% 0.00% S6U37 web 46
Outil #2 - jvmmonitor
Une autre alternative consiste à utiliser jvmmonitor. JVM Monitor est un profileur Java intégré à Eclipse pour surveiller l'utilisation du processeur, des threads et de la mémoire des applications Java. Vous pouvez soit l'utiliser pour rechercher automatiquement des JVM en cours d'exécution sur l'hôte local, soit vous connecter à des JVM distants à l'aide d'un [email protected]
Outil n°3 - visualvm
visualvm est probablement "l'outil" à utiliser lors du débogage des problèmes avec la JVM. Son ensemble de fonctionnalités est assez profond et vous pouvez obtenir un aperçu très approfondi des entrailles.
Profiler les performances de l'application ou analyser l'allocation de mémoire :
Récupérer et afficher les fils de discussion :
Références
- tutoriel visualvm
Considérez jstack .Pas tout à fait une correspondance pour strace , plutôt un pstack -analogique, mais vous donnera au moins une image d'un instantané dans le temps. Pourriez-les enchaîner pour obtenir une trace grossière si vous le deviez.
Voir également les suggestions de cet article SO :https://stackoverflow.com/questions/1025681/call-trace-in-java