Java 클래스 로딩 프로세스

Java 클래스 로딩 프로세스

첫 번째는 로딩(Loading)으로, Java가 다양한 데이터 소스의 바이트코드 데이터를 JVM으로 읽어와 JVM이 인식하는 데이터 구조(클래스 객체)에 매핑하는 것입니다. ), 여기의 데이터 소스는 jar 파일, 클래스 파일 또는 네트워크 데이터 소스와 같은 다양한 형식일 수 있습니다. 입력 데이터가 ClassFile 구조가 아닌 경우 ClassFormatError가 발생합니다. 로딩 단계는 사용자가 참여하는 단계입니다. 클래스 로더를 사용자 정의하여 자체 클래스 로딩 프로세스를 구현할 수 있습니다.

두 번째 단계는 Linking인데, 간단히 말하면 원래의 클래스 정의 정보를 JVM 실행 프로세스로 원활하게 전달하는 단계입니다. 이는 세 단계로 더 세분화될 수 있습니다. 1. 가상 머신 보안을 위한 중요한 보장인 확인 JVM은 바이트 정보가 Java 가상 머신 사양을 준수하는지 확인해야 합니다. 그렇지 않으면 VerifyError로 간주됩니다. 방지 악의적인 정보나 비준수 정보가 JVM의 작동에 해를 끼치는 경우 확인 단계에서 더 많은 클래스 로드가 트리거될 수 있습니다. 2. 준비(Pereparation), 클래스나 인터페이스에 정적 변수를 생성하고 정적 변수의 초기값을 초기화합니다. 그러나 여기의 "초기화"와 아래의 디스플레이 초기화 단계 사이에는 차이가 있습니다. 초점은 필요한 메모리 공간을 할당하는 데 있으며 추가 JVM 명령을 실행하지 않습니다. 3. 해결 이 단계에서는 상수 풀의 기호 참조가 직접 참조로 대체됩니다. Java Virtual Machine 사양에는 클래스, 인터페이스, 메소드, 필드 등 다양한 측면에 대한 분석이 자세히 소개되어 있습니다.

마지막 단계는 초기화 단계(초기화)입니다. 이 단계에서는 정적 필드 할당 작업과 클래스 정의의 정적 초기화 블록에 있는 논리 실행을 포함하여 클래스 초기화의 코드 논리를 실제로 실행합니다. 컴파일 단계에서 이를 사용합니다. 논리의 일부가 정렬되고 상위 유형의 초기화 논리가 현재 유형의 논리보다 우선합니다. 간단히 말해서, 로더(클래스 로더)가 특정 유형을 로드하려고 할 때, 상위 클래스 로더가 해당 유형을 찾을 수 없는 한 현재 로더의 상위에 작업을 위임하려고 시도하는 모델에 대해 이야기해 보겠습니다. 이를 수행하는 도구입니다. 위임 모델을 사용하는 목적은 Java 유형의 반복 로드를 방지하는 것입니다.

사용자 정의 클래스 로더의 일반적인 시나리오

유사한 프로세스 내 격리를 달성하기 위해 클래스 로더는 실제로 다른 네임스페이스로 사용되며 컨테이너와 같은 모듈식 효과를 제공합니다. 예를 들면 다음과 같습니다. 1. 두 모듈은 특정 클래스 라이브러리의 서로 다른 버전에 의존합니다. 서로 다른 컨테이너에 의해 로드되면 서로 간섭하지 않습니다. 이 분야의 마스터는 Java EE 및 OSGL, JPMS 및 기타 프레임워크입니다. 2. 애플리케이션은 로컬 파일 시스템 대신 네트워크 데이터 소스와 같은 다양한 데이터 소스에서 클래스 정의 정보를 얻어야 합니다. 3. 또는 바이트코드를 직접 조작하고 생성된 유형을 동적으로 수정해야 합니다.

일반적으로 사용자 정의 클래스 로딩 프로세스를 간단히 이해할 수 있습니다. 1. 이름을 지정하여 바이너리 구현을 찾습니다. 이는 종종 사용자 정의 클래스 로더가 "사용자 정의"하는 부분입니다. 예를 들어 이름을 기반으로 단어를 가져옵니다. 특정 데이터 소스를 섹션 코드로 지정하거나 바이트코드를 수정 또는 생성합니다. 2. 그런 다음 Class 객체를 생성하고 클래스 로딩 프로세스를 완료합니다. 바이너리 정보를 클래스 객체로 변환하는 것은 대개 정의 클래스에 의존합니다. 이는 최종 메소드입니다. Class 객체를 사용하면 후속 로딩 프로세스가 원활하게 완료됩니다.

추천 튜토리얼: "Java Tutorial"

위 내용은 Java 클래스 로딩 프로세스의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!