2012-06-28 2 views
5

JVM이 나에게 말한다 스레드에 의해 잠겨 있음을 보여줍니다"1 교착 상태 발견"하지만 추적은 교착 상태가 발생했음을

Found one Java-level deadlock: 
============================= 
"TP-Processor107": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 
"indexTrackerThread3": 
    waiting for ownable synchronizer 0x00002aaaf4394580, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "TP-Processor16" 
"TP-Processor16": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 

우리는 indexTrackerThread3TP-Processor16가 보유한 리소스를 기다리고 있음을 볼 수 있으며, 그 -versa. 그것은 정말로 교착 상태입니다.

우리는 볼 수 indexTrackerThread30x00002aaaf4394580을 기다리고 있습니다 :

"indexTrackerThread3": 
    - parking to wait for <0x00002aaaf4394580> 

내 질문 :the threads dump에서

, 왜 더 라인 - locked <0x00002aaaf4394580>이 없기를?

0x00002aaaf58e70f0이 실제로 모든 스레드에 의해 잠겨 있지 않은 것처럼 보입니다. 무엇이 그것을 잠글 수 있습니까?

모든 다른 - parking to wait for <0x123> 줄마다 항상 - locked <0x123> 줄이 있습니다 (example)의 모든 교착 상태 문서에서. 그래서 나는 JVM 버그를 의심하기 시작한다. 내가 뭔가를 오해하고 있니?

참고 : pastebin에 연결하는 것은 죄송합니다.하지만 전체 덤프가 필요하지 않은 질문은 답할 수 없습니다. 간결함을 위해 "at"가 포함 된 모든 행을 제거했지만 잠금 정보는 포함하지 않았습니다.

답변

4

java.util.concurrent 패키지는 국소적인 기본 주차 메커니즘 (뿐만 아니라 원자 비교 W 스왑)을 사용합니다. 내가 뭘 말하는지 알 수있어 here.

일반적으로 스레드 덤프에서 발생하는 것으로 설명하는 패턴은 기본 Java 관용구 synchronized(lock) { lock.wait(); }에서 유래합니다.

+0

링크를 제공해 주셔서 감사합니다. 나는 이제 Unsafe 클래스에 익숙해졌다. Unsafe.park에 대한 호출을 통해 수행하는 경우에도, 여전히 잠금은 자바 호출에서 온다, 그래서 왜'<0x123> '부분은 그 줄에서 쓸 수없는 잠긴 것? 나는 존재하지 않는 이슈의 특정 이슈에 대해 이야기하는 문서를 읽어 주시면 감사하겠습니다. –

0

Marko Topolnik의 답변이 정확합니다.

문제의 해결책은 JProfiler은 java.util.concurrent 패키지의 잠금과 관련된 잠금 상황에 대한 스레드 및 모니터의 전체 그래프를 표시합니다.

면책 조항 : 우리 회사가 JProfiler와

0

다른 일들이 동기화 된 키워드 일명, 한 가지이며, 자바 스레드, 모니터를 교착 수 있습니다 개발하고 있습니다.

A lock can be a built-in object monitor, an ownable synchronizer, or the Condition object associated with synchronizers.

또한 자세한 내용은 ThreadMXBean.findDeadlockedThreads 및 ThreadMXBean.findMonitorDeadlockedThreads의 정의에 팔 수 있습니다.

내가 아는 한 모니터 잠금 및 Java 5 잠금입니다.

스레드 덤프의 경우 waiting to lock <0x123>locked <0x123>의 조합은 모니터 잠금 전용입니다. java 5 잠금을 사용하면 첫 번째 부분 만 얻을 수 있습니다. parking to wait for <0x456>과 같은 것입니다. 그런 다음 스레드 덤프에서 0x456을 검색하지만 아무 것도 찾을 수 없습니다. 이것은 혼란 스럽다.

0

교착 이러한 유형의 스레드 덤프 분석의 복잡성은 java.util.concurrent의 패키지의 사용에 주로 기인한다. 이것은 Java 객체를 동기화하는 고전적이고 관입적인 방식을 벗어나기 위해 만들어졌습니다. 이 패키지는 예를 들어 동시 읽기 작업을 허용하면서 WRITE 작업을 단일 스레드 모델로 제한하려는 경우 매우 유용합니다. 이 접근법은 성능 튜닝 관점에서 우수합니다. 부작용은 동시성 문제를 처리 할 때 스레드 덤프 분석 프로세스의 복잡성이 증가하는 것입니다.

나는 당신은 또한 다음 문서를 검토하는 것이 좋습니다. 그것은 JVM도 (일반적으로 소유권의 개념을 가지고 설계되지 않은 잠금을 읽어 예정) 교착 상태를 감지 할 수 없습니다 hidden Java deadlock 시나리오 등의 문제에 대해 설명합니다. 예제 Java 프로그램이 예제로 제공됩니다.

0

스택 추적 0x00002aaaf4394580 모든 스레드에 의해 잠겨 있지 않은 것을 나타낸다. 이는 Java bug #6822370으로 인해 발생할 수 있습니다. 이 관찰은 voted answer에 마감을 추가해야합니다.