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

Java thread dump: WAITING (on object monitor) - what is it waiting on?

提问by Marina

there was a similar question asked java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on, but there was no concrete answer, so I will ask my question in hopes to get more info...

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

In the following thread dump I see that the thread is in the "WAITING (on object monitor)" state - but there is no line with "waiting on " that would indicate what it is waiting for. How do I interpret this thread stack and find out why (and what resource) this thread is waiting on?

在下面的线程转储中，我看到该线程处于“WAITING（在对象监视器上）”状态 - 但没有“waiting on”行表明它正在等待什么。我如何解释这个线程堆栈并找出这个线程等待的原因（以及什么资源）？

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

This thread is one of the listener threads configured to accept messages from the Tibco bus.

此线程是配置为接受来自 Tibco 总线的消息的侦听器线程之一。

thanks!

谢谢！

Marina

码头

回答by apangin

It's a peculiarity of HotSpot JVM. When dumping a stack, JVM recovers the wait object from the method local variables. This info is available for interpreted methods, but not for compiled native wrappers.

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

When Object.waitis executed frequently enough, it gets JIT-compiled.
After that there will be no "waiting?on"line in a thread dump.

当Object.wait执行得足够频繁时，它会被 JIT 编译。
之后，线程转储中将没有“waiting?on”行。

1. Since wait()must be called on a synchronizedobject, most often the wait object is the last locked object in the stack trace. In your case it is

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

2. To prevent Object.waitfrom being JIT-compiled (and thus making wait info always available) use the following JVM option

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

1. 由于wait()必须在synchronized对象上调用，因此等待对象通常是堆栈跟踪中最后一个锁定的对象。在你的情况下是

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

2. 为了防止Object.wait被 JIT 编译（从而使等待信息始终可用），请使用以下 JVM 选项

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

回答by L. Yan

This thread is waiting the notification from another thread (thread name is TCPLinkReader, if you look over the full thread dump you should be able to find it) which is created by the TIBCO EMS client library.

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

The stacktrace shows that the Spring application is trying to commit a session. To commit the session EMS client needs to send some data to server and waiting for the confirmation from server that the session is committed successfully or not.

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

TCPLinkReader thread is a dedicated thread that EMS client use to receive downstream (from server to client) TCP packets.

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

If you are seeing this thread lasts for long, there are 2 scenarios:

如果您看到此线程持续很长时间，则有两种情况：

• Something wrong on the EMS server side, possibly hung

• there are some defects in the client library that caused deadlock, so server did send the response back but the TCPLinkReader thread did not notify the caller thread.

• EMS服务器端有问题，可能挂了

• 客户端库中存在一些缺陷导致死锁，因此服务器确实将响应发送回，但 TCPLinkReader 线程没有通知调用者线程。

Last, post the full thread dump if problem persists.

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