중단 된 스레드 java.lang.ClassLoader.findBootstrapClass

Question

내 J2EE 응용 프로그램의 속도가 느립니다. 우리는 그 상황에서 Thead 덤프를 가져 와서 다음 스레드가 다중 덤프에서 Runnable이고 다른 스레드가 (직접 또는 간접적으로) 잠금을 기다리는 일부 모니터를 잠갔습니다.

at java.lang.ClassLoader.findBootstrapClass(Native Method) 
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:301) 
    - locked [0x9747c360] (a sun.misc.Launcher$ExtClassLoader) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:299) 
    - locked [0x9747c318] (a sun.misc.Launcher$AppClassLoader) 
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) 
    - locked [0x9747c318] (a sun.misc.Launcher$AppClassLoader) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:251) 
..... 

이 스레드가 움직이지 않고 다른 스레드가 작동하도록 하시겠습니까?

Answer 1

앱에로드하는 클래스가 너무 많습니다 (잠금이 loadClass에있는 이유는 무엇입니까?). 앱이 초기화 및 예열 중에 만 언로드 된 클래스를로드 할 것으로 예상됩니다.

• 당신은 대신 재사용하기 위해 노력하는 다른 동적 프록시 클래스를 많이 만들 :

  그래서, 다음 중 하나가 일어나고 있다고 생각한다.

• 불필요하게 많은 ClassLoader를 만들거나 적어도이를 잘못 사용하고 있습니다.
• 여러 개의 병렬 JVM을 시작하고 종료합니다.

물론 이러한 것들은 매우 비싸므로 가능한 한 최대로 피해야합니다.

Answer 2

이 스레드가 일시 중지 된 경우 무기한으로 원형 참조 (symlinks? other?)를 추측 할 수 있습니다.

로드 된 클래스에 대한 로깅을 사용하도록 설정하면 더 많은 정보를 찾을 수 있습니다.

java -verbose:class your.Class 

이것은 많은 것을 보여줍니다. 나는 그것이 system.out에 쓸 것이라고 믿는다. 그래서 당신은 적절한 로그를 체크해야 할 것이다.

Answer 3

이런 종류의 일은 OSGI에서 발생합니다. OSGI에서는 클래스 로더 구조가 일반적인 J2EE처럼 트리가 아닌 그래프입니다. 클래스 로더는 클래스를로드 할 때 스스로 잠그므로 클래스 로더의 클래스를 두 개의 스레드 (a, b)가 각각 (x, y)와 (y, x)의 순서로로드하면 교착 상태가 될 수 있습니다. 이것은 정적 이니셜 라이저가 다른 클래스 로더에서 더 많은 클래스 로딩을 유발할 때 발생할 수 있습니다. 부트 스트랩 클래스가 app 클래스 로더의 클래스 로딩을 자주하는 것은 아니지만 스레드 컨텍스트 로더를 사용하는 표준 라이브러리의 모든 팩토리 클래스가이 계산서에 적합합니다. 일반적인 해결책은 아마도 앱 시작 중에 클래스를로드하여 이전 시점에로드하는 것이므로주기를 깨뜨리는 것입니다.