Java クラスローダーの詳細

ブートストラップ クラス ローダーを除き、すべてのクラス ローダーには親クラス ローダーがあります。これは、表 1 に示す getParent() メソッドを通じて取得できます。システムによって提供されるクラスローダーの場合、システムクラスローダーの親クラスローダーは拡張クラスローダーであり、開発者によって作成されたクラスローダーの場合、拡張クラスローダーの親クラスローダーはブートクラスローダーです。クラスローダーは、このクラスローダーの Java クラスをロードするクラスローダーです。なぜなら、クラスローダー Java クラスは、
他の Java クラスと同様に、クラスローダーによってロードされるからです。一般に、開発者が作成したクラスローダーの親クラスローダーはシステムクラスローダーです。クラスローダーはこのように編成され、ツリー構造を形成します。ツリーのルート ノードはブート クラス ローダーです。図 1 は、典型的なクラス ローダー ツリーの組織構造図を示しています。矢印は親クラス ローダーを指しています。
図 1. クラス ローダーのツリー構成構造の概略図

コード リスト 1 は、クラス ローダーのツリー構成構造を示しています。

リスト 1. デモのクラスローダーツリー構成構造

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

reference を維持します。この参照は getClassLoader() メソッドを通じて取得できます。コード リスト 1 では、getParent() メソッドが再帰的に呼び出され、すべての親クラス ローダーが出力されます。コード リスト 1 の実行結果をコード リスト 2 に示します。 リスト 2. クラス ローダーのツリー状の組織構造の実行結果を示します
sun.misc.Launcher$AppClassLoader@9304b1 sun.misc.Launcher$ExtClassLoader@190d11 コード リスト 2 に示すように、最初の出力は ClassLoaderTree クラスのクラス ローダー、つまりシステム クラス ローダーです。これは sun.misc.Launcher$AppClassLoader クラスのインスタンスであり、2 番目の出力は拡張クラス ローダーであり、sun.misc.Launcher$ExtClassLoader クラスのインスタンスです。ここではブート クラス ローダーが出力されないことに注意してください。これは、一部の JDK 実装が、親クラス ローダーがブート クラス ローダーである場合に null を返すためです。
クラスローダーのツリー状の組織構造を理解した後、クラスローダーのプロキシモードを紹介しましょう。

クラスローダーのプロキシモード

クラスローダーが特定のクラスのバイトコードを見つけて定義しようとすると、まずその親クラスローダーにプロキシされ、親クラスローダーは最初にこのカテゴリをロードしようとします。等々。プロキシ パターンの背後にある動機を紹介する前に、まず Java 仮想マシンが 2 つの Java クラスが同じであるとどのように判断するかを説明する必要があります。 Java 仮想マシンは、クラスの完全名が同じかどうかだけでなく、このクラスをロードするクラス ローダーが同じかどうかも調べます。 2 つのクラスは、両方が同じである場合にのみ同じとみなされます。同じバイトコードを異なるクラスローダでロードしても、得られるクラスは異なります。たとえば、Java クラス com.example.Sample は、コンパイル後にバイト コード ファイル Sample.class を生成します。 2 つの異なるクラス ローダー、ClassLoaderA と ClassLoaderB はそれぞれ、この Sample.class ファイルを読み取り、このクラスを表す java.lang.Class クラスの 2 つのインスタンスを定義します。これら 2 つのインスタンスは同一ではありません。 Java 仮想マシンにとって、これらは異なるクラスです。これら 2 つのクラスのオブジェクトを相互に割り当てようとすると、実行時例外 ClassCastException がスローされます。以下に例を挙げて詳しく説明します。 Java クラス com.example.Sample をコード リスト 3 に示します。 リスト 3.com.example.Sample クラス

package com.example;
public class Sample {    
    private Sample instance;
    public void setSample(Object instance) { 
    this.instance = (Sample) instance; 
    }
}

如 代码清单 3所示，com.example.Sample类的方法 setSample接受一个 java.lang.Object类型的参数，并且会把该参数强制转换成com.example.Sample类型。测试 Java 类是否相同的代码如 代码清单 4所示。
清单 4. 测试 Java 类是否相同

public void testClassIdentity() {
    String classDataRootPath = "C:\workspace\Classloader\classData";
    
File
SystemClassLoader fscl1 = new FileSystemClassLoader(classDataRootPath);
    FileSystemClassLoader fscl2 = new FileSystemClassLoader(classDataRootPath);
    String className = "com.example.Sample";
    try {
        Class<?> class1 = fscl1.loadClass(className);
        Object obj1 = class1.newInstance();
        Class<?> class2 = fscl2.loadClass(className);
        Object obj2 = class2.newInstance();
        Method setSampleMethod = class1.getMethod("setSample", java.lang.Object.class);
        setSampleMethod.invoke(obj1, obj2);
    } catch (Exception e) {
        e.printStackTrace();
    }
 }

代码清单 4中使用了类 FileSystemClassLoader的两个不同实例来分别加载类 com.example.Sample，得到了两个不同的java.lang.Class的实例，接着通过 newInstance()方法分别生成了两个类的对象 obj1和 obj2，最后通过 Java 的反射 API 在对象 obj1上调用方法 setSample，试图把对象 obj2赋值给 obj1内部的 instance对象。代码清单 4的运行结果如 代码清单 5所示。
清单 5. 测试 Java 类是否相同的运行结果
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at classloader.ClassIdentity.testClassIdentity(ClassIdentity.java:26)
at classloader.ClassIdentity.main(ClassIdentity.java:9)
Caused by: java.lang.ClassCastException: com.example.Sample
cannot be cast to com.example.Sample
at com.example.Sample.setSample(Sample.java:7)
... 6 more
从 代码清单 5给出的运行结果可以看到，运行时抛出了 java.lang.ClassCastException异常。虽然两个对象 obj1和 obj2的类的名字相同，但是这两个类是由不同的类加载器实例来加载的，因此不被 Java 虚拟机认为是相同的。
了解了这一点之后，就可以理解代理模式的设计动机了。代理模式是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用java.lang.Object类，也就是说在运行的时候，java.lang.Object这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object类，而且这些类之间是不兼容的。通过代理模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到，后面会详细介绍。
下面具体介绍类加载器加载类的详细过程。
加载类的过程
在前面介绍类加载器的代理模式的时候，提到过类加载器会首先代理给其它类加载器来尝试加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类的加载工作是通过调用 defineClass来实现的；而启动类的加载过程是通过调用 loadClass来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。如类 com.example.Outer引用了类com.example.Inner，则由类 com.example.Outer的定义加载器负责启动类 com.example.Inner的加载过程。
方法 loadClass()抛出的是 java.lang.ClassNotFoundException异常；方法 defineClass()抛出的是java.lang.NoClassDefFoundError异常。
类加载器在成功加载某个类之后，会把得到的 java.lang.Class类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器实例来说，相同全名的类只加载一次，即 loadClass方法不会被重复调用。
下面讨论另外一种类加载器：线程上下文类加载器。
线程上下文类加载器
スレッド コンテキスト クラス ローダー (コンテキスト クラス ローダー) は、JDK 1.2 から導入されました。クラス java.lang.Thread のメソッド getContextClassLoader() および setContextClassLoader(ClassLoader cl) は、スレッドのコンテキスト クラス ローダーを取得および設定するために使用されます。 setContextClassLoader(ClassLoader cl) メソッドを通じて設定されていない場合、スレッドは親スレッドのコンテキスト クラス ローダーを継承します。 Java アプリケーションが実行される初期スレッドのコンテキスト クラス ローダーは、システム クラス ローダーです。スレッド内で実行されているコードは、このタイプのローダーを通じてクラスとリソースをロードできます。
上記のクラスローダーのプロキシモードは、Javaアプリケーション開発で遭遇するクラスローダーの問題をすべて解決できるわけではありません。 Java は多くのサービス プロバイダー インターフェイス (サービス プロバイダー インターフェイス、SPI) を提供し、サードパーティがこれらのインターフェイスの実装を提供できるようにします。一般的な SPI には、JDBC、JCE、JNDI、JAXP、JBI などがあります。これらの SPI インターフェイスは、Java コア ライブラリによって提供されます。たとえば、JAXP の SPI インターフェイス定義は javax.xml.parsers パッケージに含まれています。これらの SPI 実装コードは、Java アプリケーションが依存する jar パッケージとして含まれる可能性があり、JAXP SPI を実装する Apache Xerces に含まれる jar パッケージなど、クラス パス (CLASSPATH) を通じて見つけることができます。 SPI インターフェイスのコードは、多くの場合、特定の実装クラスをロードする必要があります。たとえば、JAXP の javax.xml.parsers.DocumentBuilderFactory クラスの newInstance() メソッドは、DocumentBuilderFactory の新しいインスタンスを生成するために使用されます。ここでのインスタンスの実際のクラスは、SPI 実装によって提供される javax.xml.parsers.DocumentBuilderFactory から継承されます。たとえば、Apache Xerces では、実装されるクラスは org.apache.xerces.jaxp.DocumentBuilderFactoryImpl です。問題は、SPI インターフェイスが Java コア ライブラリの一部であり、ブート クラス ローダーによってロードされることです。SPI によって実装された Java クラスは、通常、システム クラス ローダーによってロードされます。ブート クラス ローダーは Java コア ライブラリのみをロードするため、SPI 実装クラスを見つけることができません。また、これはシステム クラス ローダーの祖先クラス ローダーであるため、システム クラス ローダーにプロキシすることもできません。つまり、クラスローダーのプロキシモードではこの問題を解決できません。 スレッドコンテキストクラスローダーはこの問題を解決します。設定が行われていない場合、Java アプリケーション スレッドのコンテキスト クラス ローダーは、デフォルトのシステム コンテキスト クラス ローダーになります。 SPI インターフェイス コードでスレッド コンテキスト クラス ローダーを使用すると、SPI 実装クラスを正常にロードできます。スレッド コンテキスト クラス ローダーは、多くの SPI 実装で使用されます。 以下では、クラスをロードする別の方法、Class.forName を紹介します。

Class.forName
Class.forName は、クラスのロードにも使用できるstatic
メソッドです。このメソッドには、Class.forName(String name, boolean initialize, ClassLoader ローダー) と Class.forName(String className) の 2 つの形式があります。パラメータ名の最初の形式はクラスの完全名を表し、initialize はクラスを初期化するかどうかを表し、loader はロード時に使用されるクラス ローダーを表します。 2 番目の形式は、パラメーターの値 initialize を true に設定し、loader の値を現在のクラスのクラス ローダーに設定することと同じです。 Class.forName の非常に一般的な使用法は、データベース ドライバー をロードするときです。たとえば、Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance() は、Apache Derby データベースのドライバーをロードするために使用されます。 クラスローダーに関連する基本概念を紹介した後、独自のクラスローダーを開発する方法を説明します。

public class FileSystemClassLoader extends ClassLoader {
    private String rootDir; 
    public FileSystemClassLoader(String rootDir) { 
    this.rootDir = rootDir; 
} 
    protected Class<?> findClass(String name) throws ClassNotFoundException { 
    byte[] classData = getClassData(name); 
    if (classData == null) { 
        throw new ClassNotFoundException(); 
    } 
    else { 
        return defineClass(name, classData, 0, classData.length); 
    } 
} 
    private byte[] getClassData(String className) { 
    String path = classNameToPath(className); 
    try { 
        InputStream ins = new FileInputStream(path); 
        ByteArrayOutputStream baos = new ByteArrayOutputStream(); 
        int bufferSize = 4096; 
        byte[] buffer = new byte[bufferSize]; 
        int bytesNumRead = 0; 
        while ((bytesNumRead = ins.read(buffer)) != -1) { 
            baos.write(buffer, 0, bytesNumRead); 
        } 
        return baos.toByteArray(); 
    } catch (IOException e) { 
        e.printStackTrace(); 
    } 
    return null; 
} 
    private String classNameToPath(String className) { 
    return rootDir + File.separatorChar 
            + className.replace(&#39;.&#39;, File.separatorChar) + ".class"; 
    }
}

以上がJava クラスローダーの詳細の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。