Java 로더에 대한 심층적인 이해

1. 클래스 및 클래스 로더

클래스 로더: 로딩 단계를 구현하는 첫 번째 단계, 클래스의 정규화된 이름을 사용하여 이 클래스의 바이너리 바이트 스트림을 jvm에 로드합니다.

클래스 및 클래스 로더: 클래스의 고유성은 클래스 자체와 이를 로드하는 클래스 로더에 의해 결정됩니다. 두 클래스가 동일한지 여부는 해당 클래스가 동일한 클래스 로더에 의해 로드된다는 전제에 따라 다릅니다. .

jvm 가상 머신에는 두 개의 클래스 로더가 포함되어 있습니다. 하나는 C++로 구현되는 시작 클래스 로더(Bootstrap ClassLoader)이고, 다른 하나는 Java 장치에서 구현되는 다른 모든 클래스 로더입니다.

Java 프로그램 관점에서:

1) 클래스 로더 시작: lib 디렉토리 또는 -Xbootclasspath에 의해 지정된 경로에서 클래스를 로드하는 역할을 담당합니다. 또한, 파일 이름은 가상 머신에서 인식되어야 하며, jvm에서 인식되지 않으면 로드할 수 없습니다.

2) 확장 클래스 로더: libexit 디렉토리 또는 java.exit.dirs 시스템 변수에 지정된 경로에 있는 모든 클래스 라이브러리를 로드하는 역할을 담당합니다.

3) 애플리케이션 클래스 로더(시스템 클래스 로더): Classloader의 getSystemClassloader() 메소드의 반환 값입니다. 사용자 클래스 경로에 지정된 클래스 라이브러리를 로드하는 역할을 담당합니다. 애플리케이션에 사용자 정의 클래스 로더가 없으면 이것이 프로그램의 기본 클래스 로더가 됩니다.

무료 온라인 비디오 교육: java 비디오 튜토리얼

2. 부모 위임 모델

# 🎜🎜#

최상위 시작 클래스 로더를 제외하고 다른 모든 클래스 로더에는 자체 상위 클래스 로더가 있습니다. 부모-자식 관계는 상속을 통해 구현되지 않고 부모 클래스 로더를 재사용하기 위한 조합 관계를 통해 구현됩니다.

작업 프로세스: 클래스 로더가 클래스 로딩 요청을 수신합니다. –> 상위 클래스 로더에 요청을 위임합니다(최상위 클래스 로더가 시작될 때까지) –> 및 로드 실패 피드백 서브클래스 로더 제공 –> 서브클래스 로더가 로드를 시도합니다

상위 위임 모델의 이점: 기본 Java API의 안정성을 보장하고 기본 클래스와 동일한 이름(Object) 동일한 이름을 가진 서로 다른 클래스(Object)가 여러 개 나타나 Java의 기본 동작에 혼란을 야기합니다.

부모 위임 모델 소스 코드:

이 메서드는 스레드 안전을 보장하기 위해 동기화 잠금을 추가합니다. 먼저 클래스가 로드되었는지 확인하세요. 그렇지 않은 경우 상위 클래스 로더의 loadClass() 메서드를 호출합니다. 상위 클래스 로더가 비어 있으면 시작 클래스 로더가 호출된 다음 시작 클래스 로더가 호출된다는 의미입니다.

부모 클래스가 로드되지 않으면 ClassNotFoundException이 발생하고 findClass() 메서드를 호출하여 로드합니다.

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    //同步锁
    synchronized (getClassLoadingLock(name)) {
        // 首先检车这个类是不是已被加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    //如果父类不为空则调用父类加载器的loadClass方法
                    c = parent.loadClass(name, false);
                } else {
                    //没有父类则默认调用启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                //如果父类加载器找不到这个类则抛出ClassNotFoundException
            }


            if (c == null) {
                // 父类加载器失败时调用自身的findClass方法加载
                long t1 = System.nanoTime();
                c = findClass(name);


                //记录
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

3. 부모 위임 모델의 파괴

1. 첫 번째 파괴 # 🎜🎜#부모 위임 모델은 JDK1.2 이후에 등장했지만 클래스 로더와 추상 클래스 java.lang.ClassLoader는 이미 존재했습니다.

따라서 향후 호환성을 위해 JDK1.2 이후 ClassLoader에 새로운 보호 메서드 findClass가 추가되었습니다. 사용자는 사용자 정의 클래스 로딩이 상위 위임 모델을 준수하는지 확인하기 위해 loadClass 메서드를 재정의하는 대신 findClass 메서드에 고유한 클래스 로딩 논리를 작성합니다.

2. 2차 파괴

모델 자체에 결함이 있습니다. 상위 위임은 각 클래스 로더의 기본 클래스의 통일을 보장할 수 있습니다. 이는 사용자 코드가 기본 클래스를 호출하는 경우입니다. 이는 기본 클래스가 사용자 코드를 다시 호출하는 경우에는 적용되지 않습니다. 예를 들어 SPI와 관련된 시나리오에서는 필요한 SPI 코드를 로드합니다.

SPI 메커니즘에 대한 소개는 다른 글을 참고해주세요.

이 문제를 해결하기 위해 스레드 컨텍스트 로더(Thread Context ClassLoader)가 도입되었습니다. 이 클래스 로더는 java.lang.Thread 클래스의 setContextClassLoader() 메서드를 통해 설정할 수 있습니다. 스레드가 생성됩니다. 설정하지 않으면 상위 스레드에서 상속됩니다. 전역 클래스 로더가 없으면 기본적으로 애플리케이션 클래스 로더를 사용하여 하위 스레드를 요청하는 상위 클래스 로더의 작업을 완료할 수 있습니다. 로드할 클래스 로더.

3. 세 번째 피해

는 핫 배포, 핫 교체 등 프로그램 역학 추구로 인해 발생합니다.

예를 들어, 모듈 표준 OSGi R4.2는 부모 위임의 트리 구조를 보다 복잡한 네트워크 구조로 변경합니다.

java 기사 튜토리얼 추천:

java 입문 튜토리얼

위 내용은 Java 로더에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!