Java Class Loader | W3Docs Learn Java

Bevor die JVM eine einzige Zeile Ihres Codes ausführen kann, muss sie die .class-Datei finden, ihren Bytecode lesen, verifizieren und in ein lebendes Class-Objekt im Speicher umwandeln. Diese Aufgabe gehört einem Class Loader. Class Loading macht java.lang.String verfügbar, ohne dass Sie etwas tun müssen, lässt ein JAR auf dem Classpath zur Laufzeit erscheinen und betreibt Plugin-Systeme, Applikationsserver und Hot-Reload-Tools. Dieses Kapitel zeigt, wie die Loader organisiert sind, wie die Delegation funktioniert und warum die Identität einer Klasse mehr als nur ihr Name ist.

Die Class-Loader-Hierarchie

Loader sind als eine Kette von Eltern angeordnet, jeder zuständig für eine andere Quelle von Klassen. In einem modernen JDK (9+) gibt es drei eingebaute Loader:

Loader	Lädt	Gemeldet als
Bootstrap	Kern-JDK-Klassen (`java.`, `javax.` Basismodule)	`null`
Platform	Die restlichen JDK-Plattformmodule	ein `PlatformClassLoader`
System / Application	Ihr Code vom Classpath/Modulpfad	ein `AppClassLoader`

Jede Klasse merkt sich den Loader, der sie definiert hat. Sie können jede Klasse fragen, welcher Loader sie erzeugt hat:

ClassLoader appLoader = MyApp.class.getClassLoader();   // AppClassLoader
ClassLoader strLoader = String.class.getClassLoader();  // null = bootstrap
ClassLoader parent    = appLoader.getParent();          // PlatformClassLoader

Der Bootstrap-Loader ist in nativem Code geschrieben, nicht in Java, weshalb String.class.getClassLoader() null zurückgibt anstatt ein Objekt — es gibt keine Java-ClassLoader-Instanz, die zurückgegeben werden könnte.

Das Delegationsmodell

Class Loader folgen dem Parent-First-Delegations-Modell. Wenn ein Loader aufgefordert wird, eine Klasse zu laden, versucht er nicht sofort, sie zu finden. Er fragt zuerst seinen Elternteil, der wiederum seinen Elternteil fragt, bis hinauf zum Bootstrap. Nur wenn kein Vorfahre die Klasse liefern kann, versucht der ursprüngliche Loader, sie selbst zu definieren.

// Conceptual shape of ClassLoader.loadClass:
protected Class<?> loadClass(String name, boolean resolve) {
  Class<?> c = findLoadedClass(name);     // already loaded? reuse it
  if (c == null) {
    try {
      c = parent.loadClass(name);         // delegate UP first
    } catch (ClassNotFoundException e) {
      c = findClass(name);                // only now load it myself
    }
  }
  return c;
}

Diese Delegation stellt sicher, dass Kerntypen einmal geladen werden, vom höchsten Loader, der sie liefern kann. Deshalb können Sie java.lang.String nicht überschreiben, indem Sie Ihr eigenes String.class auf den Classpath legen — der Bootstrap-Loader beansprucht den Namen zuerst.

Laden, Verknüpfen, Initialisieren

Eine Klasse zum Leben zu erwecken geschieht in drei Phasen, und sie sind nicht dasselbe:

Laden — den Bytecode lesen und das Class-Objekt erstellen.
Verknüpfen — den Bytecode verifizieren, dass er wohlgeformt ist, statische Felder mit Standardwerten vorbereiten und symbolische Referenzen auflösen.
Initialisieren — statische Initialisierer und statische Feldzuweisungen ausführen (die <clinit>-Methode der Klasse).

Die entscheidende praktische Tatsache: Die Initialisierung ist lazy und geschieht genau einmal. Eine Klasse wird nur bei der ersten aktiven Verwendung initialisiert — beim ersten new, beim ersten statischen Methodenaufruf oder beim ersten Lesen eines nicht-konstanten statischen Feldes.

class Config {
  static final Map<String, String> SETTINGS = load();  // runs once, on first touch
  static Map<String, String> load() {
    System.out.println("Config initialized");
    return Map.of("env", "prod");
  }
}
// "Config initialized" prints only when Config is first actively used.

Benutzerdefinierte Class Loader

Sie können ClassLoader erweitern, um Klassen von überall zu laden — aus einer Datenbank, einem Netzwerk-Stream, generiertem Bytecode oder einem verschlüsselten JAR. Die zwei relevanten Methoden sind findClass (die Bytes finden und definieren) und defineClass (die rohen Bytes an die JVM übergeben, die eine Class zurückgibt).

class BytesLoader extends ClassLoader {
  private final byte[] bytecode;
  BytesLoader(byte[] bytecode) { this.bytecode = bytecode; }
  @Override
  protected Class<?> findClass(String name) {
    return defineClass(name, bytecode, 0, bytecode.length);
  }
}

URLClassLoader ist die eingebaute Version dieser Idee — zeigen Sie auf JARs oder Verzeichnisse und er lädt Klassen bei Bedarf:

URL jar = Path.of("plugin.jar").toUri().toURL();
try (URLClassLoader loader = new URLClassLoader(new URL[]{ jar })) {
  Class<?> plugin = loader.loadClass("com.example.Plugin");
  Object instance = plugin.getDeclaredConstructor().newInstance();
}

Klassenidentität: Name plus Loader

Hier ist die Feinheit, die viele Menschen überrascht: Die Laufzeitidentität einer Klasse ist ihr vollqualifizierter Name und der Loader, der sie definiert hat. Laden Sie Bytes für Widget durch zwei verschiedene Loader, und Sie erhalten zwei unterschiedliche Class-Objekte — nicht gleich, nicht zuweisungskompatibel — obwohl beide aus identischem Bytecode stammen. Genau so isolieren Applikationsserver zwei eingesetzte Anwendungen, die beide eine Klasse namens com.acme.Util enthalten.

Ein ausgearbeitetes Beispiel: Loader, Delegation, Laziness und Identität

Dieses Programm benötigt keine externen Klassen — es verwendet die bereits in jeder JVM vorhandenen Loader. Es durchläuft die Loader-Kette, beweist, dass Kernklassen vom Bootstrap-Loader stammen, zeigt, wie Delegation dasselbe Class-Objekt zurückgibt, beobachtet, wie ein statischer Initialisierer lazy und nur einmal ausgeführt wird, und definiert dann denselben handgefertigten Bytecode durch zwei Loader, um die Name-plus-Loader-Identitätsregel zu beweisen.

java— editable, runs on the server

public class ClassLoadingDemo {

public static void main(String[] args) throws Exception {
    // 1. Walk the loader chain for an application class.
    ClassLoader app = ClassLoadingDemo.class.getClassLoader();
    System.out.println("ClassLoadingDemo loaded by : " + app.getClass().getName());
    System.out.println("parent of app loader       : " + app.getParent().getClass().getName());

// 2. Core JDK classes come from the bootstrap loader, reported as null.
    System.out.println("String loaded by           : " + String.class.getClassLoader());

// 3. Delegation: loadClass returns the very same Class a direct reference uses.
    Class<?> sb = app.loadClass("java.lang.StringBuilder");
    System.out.println("StringBuilder loader       : " + sb.getClassLoader());
    System.out.println("same Class as direct ref?  : " + (sb == StringBuilder.class));

// 4. Loading is lazy; the static initializer runs exactly once, on first use.
    System.out.println("--- referencing Lazy now ---");
    System.out.println("Lazy.VALUE = " + Lazy.VALUE);
    System.out.println("Lazy.VALUE = " + Lazy.VALUE);

// 5. Class identity = fully-qualified name + defining loader.
    byte[] bytes = buildWidget();
    ClassLoader l1 = new BytesLoader(bytes);
    ClassLoader l2 = new BytesLoader(bytes);
    Class<?> a = l1.loadClass("Widget");
    Class<?> b = l2.loadClass("Widget");
    System.out.println("a.getName()                : " + a.getName());
    System.out.println("b.getName()                : " + b.getName());
    System.out.println("a == b ?                   : " + (a == b));
    System.out.println("a.isAssignableFrom(b) ?    : " + a.isAssignableFrom(b));
  }

// A class whose static block we can watch fire.
  static class Lazy {
    static final int VALUE;
    static {
      System.out.println("Lazy <clinit> running (initialization)");
      VALUE = 42;
    }
  }

// A loader that defines one class named "Widget" from raw bytecode.
  static class BytesLoader extends ClassLoader {
    private final byte[] bytes;
    BytesLoader(byte[] bytes) { this.bytes = bytes; }
    @Override
    protected Class<?> findClass(String name) {
      return defineClass(name, bytes, 0, bytes.length);
    }
    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
      if (name.equals("Widget")) return findClass(name);
      return super.loadClass(name);
    }
  }

// Hand-assemble the minimal .class file for: public class Widget {}
  static byte[] buildWidget() {
    java.io.ByteArrayOutputStream out = new java.io.ByteArrayOutputStream();
    java.io.DataOutputStream d = new java.io.DataOutputStream(out);
    try {
      d.writeInt(0xCAFEBABE);                            // magic number
      d.writeShort(0);                                   // minor version
      d.writeShort(52);                                  // major version (Java 8)
      d.writeShort(13);                                  // constant_pool_count
      d.writeByte(10); d.writeShort(3); d.writeShort(10);// #1 Methodref Object.<init>
      d.writeByte(7);  d.writeShort(11);                 // #2 Class Widget
      d.writeByte(7);  d.writeShort(12);                 // #3 Class Object
      d.writeByte(1);  d.writeUTF("<init>");             // #4
      d.writeByte(1);  d.writeUTF("()V");                // #5
      d.writeByte(1);  d.writeUTF("Code");               // #6
      d.writeByte(1);  d.writeUTF("Widget.java");        // #7
      d.writeByte(1);  d.writeUTF("SourceFile");         // #8
      d.writeByte(1);  d.writeUTF("ignored");            // #9
      d.writeByte(12); d.writeShort(4); d.writeShort(5); // #10 NameAndType <init>:()V
      d.writeByte(1);  d.writeUTF("Widget");             // #11
      d.writeByte(1);  d.writeUTF("java/lang/Object");   // #12
      d.writeShort(0x0021);                              // access_flags: public super
      d.writeShort(2);                                   // this_class  = #2
      d.writeShort(3);                                   // super_class = #3
      d.writeShort(0);                                   // interfaces_count
      d.writeShort(0);                                   // fields_count
      d.writeShort(1);                                   // methods_count
      d.writeShort(0x0001);                              // method: public
      d.writeShort(4);                                   // name_index = <init>
      d.writeShort(5);                                   // descriptor_index = ()V
      d.writeShort(1);                                   // attributes_count
      d.writeShort(6);                                   // attribute_name = Code
      java.io.ByteArrayOutputStream codeOut = new java.io.ByteArrayOutputStream();
      java.io.DataOutputStream cd = new java.io.DataOutputStream(codeOut);
      cd.writeShort(1);                                  // max_stack
      cd.writeShort(1);                                  // max_locals
      cd.writeInt(5);                                    // code_length
      cd.writeByte(0x2a);                                // aload_0
      cd.writeByte(0xb7); cd.writeShort(1);              // invokespecial Object.<init>
      cd.writeByte(0xb1);                                // return
      cd.writeShort(0);                                  // exception_table_length
      cd.writeShort(0);                                  // attributes_count
      byte[] codeBytes = codeOut.toByteArray();
      d.writeInt(codeBytes.length);
      d.write(codeBytes);
      d.writeShort(0);                                   // class attributes_count
      d.flush();
    } catch (Exception e) { throw new RuntimeException(e); }
    return out.toByteArray();
  }
}

Was aus dem Programmablauf zu entnehmen ist:

Die ausgegebene Loader-Kette ist die lebendige Class-Loader-Hierarchie mit Ihrem Code am unteren Ende: ClassLoadingDemo wurde von einem Loader auf Anwendungsebene definiert, dessen getParent() der nächste Loader in der Kette ist. Jeder Loader kennt nur seinen Elternteil, und die Kette steigt immer in Richtung Bootstrap.
String.class.getClassLoader() gibt null aus, die JVM-Methode zu sagen: "geladen vom Bootstrap-Loader." Kern-JDK-Typen melden hier immer null; ein Objekt würde bedeuten, dass sie von einem niedrigeren Loader stammen, was nie der Fall ist.
app.loadClass("java.lang.StringBuilder") == StringBuilder.class ist true. Die Delegation hat die Anfrage an den Loader weitergeleitet, der StringBuilder bereits besitzt, sodass Sie das identische Class-Objekt zurückbekommen, keine Kopie — Beweis, dass Delegation verhindert, dass Kerntypen zweimal geladen werden.
Lazy <clinit> running wird einmal ausgegeben, zwischen der Markierung --- referencing Lazy now --- und dem ersten Lazy.VALUE = 42, und beim zweiten Lesen nie wieder. Die Initialisierung ist lazy (sie wartete bis zur ersten Verwendung) und idempotent (der statische Block wird genau einmal pro Loader ausgeführt).
a und b heißen beide Widget, doch a == b ist false und a.isAssignableFrom(b) ist false. Zwei Loader haben denselben Bytecode in zwei unterschiedliche Typen definiert — konkreter Beweis, dass die Laufzeitklassenidentität vollqualifizierter Name plus definierender Loader ist, der Mechanismus hinter der Classpath-Isolation in Applikationsservern.

Übungen

Übung

Zwei separate benutzerdefinierte Class Loader laden jeweils identischen Bytecode für eine Klasse namens 'com.acme.Widget'. Was gilt für die resultierenden Class-Objekte a (von Loader 1) und b (von Loader 2)?

Sie sind unterschiedliche, inkompatible Typen: 'a == b' ist false und eine Instanz des einen kann keiner Referenz des anderen zugewiesen werden, weil die Klassenidentität der vollqualifizierte Name plus der definierende Loader istSie sind dasselbe Class-Objekt, weil die JVM Klassen global nach vollqualifiziertem Namen zwischenspeichertDas zweite Laden wirft einen 'LinkageError', weil eine Klasse mit diesem Namen bereits in der JVM definiert istSie sind verschiedene Objekte, aber vollständig zuweisungskompatibel, da sie denselben Namen und denselben Bytecode teilen

Java Class Loading