[java] 스레드의 컨텍스트 클래스 로더와 일반 클래스 로더의 차이점

이것은 원래 질문에 대답하지 않지만 질문의 순위가 높고 ContextClassLoader쿼리에 연결되어 있으므로 컨텍스트 클래스 로더를 사용해야하는 시점과 관련된 질문에 대답하는 것이 중요하다고 생각합니다. 짧은 대답 : 컨텍스트 클래스 로더를 사용하지 마십시오 ! 그러나 매개 변수 getClass().getClassLoader()가없는 메소드를 호출 해야 할 때 설정하십시오 ClassLoader.

한 클래스의 코드가 다른 클래스를로드하도록 요청하면 사용할 올바른 클래스 로더는 호출자 클래스와 동일한 클래스 로더입니다 (예 🙂 getClass().getClassLoader(). 99.9 %의 시간 이 작동하는 방식 입니다. 새 클래스의 인스턴스를 처음 구성하거나 정적 메소드를 호출하거나 정적 필드에 액세스 할 때 JVM 자체 가 수행하는 방식이기 때문 입니다.

리플렉션을 사용하여 클래스를 만들려면 (예 : 구성 가능한 명명 된 클래스를 역 직렬화 또는로드 할 때) 리플렉션을 수행하는 라이브러리는 항상 응용 프로그램ClassLoader 에서 매개 변수 로을 수신하여 사용할 클래스 로더를 응용 프로그램에 요청 해야 합니다. 응용 프로그램 (생성해야하는 모든 클래스를 알고 있음)이 전달해야합니다 getClass().getClassLoader().

클래스 로더를 얻는 다른 방법은 올바르지 않습니다. 라이브러리가 Thread.getContextClassLoader(), 등의 해킹을 사용 sun.misc.VM.latestUserDefinedLoader()하거나 sun.reflect.Reflection.getCallerClass()API의 결함으로 인한 버그 인 경우 기본적으로 API를 Thread.getContextClassLoader()디자인 한 사람 이 매개 변수로 사용하는 ObjectInputStream것을 잊어 버렸기 때문에 존재 하며이 ClassLoader실수는 오늘날까지 Java 커뮤니티를 괴롭 혔습니다.

즉, 많은 JDK 클래스는 몇 가지 해킹 중 하나를 사용하여 사용할 클래스 로더를 추측합니다. 일부는 ContextClassLoader(공유 스레드 풀에서 다른 앱을 실행할 때 실패하거나을 떠날 ContextClassLoader null때 실패) 일부는 스택을 걷습니다 (클래스의 직접 호출자가 라이브러리 인 경우 실패). 일부는 시스템 클래스 로더를 사용합니다 ( CLASSPATH또는 클래스의 부트 스트랩 클래스 로더 만 사용하도록 문서화되어있는 한 괜찮습니다. ) 일부는 예측할 수없는 위의 기술 조합을 사용하여 혼란을 야기합니다. 이로 인해 치아가 많이 울리고 찢어졌습니다.

이러한 API를 사용할 때는 먼저 클래스 로더를 매개 변수로 허용하는 메소드의 과부하를 찾으십시오 . 합리적인 방법이없는 경우 ContextClassLoaderAPI 호출 전을 설정 한 후 나중에 재설정하십시오.

ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
    // call some API that uses reflection without taking ClassLoader param
} finally {
    Thread.currentThread().setContextClassLoader(originalClassLoader);
}

답변