En tant qu'administrateur système, je suis parfois confronté à des situations où un programme se comporte de manière anormale, sans créer d'erreurs du tout ou en créant des messages d'erreur absurdes.
Dans le passé - avant l'arrivée de Java - il y avait deux contre-mesures :
- Si rien d'autre n'aide – RTFM 😉
- Si même 1. ne vous aide pas, tracez les appels système et voyez ce qui se passe
J'utilise habituellement strace -f pour cette tâche avec Linux (d'autres systèmes d'exploitation ont des outils de trace similaires). Bien que cela fonctionne généralement bien pour n'importe quel programme à l'ancienne, la trace devient très floue lorsque vous faites la même chose sur un java -processus. Il y a tellement d'appels système apparemment sans rapport avec une action réelle, qu'il est terrible de chercher dans un tel vidage.
Existe-t-il de meilleurs moyens de le faire (si le code source n'est pas disponible) ?
Réponse acceptée :
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). En outre, 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, ce qui est 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 librairie 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.