여러 스레드가 네이티브 호출에 걸림 (Java)

Question

JDK 1.5.0_08이 적용된 Fedora Core 6에서 실행되는 응용 프로그램에 문제가 있습니다.

가동 시간 중 일부 (보통 며칠간)가 원시 메소드에서 멈추기 시작한 후에.

스레드

는 다음과 같이 뭔가에 고정되어 VM의 때까지 갇혀 남아

"HealthMonitor-10" daemon prio=1 tid=0x0868d1c0 nid=0x2b72 waiting for monitor entry [0xbe5ff000..0xbe5ff4d4] 
at java.lang.Thread.dumpThreads(Native Method) 
at java.lang.Thread.getStackTrace(Thread.java:1383) 

스레드 :

"pool-2-thread-2571" prio=1 tid=0x08dd0b28 nid=0x319e waiting for monitor entry [0xb91fe000..0xb91ff7d4] 
at java.lang.Class.getDeclaredConstructors0(Native Method) 

또는

"pool-2-thread-2547" prio=1 tid=0x75641620 nid=0x1745 waiting for monitor entry [0xbc7fe000..0xbc7ff554] 
at sun.misc.Unsafe.defineClass(Native Method) 

특히 나에게 수수께끼

이 하나입니다 다시 시작됩니다.

아무도 내게 무슨 일이 일어나고 있는지, 네이티브 메소드가 차단할 수있는 원인을 알려 줄 수 있습니까? 각 고정 스레드의 맨 위에있는 모니터 항목 주소 범위가 다릅니다. 이 모니터를 보유하고있는 것이 무엇인지 어떻게 알 수 있습니까?

모든 제안이나 조언을 부탁드립니다!

덕분에, 데이비드

Answer 1

은 아마 당신은 다른 JDK 버전을 사용해야합니다.
"수수께끼 하나"의 경우 1.5.0_08에 대한 버그 항목이 있습니다. 메모리 누수가 (이이 문제에 관련이 있는지 나는 모른다)보고됩니다
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469701

은 또한 소스 코드를 얻을 볼 수 있었다, 다른 측면에서 라인 1383.에서 무슨 일이 수 원래 오류가 발생한 후에 스택 덤프가됩니다.

Answer 2

처음에는 내 생각 엔 당신이 어떤 종류의 클래스 로더가 deadlock을 리얼하게 경험하고있을 것입니다. 클래스 정보는 처음로드 된 스레드뿐만 아니라 전체 VM에서 사용할 수 있기 때문에 일부 클래스에서는 클래스 로딩을 동기화해야한다고 생각합니다.

스택 맨 위에있는 메서드가 기본 메서드라는 사실은 클래스 로딩 메커니즘의 일부가 그런 식으로 구현되기 때문에 순수한 우연한 것처럼 보입니다.

나는 클래스 로딩 현명한 작업에 대해 더 자세히 조사 할 것이다. 어쩌면 일부 스레드는 클래스 로더를 사용하여 속도가 느리고 사용할 수없는 네트워크 위치에서 클래스를로드하므로 클래스를로드하려는 다른 스레드로 모니터를 전송하지 않고 실제로 오랜 시간 동안 차단합니다. -verbose : class를 사용하여 JVM을 시작할 때 출력을 조사하면 시도 할 수있는 한 가지 일 수 있습니다.

Answer 3

몇 달 전에 비슷한 문제가 있었는데 jthread (?) 유틸리티가 매우 유용하다는 것을 알았습니다. Java 응용 프로그램의 프로세스 ID를 지정하면 프로세스의 각 스레드에 대해 전체 스택을 덤프합니다.

jthread의 출력에서 ​​하나의 스레드가 모니터에 들어간 후에 잠금을 얻으려고하고 다른 스레드가 잠금을 획득 한 후 모니터에 들어가려고한다는 것을 알 수있었습니다. 교착 상태에 대한 처방.

응용 프로그램이 가비지 수집 문제로 실행되고 있는지 궁금합니다. 너는 그것이 이렇게 멈추기 전에 그것이 며칠 동안 달린다 고 말한다.어쩌면 GC가 끝났는지 확인하기 위해 얼마나 오래 붙어있는 상태에있게 했습니까?

Answer 4

네이티브 메소드가 대기중인 모니터에서 실제로 어떤 스레드가 동기화되고 있는지 확인할 수 있습니까? 당신은 당신이 그것에게 SIGQUIT를 보낼 때 VM에서 얻을 적어도 스레드 덤프 (죽일 -3)이 정보를 표시해야합니다, 당신은 지금까지 게시 한 덤프에서

"Thread-0" prio=5 tid=0x0100b060 nid=0x84c000 waiting for monitor entry [0xb0c8a000..0xb0c8ad90] 
    at Deadlock$1.run(Deadlock.java:8) 
    - waiting to lock <0x255e5b38> (a java.lang.Object) 
... 
"main" prio=5 tid=0x01001350 nid=0xb0801000 waiting on condition [0xb07ff000..0xb0800148] 
    at java.lang.Thread.sleep(Native Method) 
    at Deadlock.main(Deadlock.java:21) 
- locked <0x255e5b38> (a java.lang.Object) 

같이 내가 할 수있는 ' 특정 모니터를 잠그기 위해 실제로 대기중인 스레드를 보지 마십시오 ...

Answer 5

같은 문제 (Tomcat 6.0.29가 설치된 Linux에서 실행되는 JDK 1.6.0_23)를 치고 나서이 스레드를 발견했습니다. 그 비트가 관련이 있는지 모르지만 - 내가 알아챈 것은 많은 스레드가 getDeclaredConstructors() 네이티브 메소드에 "붙어있는"것을 제외하고는 CPU가 Java 프로세스에서 100 %였습니다. 그래서 모든 요청 스레드가 여기서 멈추고, CPU가 100 %에 이르며, 스레드 덤프가 교착 상태를 보이지 않고 (중요한 작업을 수행하는 다른 스레드가 없음) 나에게 쓰레기 수집기와 같은 냄새가났다. 물론 충분히, 서버 로그를 검사하고 많은 OutOfMemory 오류가있었습니다 - 힙 공간이 모두 소모되었습니다.

는