Java semble bloqué

Question

J'utilise le wrapper de service Java dans une application personnalisée depuis assez longtemps et tout fonctionne correctement. Depuis la mise à jour de notre application vers une nouvelle version au cours des derniers jours, la machine virtuelle Java a été suspendue, puis l’imprimante l’a imprimée dans le journal:  La machine virtuelle Java semble être suspendue: délai d'attente du signal de la machine virtuelle Java expiré.

Il met alors automatiquement fin à la machine virtuelle et redémarre l'application. Cela se produit après environ 10 heures d’exécution, ce qui rend le débogage plus difficile.

Bien sûr, je vais regarder à travers les modifications que nous avons apportées, mais aucune modification majeure n'a été apportée qui, je suppose, est à l'origine de ce type de problème.

Où puis-je chercher pour essayer de comprendre ce qui se passe? Les messages de débogage de l'application n'indiquent rien d'intéressant. Si la machine virtuelle Java se bloque, elle créera généralement un vidage, ce qui peut aider à la déboguer, mais elle est suspendue et ne crée donc pas de vidage. Si je ne le fais pas redémarrer automatiquement, y a-t-il quelque chose que je puisse faire pour obtenir des informations utiles de la machine virtuelle avant de le redémarrer?

Il me semble que la machine virtuelle Java ne devrait pas être suspendue à des erreurs de programmation classiques. Qu'est-ce que vous avez rencontré auparavant qui peut entraîner le blocage de la JVM?

Answer 1

J'avais plusieurs versions différentes d'une bibliothèque sur le classpath (JBPM). Avec wrapper, vous pouvez utiliser des caractères génériques pour inclure des bocaux. Soyez prudent avec cela car vous pouvez inclure accidentellement plus que vous ne devriez.

Voici un article IBM fournissant des informations sur le débogage est bloqué en Java . Il dit essentiellement qu'il y a deux choses qui peuvent causer des blocages:

1. Une boucle infinie,
2. Une impasse.

Depuis lors, j'ai dû déboguer d'autres problèmes de blocage. Sous Linux, vous pouvez envoyer le signal QUIT à la machine virtuelle Java pour lui faire effectuer un vidage de threads vers la console. Cela aide vraiment à comprendre où est le problème. Utilisez cette commande pour faire cela: kill -QUIT

Modifier le 13/06/2017

Ces jours-ci, j'utilise jmap inclus dans le JDK pour vider toute la mémoire du programme. Ensuite, j'utilise Eclipse Memory Analyzer pour voir l'état exact du programme au moment de son crash. Vous pouvez consulter la liste des threads actifs, puis inspecter les variables dans chaque cadre de pile.

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID>

Où PID est l'ID de processus du processus java.

Answer 2

Consultez la propriété wrapper.ping.timeout . . Le logiciel d'encapsulation communique avec votre machine virtuelle de temps en temps pour s'assurer de son bon fonctionnement. Si cette communication échoue pour une raison quelconque, l'encapsuleur considère que le processus est bloqué et tente de le redémarrer.

En fonction de l'architecture de votre application, il est possible que votre machine virtuelle Java soit en train de traiter quelque chose d'autre lorsque le wrapper tente de "cingler". il.

Answer 3

Vérifiez si vous pouvez utiliser la Visual VM pour voir ce qui se passe. Demandez à Visual VM de surveiller l'application pendant tout le temps. Lorsque cela cessera de fonctionner, vous pourrez peut-être déterminer ce qui ne va pas.

Si la machine virtuelle se bloque, vous pouvez obtenir l’état des threads ... Je pense que la machine virtuelle Visual rendra les choses un peu plus faciles compte tenu de votre configuration que la combinaison classique de Ctrl-break (ou quelle que soit la combinaison de touches).

(Modifier en fonction du commentaire)

  

J'ai essayé ceci. La dernière fois qu'il a accroché le   nombre de fils et la quantité de   la mémoire utilisée était assez faible, donc   aucun de ceux qui causent la   problème. Malheureusement après ça se bloque   et wrapper termine, vous ne pouvez pas   obtenir un vidage de thread.

Existe-t-il un moyen de l'exécuter sans le wrapper pour le déboguer? De plus, si vous utilisez le profileur NetBeans, cela vous donnera peut-être une chance de le gérer quand il s’arrêtera (je vérifierai plus tard aujourd’hui et je verrai si je peux savoir si cela se comporterait différemment).

Answer 4

Dans quel environnement es-tu? Système d'exploitation, version de la machine virtuelle Java, architecture matérielle?

Cela ressemble à un bogue, et étant donné que cela prend plusieurs heures, cela ressemble à un bogue d'épuisement des ressources.