Java 스레드 덤프 : WAITING (객체 모니터에서) - 대기 상태는 무엇입니까?

Question

은 비슷한 질문이 java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on을 요청하지만, 구체적인 응답이 없었다, 그래서 나는 스레드가있는 것을 볼 다음 스레드 덤프에서 ... 더 많은 정보를 얻을 희망

을 내 질문을 물어볼 것입니다 있었던 " WAITING (오브젝트 모니터에서) 상태 "- 기다리고있는 것을 나타내는"대기 중 "이있는 행이 없습니다. 어떻게이 스레드 스택을 해석하고이 스레드가 대기중인 이유 (및 어떤 자원)를 발견합니까?

"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

그것은 핫스팟 JVM의 특색입니다. 스택을 덤프 할 때 JVM은 메서드 로컬 변수에서 대기 객체를 복구합니다. 이 정보는 해석 된 메소드에서 사용할 수 있지만 컴파일 된 원시 랩퍼에서는 사용할 수 없습니다.

Object.wait이 자주 실행되면 JIT 컴파일됩니다.
그 후 스레드 덤프에 줄이 "대기 중"이되지 않습니다. wait() 이후

1. 가장 자주 대기 객체가 스택 추적의 마지막 잠긴 물체가하는 synchronized 개체에서 호출해야합니다. 귀하의 경우는

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

2. 가되는 것을 Object.wait을 방지하는 것입니다 JIT 컴파일이 스레드가를 기다리고

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

Answer 2

다음 JVM 옵션을 사용하여 (따라서 항상 사용할 대기 정보를 만드는) TIBCO EMS 클라이언트 라이브러리에 의해 생성 된 다른 스레드의 스레드 알림 (스레드 이름은 TCPLinkReader입니다. 전체 스레드 덤프를 보면 찾을 수 있어야합니다).

stacktrace는 Spring 애플리케이션이 세션을 커밋하려고 시도하고 있음을 나타냅니다. 세션을 커밋하려면 EMS 클라이언트는 서버에 일부 데이터를 보내고 세션이 성공적으로 커밋되었다는 서버의 확인을 기다려야합니다.

TCPLinkReader 스레드는 EMS 클라이언트가 TCP 패킷을 다운 스트림 (서버에서 클라이언트로)받는 데 사용하는 전용 스레드입니다.

이 스레드가 오랫동안 지속 표시되면,이 개 시나리오가 있습니다 : 아마도

클라이언트 라이브러리에 약간의 결함이 걸려는 EMS 서버 측에서 잘못

• 뭔가 그 교착 상태가 발생하여 서버가 응답을 되돌려 보냈지 만 TCPLinkReader 스레드가 호출자 스레드에 알리지 않았습니다.

마지막으로 문제가 지속되면 전체 스레드 덤프를 게시하십시오.