이 스택 덤프는 교착 상태가 있음을 나타 냅니까?

Question

Jersey을 사용하여 REST 서비스를 구축했습니다.

내 REST API에 대해 "말림"을 수행하면 명령이 중지됩니다.

내가 실행 한 jstack & 이것은 BLOCKED 상태의 두 스레드 요약 출력입니다.

"pool-2-thread-11" prio=6 tid=0x01d51800 nid=0x2394 
waiting for monitor entry [0x05e6f000..0x05e6fce8] 
java.lang.Thread.State: BLOCKED (on object monitor) 
    at com.moi.DefaultImageProcessor$DownloadAndScaleCallable.call(
      DefaultImageProcessor.java:168) 
    - waiting to lock <0x257aa440> 
    (com.moi.ImageUriMutexImpl$MutexImpl) 
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
     ThreadPoolExecutor.java:885) 

"pool-2-thread-10" prio=6 tid=0x01d51000 nid=0x18d0 
waiting for monitor entry [0x05e1f000..0x05e1fd68] 
java.lang.Thread.State: BLOCKED (on object monitor) 
    at com.moi.DefaultImageProcessor$DownloadAndScaleCallable.call(
      DefaultImageProcessor.java:168) 
    - waiting to lock <0x257aa6b8> 
    (com.moi.ImageUriMutexImpl$MutexImpl) 
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
     ThreadPoolExecutor.java:885) 

이 스택 덤프를 읽는 방법을 알고 싶습니다. 교착 상태에서 어떤 표지판을 찾아야합니까?

업데이트 내 문제가 해결되었습니다. 기본적으로 동기화 된 블록 내에서 HttpClient 4.0 GET을 수행하고 있습니다. HttpClient가 잘못 작동하여 &이 잠금 장치에 보관 된 &을 반환하지 않았습니다. jstack을 통해, 위의 문제를 일으키는 자물쇠를 잡고있는 두 개의 실이있었습니다. 교착 상태가 너무 많지는 않지만 이제는 동기화 된 블록이 너무 오래 돌아가고 있다는 것을 알았습니다.

Answer 1

작은 스택 추적에서 스레드는 잠금 획득만을 기다리고 있습니다. 추적에서 개체 0x257aa440 및 0x257aa6b8을 찾아 누가 해당 개체를 잠 갔는지 확인하십시오. 해당 스레드가 차단되었는지 확인하십시오.

교착 상태에있는 경우 차단 된 상태의 완전한 원이 표시됩니다. 또한 차단 상태가 일시적인지 또는 긴 대기인지 확인하기 위해 추적을 여러 번 수행하십시오.

Answer 2

이 명령 "중지"고 알았어 야 감안할 때, 당신은 뮤텍스에 차단 된 두 개의 스레드를 확인했다 ... 난 정말

그것을 ... 당신은 꽤 잘 표지판을 읽고 말하고 싶지만 귀하의 서비스가 무엇을 하느냐에 달려 있습니다. 성능 문제 및 데이터 일관성 문제를 찾으십시오. 예를 들어 응답이 없거나 응답이 없거나 요청 량이 많아 질수록 성능이 저하 될 수 있다는 좋은 징후가 있습니다. 또한 여러 요청 간의 불일치 데이터 (다시 서비스에 따라 다름)도 문제를 지적 할 수 있습니다.

Answer 3

이들은 동일한 자원에 대해 경합하는 두 개의 스레드이므로, iself에는 아무 것도 문제가되지 않습니다. 그것은 문제의 절반일지도 모르다.

두 스레드가 차단 된 경우 교착 상태가 아닙니다. (이것은 단순한 형태의에서) 두 개의 스레드가 각각 이미 두 개의 서로 다른 객체에 대한 잠금을 가지고 있지만 각각 다른 하나에 대한 잠금을 원하는 위치에 교착 상태입니다.

그냥 당신이 제공 한 것과, 아니 당신이 교착 상태에 아니에요 말했다. 일이 걸려, 그리고 시작하는 경우 그러나 그것은 좋은 가능성,하지만 그것은 단지 스택 덤프에서 확실히 말해 (매우 하드이어야 이상) 불가능, 백업하세요.

편집 : 잠깐, 같은 일에 잠겨 있지 않습니다. 그러나 두 스레드는 같은 기능을합니다. 나는 그것이 가능성이 (단독) 하나의 원인이 될 것이라는 점을 찾을 것입니다,하지만 교착 상태의 원인이 스레드의 루프의 일부 있었다.

Answer 4

A (기존의) 교착 상태가 jstack로 자리하기 쉬운 - 그것은 교착 상태가 말할 것이다. (예를 들어, 스레드가 서로를 기다리고 있지만 서로를 기다리는 등의 경우가있을 수 있습니다.

두 개의 스레드가 서로 다른 객체를 잠그려고 시도하는 블록입니다 (ID 해시 코드 0x257aa440 및 0x257aa440).실제로 이러한 잠금을 유지하는 다른 스레드를 찾을 수 있습니다 (텍스트 편집기에서 find를 사용하면됩니다). 모니터가 출시되기 직전에 출시되어 개최되지 않은 경우 일 수 있습니다. 이 경우에 당신은 아마도 매우 다가간 자물쇠를 볼 것입니다.

Answer 5

this question을 살펴보십시오.

"Thread-1" prio=10 tid=0x0841ac00 nid=0x77d waiting for monitor entry [0xb42bf000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at Deadlock$Friend.bowBack(Deadlock.java:16) 
    - waiting to lock <0x8b80def8> (a Deadlock$Friend) 
    at Deadlock$Friend.bow(Deadlock.java:13) 
    - locked <0x8b80df08> (a Deadlock$Friend) 
    at Deadlock$2.run(Deadlock.java:28) 
    at java.lang.Thread.run(Thread.java:619) 

"Thread-0" prio=10 tid=0x08419400 nid=0x77c waiting for monitor entry [0xb4310000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at Deadlock$Friend.bowBack(Deadlock.java:16) 
    - waiting to lock <0x8b80df08> (a Deadlock$Friend) 
    at Deadlock$Friend.bow(Deadlock.java:13) 
    - locked <0x8b80def8> (a Deadlock$Friend) 
    at Deadlock$1.run(Deadlock.java:25) 
    at java.lang.Thread.run(Thread.java:619) 



Found one Java-level deadlock: 
============================= 
"Thread-1": 
    waiting to lock monitor 0x083f1464 (object 0x8b80def8, a Deadlock$Friend), 
    which is held by "Thread-0" 
"Thread-0": 
    waiting to lock monitor 0x083efc90 (object 0x8b80df08, a Deadlock$Friend), 
    which is held by "Thread-1" 

Java stack information for the threads listed above: 
=================================================== 
"Thread-1": 
    at Deadlock$Friend.bowBack(Deadlock.java:16) 
    - waiting to lock <0x8b80def8> (a Deadlock$Friend) 
    at Deadlock$Friend.bow(Deadlock.java:13) 
    - locked <0x8b80df08> (a Deadlock$Friend) 
    at Deadlock$2.run(Deadlock.java:28) 
    at java.lang.Thread.run(Thread.java:619) 
"Thread-0": 
    at Deadlock$Friend.bowBack(Deadlock.java:16) 
    - waiting to lock <0x8b80df08> (a Deadlock$Friend) 
    at Deadlock$Friend.bow(Deadlock.java:13) 
    - locked <0x8b80def8> (a Deadlock$Friend) 
    at Deadlock$1.run(Deadlock.java:25) 
    at java.lang.Thread.run(Thread.java:619) 

Found 1 deadlock. 

당신이 손에 교착 상태가 때, VM을 감지하고 표시 할 수 있습니다 :이 생성 할 수있는 스택 트레이스의 발췌 한 것입니다.