【JVMをゼロから学ぶ | 第4回】クラスローダーの分類と親委任の仕組み

序文：

Java プログラミングでは、クラスローダー (クラスローダー) が重要な役割を果たします。クラスローダーは Java バイトコードをロードし、それを実行可能オブジェクトに変換する役割を担っており、アプリケーション内でさまざまなクラスやリソースを使用できるようにします。 Java クラスローダーの設計と実装は、動的な拡張とモジュラープログラミングをサポートし、Java 言語に優れた柔軟性と保守性を提供することを目的としています。

クラスローダーの分類は、Java クラスロードメカニズムを理解する上で重要な部分です。さまざまなタイプのクラスローダーがさまざまなタイプのクラスのロードを担当し、ロード戦略と優先順位も異なります。この記事では、クラスローダーの分類を掘り下げ、各クラスローダーの特徴や利用シーンを詳しく紹介します。

序文：

クラスローダー:

クラスローダーとは:

クラスローダーのアプリケーションシナリオ:

クラスローダーの分類 (JDK8 および以前のバージョン):

クラスローダー:

クラスローダーとは:

ClassLoader は、クラスおよびインターフェイスのバイトコードデータを実装するために、JAVA 仮想マシンによってアプリケーションに提供されるテクノロジーです。

クラスローダーは、バイトコードが取得されてメモリにロードされるロードプロセスの部分にのみ参加します。

クラスローダーのアプリケーションシナリオ:

動的ロード: クラスローダーを使用すると、新しいクラスとリソースを実行時に動的にロードできます。これは、特定の条件やユーザーのニーズに基づいてさまざまなクラスをロードする必要があるアプリケーションに役立ちます。たとえば、クラスローダーは、プラグインシステムやモジュール開発でモジュールを動的にロードおよびアンロードして、柔軟な拡張や機能のカスタマイズを実現するためによく使用されます。
ホットデプロイメント: クラスローダーはホットデプロイメント、つまりアプリケーションの実行中にロードされたクラスの置換と更新を実装できます。これにより、アプリケーションを停止せずにコードの更新や修正を行うことができます。ホットデプロイメントは開発およびデバッグ段階で非常に役立ち、開発効率とデバッグエクスペリエンスを向上させます。
バージョン分離: 異なるクラスローダーを使用して異なるバージョンのクラスをロードすることで、クラスのバージョン分離を実現できます。これは、クラスの異なるバージョン間の競合や互換性の問題を回避するために、アプリケーションのアップグレードや依存関係の管理において非常に重要です。
セキュリティ制御: クラスローダーは、特定のコードやリソースへのアクセスを制限または制御するセキュリティポリシーを適用できます。カスタムクラスローダーを介して、カスタムセキュリティポリシーを実装し、読み込まれたクラスに対して権限の制御と検証を実行できます。
バイトコードの拡張機能と動的プロキシ: クラスローダーを使用して、バイトコードの拡張機能と動的プロキシを実装できます。カスタムクラスローダーを使用すると、クラスロードプロセス中にバイトコードを変更し、追加のロジックや機能を追加できます。これには、AOP (アスペクト指向プログラミング) やプロキシパターンなどのテクノロジに重要な用途があります。

クラスローダーの親委任メカニズムも、面接で必ず尋ねるべき質問です。面接官が JVM について質問している限り、-関連コンテンツの場合は、親委任メカニズムを必ず確認する必要があります。したがって、クラスローダー関連の内容をよく学ぶ必要があります。

クラスローダーとは何か、およびその適用シナリオを理解したら、クラスローダーについて正式に学習しましょう。

クラスローダーの分類 (JDK8 および以前のバージョン):

ブートストラップクラスローダー: JVM の一部であり、java.lang パッケージ内のクラスなどの Java コアクラスライブラリをロードします。これはトップレベルのクラスローダーであり、通常はC++ を使用して実装され、Java コードで直接取得することはできません< /span>。 (一般的かつ重要)
Extension ClassLoader: Java 拡張ライブラリのロードを担当します。通常は JRE の lib/ext ディレクトリにあります。これは Java で書かれており、スタートアップクラスローダーによってロードされます。 (一般的ですが重要ではありません)
アプリケーションクラスローダー: システムクラスローダー (System ClassLoader) とも呼ばれ、ユーザークラスパス (Classpath) で指定されたクラスライブラリをロードします。これは開発者によって最も一般的に使用されるクラスローダーであり、デフォルトのクラスローダーでもあります。

上記の 3 つの一般的なクラスローダーに加えて、java.lang.ClassLoader クラスを継承してクラスローダーをカスタマイズすることもできます。カスタムクラスローダーは、ネットワークからのクラスファイルのダウンロード、復号化など、さまざまな特定のニーズを満たすためにクラスを柔軟にロードできます。

要約すると、一般的なクラスローダーは、起動クラスローダー、拡張クラスローダー、およびアプリケーションクラスローダーに分類できます。開発者は、必要に応じてクラスローダーをカスタマイズすることもできます。

実際の JAVA コードでは、複数のクラスローダーのロードスコープに JAR パッケージが同時に存在する状況が発生することがありますが、このとき、この問題を解決するには親の委任メカニズムが必要です。

親委任メカニズム:

親の委任メカニズムとは次のとおりです。

親委任モデルは、Java クラスローダーの動作メソッドであり、クラスロードの安全性を確保するために使用されます。 < a i=3>そして一貫性。

親委任メカニズムに従って、クラスローダーがクラスをロードする必要がある場合、まず親クラスローダーに委任してロードを試行します。親クラスローダーがクラスを正常にロードできる場合、クラスの Class オブジェクトが返されます。親クラスローダーがクラスをロードできない場合、子クラスローダーはそれ自体をロードしようとします。

簡単に言うと、親委任メカニズムの核心は、誰がクラスをロードするかという問題を解決することです。このプロセスでは、ロードされているかどうかを調べ、ロードを試みます。

注: 「親」は存在しますが、ローダーとその親クラスローダーの間の関係は継承とみなされません。本質は、ローダー内に ClassLoader を作成して、その親クラスローダーを保存することです。

拡張クラスローダーの親オブジェクトを取得しようすると、結果は null になることに注意してください。これは、その親クラスが起動クラスローダーではないということではなく、起動クラスローダーは JVM の一部であり、C++ で実装されており、取得できないためです。 =4>!

親委任メカニズムのソースコードの解釈:

親委任メカニズム全体はクラスロードで実行されるため、主にソースコードのこの部分を確認します。

クラスをロードしようとするとき、loadClass メソッドを呼び出します。メソッドの最初のパラメータは、ロードされたクラスの名前です。 、2 番目のパラメータは、クラスを解析するかどうかです

loadClassメソッドを入力します

実際、このコードは比較的理解しやすく、全体的なロジックは次のとおりです。

findLoadedClass を使用して、ターゲットクラスがロードされているかどうかを確認します。
ターゲットクラスがロードされていない場合 (c==null)、現在のローダーの親クラスローダーを探します。親クラスローダーがある場合 (parent!=null)、現在のクラスを親クラスに渡します。ローダーでloadClass.メソッドを実行します。親クラスローダーがない場合は、起動クラスローダー (BootstrapClassLoad) に親クラスローダーを見つけてロードさせます。
最上位ローダーに到達した後もターゲットクラスをロードできない場合は、現在のローダーにそれをロードさせ (c=findClass(name))、時間とその他の情報を記録して、0 を返します。
ターゲットクラスがロードされている場合は、直接 0 を返します。

最後に、c=findClass(name) の findClass ソースコードを見てみましょう。

親委任メカニズムの役割:

重複ロードを避ける: 親委任メカニズムを使用すると、各クラスローダーはクラスをロードする前に親クラスローダーに委任します。これにより、同じクラスが複数の異なるクラスローダーによってロードされるのを防ぎ、クラスの一貫性を確保し、繰り返しのロードによって発生する競合やメモリの無駄を回避できます。
セキュリティ保証: コアクラスライブラリ (Java のコアクラスライブラリなど) はスタートアップクラスローダーによってロードされ、ユーザー定義クラスはアプリケーションクラスローダーによってロードされます。。これにより、コアクラスライブラリのセキュリティが確保され、ユーザー定義クラスによるコアクラスライブラリの動作の改ざんを防ぐことができます。
クラスの分離: 異なるクラスローダーによってロードされたクラスは、異なる名前空間に配置され、相互に分離されます。 2 つのクラスの完全修飾名が同じであっても、異なるクラスローダーによってロードされたクラスは、JVM では異なるクラスとみなされます。この分離によりクラスの競合が効果的に回避され、各クラスローダーがクラスを個別にロードして管理できるようになります。
拡張性: クラスローダーをカスタマイズすることで、Java のクラスロードメカニズムを拡張して、特定のロード要件を達成できます。開発者はクラスローダーをカスタマイズして、ホットデプロイメントや動的ローディングなどの機能を実装できます。カスタムクラスローダーは、親クラスローダーの特性を継承し、ビジネスニーズに応じて拡張できます。

一般に、親委任メカニズムは、クラスの一貫性、セキュリティ、分離を確保し、繰り返しロードを回避することができ、また、特定のニーズに応じてクラスローダーをカスタマイズできるように柔軟な拡張性も提供します。

親委任メカニズムは、JAVA クラスのロードに優れたセキュリティを提供しますが、および利便性 a>。しかし、場合によっては、次のような親の委任メカニズムを破らなければならない場合もあります。

Tomcat コンテナは複数の WEB アプリケーションを実行できます。これら 2 つのアプリケーションに同じ名前のクラス A が存在する場合、Tomcat は両方のクラス A がロードされ、異なるクラスであることを確認する必要があります。親委任メカニズムが壊れていない場合、WEB1 のクラス A が記録された後、WEB2 の自身のクラス A は正常にロードされず、親委任メカニズムに従って、この時点で WEB1 のクラス A が直接返されます。この時点で、親の委任メカニズムを解除する必要があります。

親の委任メカニズムを破壊する:

1. クラスローダーをカスタマイズし、クラスロードを書き換えます (Tomcat の使用方法)。

上記のソースコードの個別の読み取りを通じて、親委任メカニズムの基本的なプロセスを皆さんは理解できたと思います。親の委任メカニズムを壊したい場合は、Classload メソッドを書き換えるだけです。具体的には、次のコードブロックを書き換えます。

コード例:

public class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) {
            // 首先检查类是否已经被加载
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                // 检查类是否在系统类加载器中已经加载
                c = findClass(name);
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
    
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 在这里实现自定义的类加载逻辑
        // 可以从其他位置加载类的字节码，并使用 defineClass() 方法定义类
    }
}

ただし、このコードのロジックでは、カスタムクラスの親クラスローダーはロードしませんが、デフォルトの親クラスローダーも存在することに注意してください。 < a i=1>アプリケーションクラスローダーですが、loadClass を書き換えたときに親クラスローダーを使用しませんでした。

ローダーをカスタマイズしていくつかのクラスを個別にロードしたい場合。現時点では、親委任メカニズムを壊さず、FindClass で書き直すことを選択する必要があります。

2. スレッドコンテキストクラスローダー (JDBC 使用戦略):

JDBC は、データベースに接続してさまざまなデータベースドライバを管理し、関連ドライバを読み込むときに、DriveManager というパッケージを使用します。

String url = "jdbc:mysql://localhost:3306/your_database_name";
String username = "your_username";
String password = "your_password";
Connection connection = DriverManager.getConnection(url, username, password);

DriveManager は rt.jar にあり、スタートアップクラスローダーによってロードされます。

このパッケージはさまざまなデータベースドライバークラスをロードする必要があります。このサードパーティパッケージは、アプリケーション読み込みクラスに読み込む必要があります。その後、問題が発生します:

つまり、起動クラスローダーがDriveManagerをロードした後、ロードする必要があるさまざまなデータベースドライバが必要になります。< a i=3>スタートアップクラスローダーはロードできません。アプリケーションクラスローダーによってのみロードできます。これは、親委任メカニズムのボトムアップ委任原則に違反していませんか?

段階的に分析してみましょう。まず、SPI メカニズムを紹介します。

SPI (Service Provider Interface) は、Java によって提供されるサービスディスカバリメカニズムです。これにより、開発者はサービスインターフェイスを定義でき、サードパーティベンダーはアプリケーションのクラスパスの下に実装を提供することでアプリケーションの機能を拡張できます。

SPI メカニズムは次のように機能します。まず、開発者はサービスインターフェイスと、そのインターフェイスのサービス実装を提供する 1 つ以上のクラスを定義します。次に、アプリケーションのクラスパスに構成ファイルを作成します。ファイル名は「META-INF/services/インターフェイスの完全修飾名」である必要があり、インターフェイスの完全修飾名がファイル名として使用されます。、その内容はサービスインターフェイス実装クラスの完全修飾名です。

アプリケーションが初期化されると、Java ランタイムは Java のリフレクションメカニズムを使用して、クラスパス上の構成ファイルからサービスインターフェイスの実装クラスを読み取り、ロードします。このようにして、アプリケーションは実装クラスのインスタンスを取得し、それが提供する関数を使用できます。

そして、DriveManager は、SPI メカニズムを通じて、JaR パッケージによってロードされるドライバーを迅速に見つけます。

SPI メカニズムに基づいて、DriveManager をロードする全体的なプロセスは次のとおりです。

SPI メカニズムに基づいて DriveManager をロードする全体的なプロセスを理解した後、もう一度考えてみましょう。SPI メカニズムは、親の委任メカニズムの下で下からの委任をどのようにして解除するのでしょうか。毛織物？

SPI メカニズムでは、通常、スレッドコンテキストクラスローダー (Thread Context Class Loader) が特定の実装クラスをロードするために使用されます。スレッドコンテキストクラスローダーは、各スレッドのクラスローダーを指定するためにマルチスレッド環境で導入された概念です。スレッドコンテキストクラスローダーは、通常、 Thread.currentThread().setContextClassLoader() メソッドを介して設定されます。

SPI メカニズムでは、スレッドコンテキストクラスローダーは、親委任モデルの下で委任の問題をボトムアップで解決できます。具体的には、SPI 実装フレームワークのコードがクラスライブラリに配置され、アプリケーションによってカスタマイズされた SPI 実装クラスがアプリケーションのクラスパスの下に配置されている場合、親の制限により、SPI 実装はアプリケーションによって直接ロードできません。委任モデルの種類。現時点では、SPI 実装クラスは、アプリケーションのスレッドコンテキストクラスローダーを使用してロードできます。つまり、スレッドコンテキストクラスローダーをアプリケーションのクラスローダーに設定します< a i =4>。このようにして、SPI 実装フレームワークは、スレッドコンテキストクラスローダーを通じてアプリケーションに SPI 実装クラスをロードできるため、親委任モデルの制限が打ち破られます。

SPI メカニズムはスレッドコンテキストクラスローダーの正しい設定に依存していることに注意してください。したがって、SPI メカニズムを使用する場合は、SPI 実装フレームワークが正しく機能できるように、スレッドコンテキストクラスローダーが正しく設定されていることを確認する必要があります。アプリケーションに SPI 実装クラスをロードします。

簡単に言うと、SPI にはコンテキストクラスローダーがあり、アプリケーションクラスローダーを事前に保存できます。次に、スタートアップクラスローダーを使用して DriveManager をロードし、DriveManager がデータベースドライバーをロードする必要がある場合、DriveManager はコンテキストクラスローダーを呼び出し、現在のローダーがスタートアップクラスローダーからアプリケーションクラスローダーに変更されます。

しかし実際には、コンテキストローダーが親の委任メカニズムを破る方法についてはまだ議論があります。

一部の人々は、彼が親の委任メカニズムを破ったと考えています: DriveManager は起動クラスローダーによってロードされますが、記録中に記録するにはプログラムクラスローダーを委任する必要があるためです。プロセス、親の委任を破るメカニズムの委任はトップダウンのルールです。
一部の人々は、彼が親の委任メカニズムを破っていないと考えています: クラスのロードプロセス全体で、DriveManager は Java コアパッケージ rt.jar 内にあるため、ロードされるからです。起動クラスローダーによる; jar パッケージ内のデータベースドライバーはサードパーティパッケージであるため、アプリケーションクラスローダーからロードされます。 DriveManager クラスをロードする場合でも、データベースドライバークラスをロードする場合でも、loadClass メソッドはオーバーライドされません。ネイティブの loadClass を使用する限り、親の委任メカニズムに従います。

3. OSGI フレームワーククラスローダー:

歴史的に、OSGI モジュラーフレームワークは親委任メカニズムを破壊し、ピア間でクラスレコーダーの読み込みを委任していました。

OSGi (Open Services Gateway) は、モジュール式で動的かつ拡張可能な Java アプリケーションを構築するための仕様およびフレームワークです。

モジュール化とは、アプリケーションを複数の独立したモジュール (バンドルとも呼ばれます) に分割し、それぞれに独自のコードとリソースを含めることを指します。このモジュール設計により、開発者はアプリケーションをより柔軟に管理および保守できるようになり、再利用性と保守性が向上します。

初期の頃、JAVA にはモジュール性という概念がありませんでした。すべての jar パッケージはrt.jar で管理されていましたが、 OSGi 同様の機能を持つjarパッケージを1つのjarパッケージにまとめて一元管理する方法を提供します。

OSGi フレームワークでは、各モジュールはバンドルと呼ばれ、バンドルには独自のクラスとリソースを含めることができます。 OSGi は、BundleClassLoader と呼ばれる独自のクラスローダー実装を使用します。

BundleClassLoader は OSGi フレームワークのコアクラスローダーであり、クラスをロードするときに親の委任メカニズムを破壊します。まずクラス自体のロードを試みますが、必要なクラスが見つからない場合は、親クラスローダーに委譲します。 BundleClassLoader は最初に自分自身をロードしようとし、必ずしも親優先の原則に従わないため、このメカニズムは標準の親委任メカニズムとは異なります。

要約:

クラスローダーと親委任メカニズムは、Java の重要な概念です。 Java プログラムは、クラスローダーを通じてクラスを動的にロードして、コードの柔軟性とスケーラビリティを実現できます。親委任メカニズムにより、クラスの一意性と一貫性が保証され、繰り返しの読み込みと競合が回避されます。クラスローダーと親委任を理解することは、クラスパスの競合を解決し、モジュール開発を実現し、セキュリティを確保するために重要です。これらは、Java の動的読み込み機能とモジュール開発を習得する上で非常に重要です。 Java の原理とメカニズムを深く理解すると、Java の柔軟性と拡張性をより適切に活用し、優れたアプリケーションを開発できます。場合によっては、クラスローダーの動作をさらに便利にするために、クラスローダーの動作をカスタマイズおよび拡張することが必要になる場合があります。つまり、クラスローダーと親委任メカニズムは Java 仮想マシンのコアコンポーネントであり、Java の動的読み込み機能とモジュール開発を理解して習得するために重要です。

私のコンテンツがお役に立ちましたら、いいね、コメント、収集してください。創作するのは簡単なことではありませんが、皆さんのサポートが私の原動力です。