Java-Thread-Dump: WARTEN (auf Objektmonitor) - Worauf wartet es?

Question

gibt es eine ähnliche Frage gestellt java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on, aber es gab keine konkrete Antwort, also werde ich meine Frage in der Hoffnung fragen, um mehr Informationen zu erhalten ...

Im folgenden Thread-Dump Ich sehe, dass der Faden in dem " WARTEN (auf Objektmonitor) "Zustand - aber es gibt keine Zeile mit" Warten auf ", die anzeigen würde, worauf es wartet. Wie interpretiere ich diesen Thread-Stack und finde heraus, warum (und auf welche Ressource) dieser Thread wartet?

"eventTaskExecutor-50" prio=10 tid=0x0000000004117000 nid=0xd8dd in Object.wait() [0x00007f8f457ad000] 
java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
at java.lang.Object.wait(Object.java:503) 
at com.tibco.tibjms.TibjmsxLink.sendRequest(TibjmsxLink.java:359) 
- locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse) 
at com.tibco.tibjms.TibjmsxSessionImp._confirmTransacted(TibjmsxSessionImp.java:2934) 
at com.tibco.tibjms.TibjmsxSessionImp._confirm(TibjmsxSessionImp.java:3333) 
- locked <0x00007f90101399b8> (a java.lang.Object) 
at com.tibco.tibjms.TibjmsxSessionImp._commit(TibjmsxSessionImp.java:2666) 
at com.tibco.tibjms.TibjmsxSessionImp.commit(TibjmsxSessionImp.java:4516) 
at org.springframework.jms.support.JmsUtils.commitIfNecessary(JmsUtils.java:217) 
at org.springframework.jms.listener.AbstractMessageListenerContainer.commitIfNecessary(AbstractMessageListenerContainer.java:577) 
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:482) 
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) 
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) 
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1102) 
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:996) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:722) 

Locked ownable synchronizers: 
- <0x00007f901011ca88> (a java.util.concurrent.ThreadPoolExecutor$Worker) 

Dieser Thread ist einer der Listener-Threads, die zum Akzeptieren von Nachrichten vom Tibco-Bus konfiguriert sind.

danke!

Marina

Answer 1

Es ist eine Besonderheit des HotSpot JVM. Beim Speichern eines Stapels stellt JVM das Wait-Objekt aus den lokalen Variablen der Methode wieder her. Diese Information ist für interpretierte Methoden verfügbar, jedoch nicht für kompilierte native Wrapper.

Wenn Object.wait häufig genug ausgeführt wird, wird es JIT kompiliert.
Danach wird es keine "Warten auf" Zeile in einem Thread-Dump sein.

1. Seit wait() muss auf ein synchronized Objekt aufgerufen werden, am häufigsten die Warte Objekt ist das letzte gesperrte Objekt im Stack-Trace. In Ihrem Fall ist es

   - locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse) 
   

2. Um Object.wait davon, dass JIT-kompiliert zu verhindern (und damit Warte info machen immer verfügbar) verwenden Sie die folgende JVM-Option

   -XX:CompileCommand="exclude,java/lang/Object.wait" 
   

Answer 2

Dieser Thread die wartet Benachrichtigung von einem anderen Thread (Thread-Name ist TCPLinkReader, wenn Sie über den vollständigen Thread-Dump schauen, sollten Sie in der Lage sein, ihn zu finden), der von der TIBCO EMS-Client-Bibliothek erstellt wird.

Der Stacktrace zeigt, dass die Spring-Anwendung versucht, eine Sitzung zu begehen. Um die Sitzung zu committen, muss der EMS-Client einige Daten an den Server senden und auf die Bestätigung vom Server warten, dass die Sitzung erfolgreich übergeben wurde oder nicht.

TCPLinkReader-Thread ist ein dedizierter Thread, den EMS-Client zum Empfangen von TCP-Paketen (von Server zu Client) verwendet.

Wenn Sie diesen Thread sehen für lange dauert, gibt es 2 Szenarien:

• etwas falsch auf der Seite EMS-Server, hing möglicherweise

• einige Mängel in der Client-Bibliothek gibt, die Deadlock verursacht, so dass der Server die Antwort zurücksendet, aber der TCPLinkReader-Thread den Thread des Aufrufers nicht benachrichtigt hat.

Zuletzt, veröffentlichen Sie den vollständigen Thread-Dump, wenn das Problem weiterhin besteht.