Question

有一个类似的问题java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on，但没有具体的答案，所以我会问我的问题，希望能获得更多信息......

在下面的线程转储中，我看到该线程位于＆＃34; WAITING（在对象监视器上）＆＃34;国家 - 但没有＆＃34;等待＆＃34;这表明它正在等待什么。如何解释此线程堆栈并找出此线程正在等待的原因（和资源）？

"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总线的消息的侦听器线程之一。

谢谢！

码头

Answer 1

这是HotSpot JVM的一个特点。转储堆栈时，JVM从方法局部变量恢复等待对象。此信息可用于已解释的方法，但不适用于已编译的本机包装器。

当Object.wait频繁执行时，它会被JIT编译之后，在线程转储中将没有“等待”行。

由于必须在wait()对象上调用synchronized，因此通常等待对象是堆栈跟踪中的最后一个锁定对象。在你的情况下它是
```
- locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse)
```
为防止Object.wait被JIT编译（从而使等待信息始终可用），请使用以下JVM选项
```
-XX:CompileCommand="exclude,java/lang/Object.wait" 
```

Answer 2

此线程正在等待来自另一个线程的通知（线程名称为TCPLinkReader，如果您查看应该能够找到的完整线程转储），这是由TIBCO EMS客户端库创建的。

stacktrace显示Spring应用程序正在尝试提交会话。要提交会话，EMS客户端需要向服务器发送一些数据，并等待服务器确认会话成功提交与否。

TCPLinkReader线程是EMS客户端用于接收下游（从服务器到客户端）TCP数据包的专用线程。

如果你看到这个帖子持续很长时间，有两种情况：

EMS服务器端出错，可能挂起
客户端库中存在一些导致死锁的缺陷，因此服务器确实发回了响应，但TCPLinkReader线程没有通知调用者线程。

最后，如果问题仍然存在，请发布完整的线程转储。

Java线程转储：WAITING（在对象监视器上） - 它在等待什么？

2 个答案: