L'analyse de thread dump d'un processus java

Que je dispose de Java EE en fonction de l'application en cours d'exécution sur tomcat et je vois que tout d'un coup, l'application se bloque au bout de quelques heures.

J'ai recueilli le thread dump de l'application juste avant qu'il se bloque et le mettre dans TDA pour l'analyse:

L'analyse de thread dump d'un processus java

TDA (Thread Dump de l'Analyseur) donne le message suivant pour le moniteur:

A lot of threads are waiting for this monitor to become available again.
This might indicate a congestion. You also should analyze other locks 
blocked by threads waiting for this monitor as there might be much more 
threads waiting for it.

Et voici le suivi de pile du thread mis en évidence ci-dessus:

"MY_THREAD" prio=10 tid=0x00007f97f1918800 nid=0x776a 
             waiting for monitor entry [0x00007f9819560000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.util.Hashtable.get(Hashtable.java:356)
    - locked <0x0000000680038b68> (a java.util.Properties)
    at java.util.Properties.getProperty(Properties.java:951)
    at java.lang.System.getProperty(System.java:709)
    at com.MyClass.myMethod(MyClass.java:344)

Je veux savoir quel est le "waiting for monitor entry" état signifie? Et également apprécie les pointeurs pour m'aider à déboguer ce problème.

  • Je cache les recherches de propriétés du Système plutôt que de l'appeler à plusieurs reprises de ce genre. Vous ne devriez pas besoin de Système d'appel.getProperty() plus d'une douzaine de fois au cours de la durée de vie de l'application. c'est à dire que vous devriez code, donc ce n'est pas un goulot de bouteille.
  • hmm.. bon point de Pierre!
InformationsquelleAutor peakit | 2012-07-05
  1. 5

    L'un de vos fils acquis un moniteur de l'objet (un verrou exclusif sur un objet). Cela signifie que le fil est en cours d'exécution synchronisée code et pour quelque raison que ce soit coincé là-bas, probablement en attente pour d'autres threads. Mais les autres threads ne peuvent pas poursuivre leur exécution, car ils ont rencontré un bloc synchronisé et a demandé un verrou (le moniteur de l'objet), mais ils ne peuvent l'obtenir jusqu'à ce qu'il est rejeté par les autres fil. Alors... probablement l'impasse.

    InformationsquelleAutor maestr0
  2. 2

    S'il vous plaît regardez pour cette chaîne de caractères à partir de l'ensemble de la thread dump

    - verrouillé <0x00007f9819560000>

    Si vous pouvez le trouver, le thread est en impasse avec fil "tid=0x00007f97f1918800"

    • oui bobon, j'ai cherché dans l'ensemble du thread dump pour cette chaîne et n'a pu trouver aucune autre référence pour cet id à part le fil mis en évidence dans la question.
    InformationsquelleAutor bobon
  3. 1

    Moniteur = synchronisé. Vous avez beaucoup de fils en essayant d'obtenir le verrou sur le même objet.

    Vous devriez peut-être passer de l'utilisation d'une table de hachage et d'utiliser une HashMap

    • Si vous voyez que je ne suis pas à l'aide de Hashtable directement. Ça vient de mon appel à System.getProperty(). Est-il un non-blocage de la version de System.getProperty()? Merci!
    InformationsquelleAutor ControlAltDel
  4. 1

    Cela signifie que votre fil est en essayant de mettre un verrou (sur la table de hachage), mais à un autre thread est déjà d'y accéder et a mis un verrou. Il est donc en attente pour le déverrouiller. Vérifier ce que vos autres threads sont en train de faire. Surtout avec du fil d'tid="0x00007f9819560000"

    • Il est intéressant de noter, je ne vois PAS de n'importe quel thread avec tid=0x00007f9819560000 dans le fil de fichier de vidage. Une idée?
    • Mmmmh, c'est probablement la VM moniteur verrouiller la table ensuite. Court de voir le code, il va être difficile. Essentiellement, la table de hachage est en compétition pour entre deux threads. Une option pourrait être de remplacer la table de hachage avec une HashMap (parce que la table de hachage n'est pas thread-safe). Je sais que vous êtes en utilisant la Propriété, mais il suffit de copier une partie de la carte et à l'utilisation de la carte par la suite. Donc, vous allez le voir sauter sur la contention (ConcurrentModificationException probablement), ou il commence à travailler parce que le verrou n'était même pas nécessaire.
    InformationsquelleAutor mprivat