同様の質問がありました Java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on しかし、具体的な答えがなかったので、質問しますより多くの情報を得ることを望んでいる私の質問...
次のスレッドダンプでは、スレッドが「WAITING(オブジェクトモニター上)」状態にあることがわかりますが、待機していることを示す「waitingon」の行はありません。このスレッドスタックを解釈して、このスレッドが待機している理由(およびどのリソース)を見つけるにはどうすればよいですか?
"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)
このスレッドは、Tibcoバスからのメッセージを受け入れるように構成されたリスナースレッドの1つです。
ありがとう!
マリーナ
これはHotSpotJVMの特徴です。スタックをダンプするとき、JVMはメソッドのローカル変数から待機オブジェクトを回復します。この情報は、解釈されたメソッドで利用できますが、コンパイルされたネイティブラッパーでは利用できません。
_Object.wait
_が十分な頻度で実行されると、JITコンパイルされます。
その後、スレッドダンプに"waiting on"行がなくなります。
wait()
はsynchronized
オブジェクトで呼び出す必要があるため、ほとんどの場合、待機オブジェクトはスタックトレースで最後にロックされたオブジェクトです。あなたの場合は
_- locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse)
_
_Object.wait
_がJITコンパイルされないようにするには(したがって、待機情報を常に利用できるようにするには)、次のJVMオプションを使用します。
_-XX:CompileCommand="exclude,Java/lang/Object.wait"
_
このスレッドは、TIBCO EMSクライアントライブラリによって作成された別のスレッド(スレッド名はTCPLinkReaderです。完全なスレッドダンプを調べると、それを見つけることができるはずです)からの通知を待機しています。
スタックトレースは、Springアプリケーションがセッションをコミットしようとしていることを示しています。セッションをコミットするにはEMSクライアントはサーバーにデータを送信し、セッションが正常にコミットされたかどうかのサーバーからの確認を待つ必要があります。
TCPLinkReaderスレッドは、EMSクライアントがダウンストリーム(サーバーからクライアントへ)TCPパケットを受信するために使用する)専用スレッドです。
このスレッドが長く続く場合は、次の2つのシナリオがあります。
EMSサーバー側に問題があり、ハングしている可能性があります
デッドロックの原因となったクライアントライブラリにいくつかの欠陥があるため、サーバーは応答を送り返しましたが、TCPLinkReaderスレッドは呼び出し元のスレッドに通知しませんでした。
最後に、問題が解決しない場合は、完全なスレッドダンプを投稿します。