Java 클래스 로딩 메커니즘

저는 Java의 클래스 로딩 메커니즘이 이해하기 너무 어렵다고 생각해서 오랫동안 거부감을 느꼈습니다. 하지만 좋은 Java 엔지니어가 되기 위해, 나는 열심히 공부하기로 결정했습니다.

01, Bytecode

Java 클래스 로딩 메커니즘에 대해 이야기하기 전에 먼저 Java 바이트코드를 이해해야 합니다. 왜냐하면 Java 클래스 로딩 메커니즘과 밀접한 관련이 있기 때문입니다.

컴퓨터는 0과 1만 이해하므로 어떤 언어로든 작성된 프로그램은 컴퓨터에서 이해하고 실행하려면 기계어 코드로 컴파일해야 하며, Java도 예외는 아닙니다.

Java는 탄생 당시 "Write Once, Run Anywhere"라는 매우 멋진 슬로건을 외쳤습니다. 이 목표를 달성하기 위해 Sun은 다양한 플랫폼(Windows, Linux)(JVM)에서 실행될 수 있는 많은 Java 가상 머신을 출시했습니다. Java 컴파일 바이트코드 로드 및 실행을 담당합니다.

Java 바이트코드는 어떻게 생겼나요? 간단한 코드를 통해 살펴보겠습니다.

소스코드는 다음과 같습니다.

package com.cmower.java_demo;

public class Test {

    public static void main(String[] args) {
        System.out.println("版权声明");
    }

}

코드 컴파일 후 xxd Test.class 명령어를 통해 바이트코드 파일을 확인합니다.

xxd Test.class
00000000: cafe babe 0000 0034 0022 0700 0201 0019  .......4."......
00000010: 636f 6d2f 636d 6f77 6572 2f6a 6176 615f  com/cmower/java_
00000020: 6465 6d6f 2f54 6573 7407 0004 0100 106a  demo/Test......j
00000030: 6176 612f 6c61 6e67 2f4f 626a 6563 7401  ava/lang/Object.
00000040: 0006 3c69 6e69 743e 0100 0328 2956 0100  ..<init>...()V..
00000050: 0443 6f64 650a 0003 0009 0c00 0500 0601  .Code...........
00000060: 000f 4c69 6e65 4e75 6d62 6572 5461 626c  ..LineNumberTabl

좀 당황스럽죠?

맞습니다.

이 바이트코드의 카페 베이비는 "매직 넘버"라고 불리며, 이는 JVM이 .class 파일을 인식한다는 표시입니다. 파일 형식의 사용자 정의자는 매직 넘버를 자유롭게 선택할 수 있습니다(사용되지 않는 한). 예를 들어 .png 파일의 매직 넘버는 8950 4e47입니다.

다른 콘텐츠는 삭제하도록 선택할 수 있습니다.

02. 클래스 로딩 과정

Java 바이트코드를 이해한 후, Java의 클래스 로딩 과정에 대해 이야기해보겠습니다.

Java의 클래스 로딩 프로세스는 로딩, 검증, 준비, 구문 분석 및 초기화의 5단계로 나눌 수 있습니다. 이 5단계는 일반적으로 순차적으로 발생하지만 동적 바인딩의 경우 초기화 단계 이후에 구문 분석 단계가 발생합니다.

1) 로드

이 단계에서 JVM의 주요 목적은 다양한 데이터 소스(클래스 파일, jar 패키지 또는 네트워크)의 바이트코드를 메모리에 로드하기 위해 바이너리 바이트 스트림으로 변환하고 java.lang을 생성하는 것입니다. 클래스를 나타내는 클래스 객체입니다.

2) 검증

JVM은 이 단계에서 바이너리 바이트 스트림을 검증합니다. JVM 바이트코드 사양을 준수하는 것만 JVM에서 올바르게 실행될 수 있습니다. 이 단계는 JVM의 보안을 보장하는 중요한 장벽입니다. 다음은 몇 가지 주요 점검 사항입니다.

바이너리 바이트 스트림 형식이 예상한 것과 같은지 확인하세요(예: Cafe bene으로 시작).

모든 메소드가 액세스 제어 키워드 제한 사항을 준수하는지 여부.

메서드 호출의 매개변수 개수와 유형이 올바른지 여부.

사용하기 전에 변수가 올바르게 초기화되었는지 확인하세요.

변수에 적절한 유형의 값이 할당되었는지 확인하세요.

3) 준비

JVM은 이 단계에서 메모리를 할당하고 클래스 변수(정적 변수라고도 하며 static 키워드로 수정됨)를 초기화합니다(0, 0L, null과 같은 데이터 유형의 기본 초기 값에 해당). 거짓 등).

즉, 다음과 같은 코드가 있는 경우:

public String chenmo = "沉默";
public static String wanger = "王二";
public static final String cmower = "沉默王二";

chenmo는 메모리를 할당하지 않지만 Wanger는 할당하지만 Wanger의 초기 값은 "王二"가 아니라 null입니다.

정적 final에 의해 수정된 변수를 상수라고 부르며 클래스 변수와는 다르다는 점에 유의해야 합니다. 상수에 값이 할당되면 변경되지 않으므로 준비 단계의 cpower 값은 null 대신 "silent king two"입니다.

4) 해결

이 단계에서는 상수 풀의 기호 참조를 직접 참조로 변환합니다.

뭐? 상징적 참조, 직접 참조?

기호 참조는 참조된 대상을 설명하기 위해 일련의 기호(사용 시 대상을 명확하게 찾을 수 있는 한 모든 형태의 리터럴)를 사용합니다.

컴파일 시 Java 클래스는 참조된 클래스의 실제 주소를 모르므로 대신 기호 참조만 사용할 수 있습니다. 예를 들어, com.Wanger 클래스는 com.Chenmo 클래스를 참조합니다. 컴파일 시 Wanger 클래스는 Chenmo 클래스의 실제 메모리 주소를 알지 못하므로 com.Chenmo 기호만 사용할 수 있습니다.

직접 참조는 기호 참조를 구문 분석하여 참조의 실제 메모리 주소를 찾습니다.

5) 초기화

이 단계는 클래스 로딩 프로세스의 마지막 단계입니다. 준비 단계에서는 클래스 변수에 기본 초기값이 할당되고, 초기화 단계에서는 클래스 변수에 코드에서 예상하는 값이 할당됩니다. 즉, 초기화 단계는 클래스 생성자 메서드를 실행하는 과정입니다.

아뇨, 위 문단은 매우 추상적이고 이해하기 어렵죠? 예를 들어보겠습니다.

String cpower = new String("Silent Wang Er");

위 코드는 new 키워드를 사용하여 문자열 객체를 인스턴스화한 다음, 이때 String 클래스의 생성자가 호출되어 cpower 변경을 인스턴스화합니다.

03. 클래스 로더

클래스 로딩 과정에 대해 이야기한 후에는 클래스 로더에 대해 이야기해야 합니다.

一般来说，Java 程序员并不需要直接同类加载器进行交互。JVM 默认的行为就已经足够满足大多数情况的需求了。不过，如果遇到了需要和类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就不得不花大量的时间去调试

ClassNotFoundException 和 NoClassDefFoundError 等异常。

对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在 JVM 中的唯一性。也就是说，如果两个类的加载器不同，即使两个类来源于同一个字节码文件，那这两个类就必定不相等（比如两个类的 Class 对象不 equals）。

站在程序员的角度来看，Java 类加载器可以分为三种。

1）启动类加载器（Bootstrap Class-Loader），加载 jre/lib 包下面的 jar 文件，比如说常见的 rt.jar。

2）扩展类加载器（Extension or Ext Class-Loader），加载 jre/lib/ext 包下面的 jar 文件。

3）应用类加载器（Application or App Clas-Loader），根据程序的类路径（classpath）来加载 Java 类。

来来来，通过一段简单的代码了解下。

public class Test {

	public static void main(String[] args) {
		ClassLoader loader = Test.class.getClassLoader();
		while (loader != null) {
			System.out.println(loader.toString());
			loader = loader.getParent();
		}
	}

}

每个 Java 类都维护着一个指向定义它的类加载器的引用，通过 类名.class.getClassLoader() 可以获取到此引用；然后通过 loader.getParent() 可以获取类加载器的上层类加载器。

这段代码的输出结果如下：

sun.misc.Launcher$AppClassLoader@73d16e93
sun.misc.Launcher$ExtClassLoader@15db9742

第一行输出为 Test 的类加载器，即应用类加载器，它是 sun.misc.Launcher$AppClassLoader 类的实例；第二行输出为扩展类加载器，是 sun.misc.Launcher$ExtClassLoader 类的实例。那启动类加载器呢？

按理说，扩展类加载器的上层类加载器是启动类加载器，但在我这个版本的 JDK 中， 扩展类加载器的 getParent() 返回 null。所以没有输出。

04、双亲委派模型

如果以上三种类加载器不能满足要求的话，程序员还可以自定义类加载器（继承 java.lang.ClassLoader 类），它们之间的层级关系如下图所示。

这种层次关系被称作为双亲委派模型：如果一个类加载器收到了加载类的请求，它会先把请求委托给上层加载器去完成，上层加载器又会委托上上层加载器，一直到最顶层的类加载器；如果上层加载器无法完成类的加载工作时，当前类加载器才会尝试自己去加载这个类。

PS：双亲委派模型突然让我联想到朱元璋同志，这个同志当上了皇帝之后连宰相都不要了，所有的事情都亲力亲为，只有自己没精力没时间做的事才交给大臣们去干。

使用双亲委派模型有一个很明显的好处，那就是 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系，这对于保证 Java 程序的稳定运作很重要。

上文中曾提到，如果两个类的加载器不同，即使两个类来源于同一个字节码文件，那这两个类就必定不相等——双亲委派模型能够保证同一个类最终会被特定的类加载器加载。

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