2012-07-05 8 views
9

Ich habe Java EE-basierte Anwendung läuft auf Tomcat und ich sehe, dass plötzlich die Anwendung hängt nach dem Ausführen für einige Stunden.Analysieren Thread-Dump eines Java-Prozesses

:

ich gesammelt, um den Thread-Dump aus der Anwendung, kurz bevor es und es in TDA zur Analyse setzen hängt: Für den oben stehenden Monitor

enter image description here

TDA (Thread-Dump Analyzer) gibt die folgende Meldung

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. 

Und hier ist der Stacktrace des Gewindes oben hervorgehoben:

"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) 

Ich möchte wissen, was der "waiting for monitor entry" Zustand bedeutet? Außerdem würde ich mich über Hinweise freuen, die mir helfen, dieses Problem zu beheben.

+4

I würde Lookups von Systemeigenschaften zwischenspeichern, anstatt sie auf diese Weise wiederholt aufzurufen. Sie sollten System.getProperty() nicht mehr als etwa ein Dutzend Mal über die Laufzeit der Anwendung aufrufen müssen. Sie sollten es also so programmieren, dass es kein Flaschenhals ist. –

+0

hmm .. guter Punkt Peter! – peakit

Antwort

1

Monitor = synchronisiert. Sie haben viele Threads versucht, die Sperre für das gleiche Objekt zu erhalten.

Vielleicht sollten Sie wechseln von einer Hashtable und verwenden eine HashMap

+0

Wenn Sie sehen, verwende ich 'Hashtable' nicht direkt. Es kommt von meinem Aufruf an 'System.getProperty()'. Gibt es eine nicht blockierende Version von 'System.getProperty()'? Vielen Dank! – peakit

1

Dies bedeutet, dass der Thread eine Sperre zu setzen versucht (auf der Hashtable), aber einige andere Thread bereits darauf zugreift und hat es eine Sperre . Es wartet also auf die Freigabe des Schlosses. Überprüfe, was deine anderen Threads machen. Vor allem Thread mit tid = "0x00007f9819560000"

+0

Interessanterweise sehe ich keinen Thread mit 'tid = 0x00007f9819560000' in der Thread-Dump-Datei. Irgendeine Idee? – peakit

+0

Mmmmh, ist wahrscheinlich die VM-Monitor-Tabellensperre dann. Kurz, um den Code zu sehen, wird es schwierig werden. Im Wesentlichen wird die Hashtable um zwei Threads konkurrieren. Eine Option könnte sein, die Hashtabelle durch eine HashMap zu ersetzen (weil HashMap nicht threadsicher ist). Ich weiß, dass Sie Property verwenden, aber kopieren Sie einfach in eine Karte und verwenden Sie anschließend die Karte. Sie werden also sehen, dass es bei Konflikten explodiert (vermutlich ConcurrentModificationException), oder es funktioniert, weil die Sperre nicht einmal benötigt wurde. – mprivat

5

Einer Ihrer Threads erwarb ein Monitor-Objekt (eine exklusive Sperre für ein Objekt). Das bedeutet, dass der Thread synchronisierten Code ausführt und aus irgendeinem Grund dort feststeckt und möglicherweise auf andere Threads wartet. Die anderen Threads können ihre Ausführung jedoch nicht fortsetzen, da sie auf einen synchronisierten Block gestoßen sind und nach einer Sperre gefragt haben (Monitor-Objekt), jedoch erst, wenn sie von einem anderen Thread freigegeben wurde. Also ... wahrscheinlich Sackgasse.

2

Bitte suchen Sie nach diesem String aus der ganzen Thread Dump

-< gesperrt 0x00007f9819560000>

Wenn Sie es finden können, ist der Thread mit Thread-Deadlock "tid = 0x00007f97f1918800"

+0

ja bobon, ich suchte im gesamten Thread-Dump nach dieser Zeichenkette und konnte außer dem in der Frage hervorgehobenen Thread keine andere Referenz für diese ID finden. – peakit