Java线程转储:等待(在对象监视器上)-等待什么? [英] Java thread dump: WAITING (on object monitor) - what is it waiting on?

查看:111
本文介绍了Java线程转储:等待(在对象监视器上)-等待什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

还有一个类似的问题,

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...

在下面的线程转储中,我看到该线程处于正在等待(在对象监视器上)"状态-但是没有一行与"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?

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

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

谢谢!

Marina

推荐答案

这是HotSpot JVM的独特之处.转储堆栈时,JVM从方法局部变量恢复等待对象.此信息可用于解释方法,但不适用于已编译的本地包装.

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.

Object.wait执行得足够频繁时,它将被JIT编译.
之后,线程转储中将没有正在等待" 行.

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

  1. 由于必须在synchronized对象上调用wait(),因此大多数情况下,等待对象是堆栈跟踪中的最后一个锁定对象.就您而言是

  1. Since wait() must be called on a synchronized object, 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)

  • 要防止Object.wait进行JIT编译(从而使等待信息始终可用),请使用以下JVM选项

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

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

  • 这篇关于Java线程转储:等待(在对象监视器上)-等待什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆