この記事を読んだ後、JVMクラスローディングの仕組みが分からないなんて言わないでくださいね〜

[[405748]]

JVM は親委任モデルを通じてクラスをロードします。つまり、クラス ローダーはクラスのロード要求を受け取ると、まずロード タスクを親クラス ローダーに再帰的に委任します。親クラスローダーがクラスロードタスクを完了できる場合、正常に戻ります。親クラス ローダーがこの読み込みタスクを完了できない場合にのみ、クラス ローダー自体が読み込みます。

クラスローダー

• Bootstrap ClassLoader: JAVA_HOME\lib ディレクトリまたは -Xbootclasspath パラメータで指定され、仮想マシンによって認識されるパス (rt.jar などのファイル名で識別されます。名前が一致しないクラス ライブラリは、lib ディレクトリに配置されていてもロードされません) にクラスをロードします。ブート クラス ローダーは Java プログラムによって直接参照することはできません。
• 拡張クラスローダー: JAVA_HOME\jre\lib\ext ディレクトリまたは java.ext.dirs システム変数で指定されたパスにクラス ライブラリをロードします。
• アプリケーション ClassLoader: ユーザー パス (クラスパス) 上のクラス ライブラリをロードする役割を担います。
• java.lang.ClassLoader クラスを継承して (主に findClass メソッドをオーバーライドして)、カスタム クラス ローダーを実装します。

概要: クラス ローダーとバイトコードは、Java プラットフォームの独立性の基礎となります。どのクラスでも、そのクラス ローダーとクラス自体が連携して、Java 仮想マシン内での一意性を確立する必要があります。

親委任モデルの利点:

• 基本クラスの統一されたロードの問題 (クラスが基本的であるほど、ローダーのレベルが高くなります)。たとえば、java.lang.String クラスの場合、どのクラス ローダーがこのクラスをロードしようとしても、最終的には起動クラス ローダーにロードが委任されるため、プログラムのさまざまなクラス ローダー環境で同じクラスになります。
• Java コードのセキュリティを向上します。たとえば、ユーザーがシステム ライブラリ内のクラスと同じ名前の java.lang.String クラスをカスタマイズした場合、トップレベルのクラス ローダーはカスタマイズされた String クラスではなく、システムの java.lang.String クラスを最初にロードするため、このクラスはロードされず、悪意のあるコードの挿入が防止されます。
• クラスの繰り返しロードを回避し、Java のコア API が改ざんされるのを防ぐことができます。

クラスのロードプロセス

クラスのライフ サイクルは次の 7 つの段階を経ます。

ロードフェーズ

このステージは、対応するクラスを見つけ (クラス名で検索)、このクラスのバイト ストリームをメソッド領域ランタイムのデータ構造に変換し、他のデータにアクセスするためのエントリ ポイントとしてメモリ内でこのクラスを表すことができる java.lang.Class オブジェクトを生成するために使用されます。

検証フェーズ

このステップは主にバイトコードのセキュリティを検証するためのものです。セキュリティ チェックが実行されないと、安全でないバイトコードや誤ったバイトコードがロードされ、システムがクラッシュする可能性があります。これは JVM の自己保護のための重要な対策です。

検証の主なアクションは次のとおりです。

• ファイル形式の検証には、定数プール内の定数タイプ、クラス ファイルのさまざまな部分が削除されているかどうか、またはその他の情報が追加されているかどうかなどが含まれます。
• メタデータ検証には、親クラスの正確性検証 (親クラスが final として変更されているかどうかのチェック)、抽象クラスの検証などが含まれます。
• バイトコード検証: このステップは最も重要かつ複雑であり、主にプログラム内のセマンティクスが合法かつ論理的であるかどうかを検証するために使用されます。
• シンボル参照の検証。定数プールなど、クラス自体の外部にあるさまざまなシンボル参照の情報の一致をチェックします。

準備

このステージは、クラスで定義された静的変数のメモリを初期化して割り当てるために使用されます。これらの静的変数はメソッド領域に割り当てられます。

JDK 1.7 より前では HotSpot 仮想マシンはメソッド領域にありますが、JDK 1.8 以降ではこの変数はクラス オブジェクトとともに Java ヒープ内に格納されます。

解析フェーズ

このステージは主に、クラス、インターフェース、フィールド、メソッドを解析するために使用されます。解析中に、シンボリック参照は直接参照に置き換えられます。

シンボリック参照は、参照先を記述するために使用されるシンボルのセットです。シンボルは、使用時にターゲットを明確に特定できる限り、任意の形式のリテラルにすることができます。直接参照は、ターゲットを直接指すポインター、相対オフセット、または間接的にターゲットを特定できるハンドルです。

シンボリック参照と直接参照には重要な違いがあります。シンボリック参照を使用する場合、参照先は必ずしもメモリにロードされるわけではありません。直接参照を使用する場合、参照先ターゲットは仮想マシンのメモリ内にすでに存在している必要があります。

初期化

初期化フェーズでは、JVM はクラスに記述された Java ビジネス コードを正式に実行し始めます。このステップの後、クラスのロードプロセスは正式に完了します。

要約する

上の図に示すように、2 つの明るい緑色の部分はクラスのライフ サイクルを表します。これは、クラスのロードからクラス インスタンスの作成と使用、そして使用されなくなったクラス オブジェクトが GC によってアンロードされ、リサイクルされるまでのプロセスです。

ここで注意すべき点は、Java 仮想マシンに付属する 3 つのクラス ローダーによってロードされたクラスは、仮想マシンのライフ サイクル全体を通じてアンロードされないことです。ユーザー定義のクラスローダーによってロードされたクラスのみをアンロードできます。